Developers only need to build some APIs - those APIs can be multi-purpose. They don't need to know that one such purpose is NSA spying - you can come up with dozens of other reasons for wanting a "back door".
The actual interface that's used for responding to legally binding orders or subpoenas and that uses the APIs in question can be built by people on NSA's payroll.
Besides executives, the only people slightly aware of what's going on will be some people from the legal department. And they'll get presented with an interface in which they have to double-check (in bulk) the validity of received orders.
As far as I understand from the other press coverage the current procedure is that people in MS legal department don't even have to "check" that specific orders exist, it's something that the API user is supposed to do on their side. The procedure specifically allows API requests and monitoring immediately and providing the orders in some-week time or if the order doesn't come "destroying" the obtained data that aren't metadata. Metadata can always remain because they are considered "public" in the current up-to-recently secret law interpretations. And for non-US-citizen-or-not-on-US-soil data the orders are never needed.
Give me 12 (a dozen) reasons to break the encryption and security of your users that could be acceptable to a non brain dead engineer and exclude surveillance and government snooping?
You're missing the fact that if a middleman does the encryption or has access to the decryption key, then encryption is already broken.
A service provider is the middleman in this case and encryption only serves the purpose of you making sure that communications are with this service provider and not with another middleman.
"Breaking the encryption" is not accurate. They don't need to break anything as your data is in plain text on their servers.
> "Breaking the encryption" is not accurate. They don't need to break anything as your data is in plain text on their servers.
While this is true, I don't think it was his point. His point, I believe, was that the software should protect the data, and the engineer should not install or create APIs that allow someone to circumvent the security and privacy of the user — for any reason. He was replying to someone saying that higher ups could lie about the reason or need for such an API; his reply was saying that even the lie should be so obviously privacy-breaking as to be unacceptable. (Hence, he asked for examples.)
That said: legitimate law enforcement requests, i.e., warrants, would be an acceptable reason to me to implement such an API. That said, it should be auditable, so that you can verify it isn't being abused.
Developers only need to build some APIs - those APIs can be multi-purpose. They don't need to know that one such purpose is NSA spying - you can come up with dozens of other reasons for wanting a "back door".
The actual interface that's used for responding to legally binding orders or subpoenas and that uses the APIs in question can be built by people on NSA's payroll.
Besides executives, the only people slightly aware of what's going on will be some people from the legal department. And they'll get presented with an interface in which they have to double-check (in bulk) the validity of received orders.