[gnosis]

Actually, it does have something to do with it.

When you don't pay for a service in money, the company providing that service has to find some other way of generating money.

Often they do this by collecting and selling data about you.

Now, that doesn't mean that just because you paid for a service they won't do the same thing. But they'll will have more incentive to protect their paying customers than some service which consider you and your data as the commodity.

[spankalee]

Sorry, paid or not still doesn't have anything to do with whether or not a company will comply with a lawful order, or how much that company will push back. The incentive and willingness to push back isn't related to how much a single user pays, but considerations like the principles of the company, and the estimated aggregate losses from the perception that a company doesn't protect their user's data. Google, for instance, has a much higher potential loss from this perception than a smaller company that charges.

Also, Google does not sell information about their users. They target ads. The difference is huge.

[jkrems]

This has nothing to do with privacy and free services. Yes, that is a problem, but it has no connection at all to this case. It's about emails and private chats being given to the government without any limitations. It's about non-US citizens having zero protection or due process when they use US-based cloud services. That's a couple of degrees more severe than "Google is storing personal details about you and may give them to the government". It basically means that foreigners upload their data de-facto directly to NSA servers when they use US cloud services.

[embolism]

You can't separate the two. The reason why foreigners are uploading their data to the NSA when they use Google is because of the way Google makes its money and engineers its services.

Compare this to Apple's iMessage or FaceTime - Apple cannot decrypt the contents of the messages, and therefore cannot give the contents to the government.

They designed the service this way because their users pay for the service as part of the cost of the devices they sell so they don't require access to the data for behavioral profiling.

[jmillikin]

  > Compare this to Apple's iMessage or FaceTime - Apple
  > cannot decrypt the contents of the messages, and
  > therefore cannot give the contents to the government.

This is not correct.

First, when you buy a new iPhone, the way you authenticate yourself is by entering your Apple ID and password. Once entered, your new device will begin receiving iMessage data. This means that Apple is capable of provisioning a virtual device with your credentials, which will receive your messages. From there, they can be either stored or forwarded to third parties.

Second, your iPhone runs binaries distributed by Apple. There is no technical reason why these binaries could not contain code to forward historical messages to Apple or to a third party. Even if they don't now, a future update to iOS (which you won't be able to audit) could introduce such code.

The only way to have private communication is for all parties to run open-source clients. Each party must have the technical skill to audit the source code, or there must be at least one (preferably multiple) trusted third-party auditor. They must distribute encryption keys through a separate channel which does not depend on the communication host.

In other words, the standard Thunderbird+GPG+keyparty system that is popular among nerds but has seen no uptake among the general population.

[embolism]

First, when you buy a new iPhone, the way you authenticate yourself is by entering your Apple ID and password. Once entered, your new device will begin receiving iMessage data. This means that Apple is capable of provisioning a virtual device with your credentials, which will receive your messages. From there, they can be either stored or forwarded to third parties.

Wrong. As others who have examined the protocol have noted, your password is used to unlock a keybag on the device itself. Apple doesn't have your password (only a secure hash) and therefore can't unlock the keybag. The security depends on the strength of your password, which is a weakness, but it is in your control, not Apples.

Yes, the binaries of any system can contain arbitrary spyware or be infected with such at any stage from development through to decommissioning. Open source is no absolute protection against that.

At the moment we are trusting that companies are not baldly lying to us, even Google.

[jmillikin]

  > As others who have examined the protocol have noted,
  > your password is used to unlock a keybag on the device
  > itself. Apple doesn't have your password (only a secure
  > hash) and therefore can't unlock the keybag.

Re-read what I wrote, and think about what it means.

Setting up iMessage on a new iPhone does not involve copying a "keybag" (sic), inputting a private key, or any other form of strong client-side authentication. All you have to do is sign into the device using your Apple ID, and you can then receive iMessage messages.

If there were any additional barrier preventing Apple from provisioning iMessage entpoints, iPhone users would not be able to activate iMessage with only their Apple ID.

Do you understand now?

  > Yes, the binaries of any system can contain arbitrary
  > spyware or be infected with such at any stage from
  > development through to decommissioning. Open source is
  > no absolute protection against that.

It's not an absolute protection, but it is very good protection.

Staying inside your house is not absolute protection against being eaten by bears, but your chances of being eaten by bears are much much lower than if you walk around Yellowstone dressed in steak.

[embolism]

   Re-read what I wrote, and think about what it means.

I think it means you have a false belief about the limits of the system.

   If there were any additional barrier preventing Apple from provisioning iMessage entpoints, iPhone users would not be able to activate iMessage with only their Apple ID.

Wrong. Apple doesn't have your password. Only a hash. Verifying against the hash allows apple to add another device to the backend but does not unlock the keys to the message history. Only the password does that.

There is some understanding about how the protocol works here: https://news.ycombinator.com/item?id=5493514

There are other sources around the net that you can refer to to understand more about how such a protocol can be built, but I don't have a lot of faith in you as a conversation partner now that you've demonstrated that you can't be bothered to inform yourself before responding incorrectly with condescending certainty.

[magicalist]

Even leaving behind the arguments that Apple was incorrect on iMessage history being inaccessible to them, what about the rest of Apple's services (like all your icloud email, your contacts, calendar, etc) that certainly can be turned over with a warrant?

Your conclusion does not follow.

[embolism]

That data certainly can (and likely is) turned over by Apple in just the same way that the data Google stockpiles can be.

This doesn't affect the conclusion - Apple can make services that don't compromise user privacy because they aren't driven by their business model to collect personal data for behavioral profiling. Google has a vested interest in collecting this data, and persuading us to accept this as normal, that Apple just doesn't have.