arde

Regarding item 4, a VPN solution is considerably more complex and error prone than port knocking plus SSH. What do you do if/when your VPN service fails? I think you would usually have a VPN service AND a port knocked SSH backdoor.

That is equivalent to limiting SPA to a 16-bit password.

This. Obscurity has too much bad press. It's not to be depended on, but it can be a useful addition sometimes.

Yes, an AES-CTR transformation would be more secure than any port knocking variety such as SPA, at the cost of being more complicated. But the point in port knocking is not its intrinsic security, which is not worth to talk about: its point is actually the obscurity it adds to some other secure access method such as SSH, and its ease of implementation and usage. With it you get much shorter and less noisy logs to monitor, and it's almost for free. In a way, it can be compared to camouflage: its dirt cheap and quite effective at avoiding hits. Bulletproof vests or armoring are still required, but the question is why would you NOT be camouflaged when you can?

Well, that's exactly what I meant with my edit: carry it yourself so "they" don't get their hands on it. Sorry I didn't make it clear.

Hmm. How about having a firewall consisting of two distinct servers placed in series, one made in the US and the other made in China, both running some open-source OS. I know, the surface attack is still huge but at least you are not automatically and completely open to a single three-digit agency.

Edit: oh, you'd have to import the Chinese one yourself into the US to make sure it doesn't get its firmware "updated" somewhere in the suppliers chain.

Snark and sarcasm somewhat aside, it's not like they could tell the users about the remediation progress through their intranet, so they probably didn't have many options besides posting it on the Internet for all to see.

Yeah, and who cares about shared folder performance anyway?

What, no Erlang? Sheesh! Amazing work.

It depends on what you compare it to. I meant complex in the context of the use case I have in mind. It certainly IS much more complex (and powerful) than a simple GIF creator. But if you only need a one-way, low quality stream, RFB is overkill.

For my use case I'm not worried about the client's security (in fact, he's the one I'm interested in protecting the server from).

We probably are assuming very different tolerance thresholds on security. But even so, I don't think you can argue for any security advantages of typical implementations for a 50-page protocol when comparing them to a one-way simple GIF sender.

For this use case I don't trust implementations that I have source code for, due to their complexity. This is intended to share screens that lie behind a firewall. It wouldn't make sense to trust third-party code with closed source code and a similarly complex protocol (and undocumented). Neither would be logical to add this third party, the middle-man, as a point of failure and attack.

This nicely solves a problem I've been asked about: how to share a screen securely (read-only). VNC protocol and implementations are too complex/sloppy so I don't trust them. An endless GIF, on the other hand...

Same here. Specifically, I'm not buying one until I can print circuit boards.

"We certainly have something to learn here about the best way to ensure dialog with clients about this kind of issue. [...] We [...] invite them to contact our commercial team (in french)."

To ensure dialog, why not start by being able to communicate with clients in English? (or their own language, for that matter).

This one wasn't one of the reasons I considered, but I find it interesting:

Suppose you upgrade any old OEM Windows XP or later that's bound to the hardware that you bought it with. Once you upgrade, you are no longer bound by the old license but by the new one. So you now have a full Windows 8 Pro, not OEM, that you can move somewhere else, virtualize, etc. That's what the license says, as far as I understand it (IANAL, but I have read it thoroughly).

Edit for clarification: even though you get a Windows 8 Pro, not OEM, it's still a Windows 8 Pro Upgrade. So yes, you can move it somewhere else or virtualize it, but it still needs to be installed over an existing and properly licensed Windows copy (XP or later).

More easily said than done, though.

Windows 8's UI is noticeably faster than its predecessors.

And if you have a Windows 7-based tablet like I do, you'll appreciate the new touch UI because Windows 7's was not very good while Windows 8's is more reasonable.

Also, Windows 8 doesn't seem as half-baked as previous Windows versions did at the time they were released. Then must have improved their testing process because being a Windows 8 early adopter no longer feels like being a beta tester.

I'm not a Microsoft lover, not by a long stretch, but for Windows users this is an offer too good to pass.

New wave of "Beat the stock market" strategy books in 3, 2, 1...

Indeed. Furthermore a study has found that moth's memories are retained from one stage to the other (http://news.nationalgeographic.com/news/2008/03/080305-moth-...).

Sure, but those who inherit PHP systems may not belong to the PHP's target audience that I was referring to. Neither must all people who choose to use PHP necessarily idiots, because PHP does have some legitimate use cases. But all in all I don't think PHP maintainers can expect sanity from their users as a general population nowadays. I know it sounds harsh, and it probably is a bit judgmental on my part too, but I hope you get the idea.

I don't think you got to the real problem here. Weak types are quite useful for some tasks, and of course they are nothing new. Languages that convert between integer and string types automatically are well suited for text processing in general (including generating web pages dynamically).

The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check out AWK, another weakly typed language, for example:

BEGIN{printf "%5.2f\n", ""}

prints "0.00" as would be reasonable.

Perhaps it was not like this when PHP was created, but it surely has been for a long while now: Idiots are now PHP's target audience be it by design or by its own faults. So if Rasmus Lerdorf still maintains PHP then he should not get angry by the kind of users he chose and/or deserves.

It's bad code alright. But I would argue that any code you write in a bad language turns into bad code, no matter how you do it. It might be good enough for your application, so that's fine. But it would be bad nonetheless. And PHP is not a sane language by any measure. So here we have a bad code author dealing with it's bad languague's shortcomings and expecting that they be solved by the very people who created said bad language in the first place. Quite entertaining.

Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.

They probably only care about the presentation aspect of it, and not doing any calculations with uninitialized variables. The users are probably worried about showing NULLs instead of zeroes on empty fields.

Well, of course they must be addressing security changes! It's PHP, remember? ;)