Personally, I would use the names of some bad guys at the TSA as aliases, ...

Actually the backup data centre is outside of the EU, located in Switzerland.

Well, he did fix the illegal activities of the previous administration.

He's a law professor.

So now all these stuff has been made as legal as possible.

See, you should be happy that you've lost your privacy legally, aren't you happy?

Get yourself educated, the NSA is a little bit older than the 90s.

http://en.m.wikipedia.org/wiki/National_Security_Agency

And similar to that, the invocation of "it's legal", well, many extremely negative things are "legal". The Holocaust was almost certainly quite legal by German laws issued by the Nazis. Which by the way were elected legally in a democracy, btw.

Well, the reality is that different jurisdictions will always have compatibility issues. And they are really really hard to fix. They exist in the US (where companies have been known to use license plates from other states for their trucks to save a dime, even if their "office" in that state happened to be a desk in the dealership selling them the trucks), in the EU (where despite treaties being in place they still do not really manage to make tickets stick in different countries for minor traffic mishaps), and internationally.

Up to a certain point it's probably okay, but it's hard to fixate that point (which makes working out the compatibility issues in laws and taxes even harder).

Now the big international companies are taking this avoidance to ridiculous levels, e.g. small single digit percentages, at least for income outside US.

The big but: "it's legal". Well, many things that are legal, are far from ethical. "legal" is a very poor benchmark for behavior. (Hint: most genocides have been quite legal in the country that was responsible for them at the time that they happened.)

Well, always compare it to the base value, the income to be taxed.

So yes, the rate is relevant. Plus, in the case of Apple & friends, the issue is that they avoid paying taxes on income abroad, they basically manage to get it not taxed in the US, and the country where the income was created.

One can argue that this is "fair" to the US, because the part of the income that the companies did not manage to move out of the country is taxed here. But it's certainly not fair to the other countries.

You do realize, that for snail mail the NSA does get all scanned envelopes from the post office?

So the metadata is there in the same way.

And opening an envelope, openly with a warrant or in secret is an art form that has reached rather perfection over the centuries.

Think before typing.

We are talking about the SSL key, and yes I think you'll accept it that for a working webserver you need to respond in real time.

Well, you do not know that.

Court orders seem to come nowadays quite often with a gag order.

So basically, you only learn when the companies go bat and that somehow leaks (the gag order gets lifted).

The other extreme is, you might get to know if they go and prosecute you.

Now you've got a situation where the huge majority of events (guess in 99% range) is not observable, hence it's not an option to use these events to guide your
behavior.

For practical purposes, all companies (and especially big companies with shareholders) don't care and cooperate. Lavabit did fold because it was small enough (and closely enough held) that the ethics of one person where enough to make the company close down instead of cooperating. That won't happen for a publicly traded company.

So basically Google, MS, Apple, ... are all not trustworthy in this context.

Go, get yourself some education.

They wanted the master SSL private key.

That would have allowed the Feds (or anyone that gets his hands on it), to do a Man-in-the-middle attack. Plus depending on the browser used and server, it would have allowed them to decrypt passively intercepted connections. (the reasoning for that is that depending on the configuration of SSL client/server, the symmetric key used for the connection is passed on the wire or not)

In near field that means SSL can be intercepted and decrypted, without breaking the encryption, for specific sites.

On the extreme it means, that x509 and SSL as a whole is broken. Wonder if there are sealed court orders (or court orders by secret courts), with gag order, to hand over the private signing keys of CAs?

And last but not least, the big issue here is why this is so bad. It forces tiny bits of data, but that are of crucial importance, that are normally guarded highly to be distributed to 3rd parties. Now these 3rd parties have no real economic incentives to keep that tiny speck of data overly secret, e.g. it ends in the normal files of law enforcement. So basically your highly sophisticated system design to ensure the security of the private key is now open to a quite long list of dangers you cannot do anything against.

In the artificial benchmark world, yes you can manage to construct cases where a two liner in python can beat a C++ STL program. (Hint: C++ strings are mutable, Python one not. C++ has a strong preference for by-value semantics because it lacks GC. Hence stuff a huge multi-kb const string into a big dict, no matter what, STL map will be slower because it's forced to copy the stupid strings)

In the real world of commercial development, yes, but it's a complete different pattern:
experience shows (in at least one contract I had rather exactly the same situation), that the terser-language guys tend to be quite a bit more productive, hence while the C++ guys are happy to have finished their first iteration, the more productive guys are somewhere in their third iteration, yielding improvements in algorithms, data structures, inner-loops implemented in C, plus generally speaking a way better understanding of the problem space.

Furthermore, static typing catches many errors during compilation. The sad part is that it does not catch all errors in some categories, which leads to multiple ugly results, the foremost being that developers expect the bugs caught by the compiler, hence don't test for them.

An example would be changing method arguments. Most developers expect the compiler to catch these. Sadly, a huge subset of these are not caught by compilers in most languages, e.g.:

void doit(int x, int y) => void doit(int y, int x);

Now while this sounds trivial, the underlying issue is fundamental (type theoretically spoken, type equivalence by structure), and even a developer knowing about this can be caught, as the typenames for x and y could be different (typedefs come to mind). Actually, C & C++ define a number of opaque datatypes where the developer is not expected to know what's inside. (e.g. FILE in Ansi C, guess most developers would not be able to tell by introspection if some random struct is type equivalent to FILE.)

Now the ugly part is, because unittesting is work (and static-ness does not help, it usually makes it necessary for code to be developed explicitly allowing stubbing out stuff), and because the compiler is meant to catch this category ("argument errors"), you will find that most statically typed projects do not apply the same degree of testing to the code (and especially for issues that the compiler is supposed to handle).

Dynamically typed languages do not promise any of these, hence testing usually includes also these topics that others believe to be checked by their compiler.

Sorry guys, since when is Scala a scripting language. Anything but?

Actually, in most cases Alice won't be in legal trouble either, e.g.:

Bob kills somebody.
Alice witnesses this, but is texting while driving.

Bob does not need to talk because he might self-incriminate. Alice would also self-incriminate herself, albeit not in the murder case.

That's why witnesses if they are really needed are offered immunity.