Apple’s New Privacy Page
With Apple’s update to its privacy page today, the company has created a site that explains how privacy drives the design of its apps in clear, concise language. However, for anyone who wants to understand the nitty-gritty details, Apple has also published white papers and linked to other materials that provide a closer look at the issues that the main page addresses.
I’m not thrilled with the Safari section and white paper:
Browsers are more convenient to use when information is synced across a user’s different devices. For example, being able to access their history across devices means users can easily find the places that they’ve been on the web, regardless of whether they’re on their phone or their computer. Safari provides a secure way to keep information in sync across devices while protecting privacy. Unlike other browsers, Safari doesn’t have a browser-level sign-in that automatically signs the user in to all the browser vendor’s online services.
Instead, macOS continually badgers you to sign into iCloud, and unless you specifically opt out using the checkbox that merely says “Safari,” it sends your entire browsing history to Apple. Nowhere in the app’s interface does it say that it does this, and you can’t opt out without also losing bookmark syncing. Whereas, Chrome does not badger you to log in, does not enable history syncing by default, and does let you sync bookmarks without syncing history.
It also fails to mention that the Safe Browsing feature sends, from your IP address, information about the sites you visit to Google or Tencent.
Previously:
- Siri Stores Encrypted E-mails in Plain Text
- Safari Safe Browsing, China, and Privacy
- Intelligent Tracking Prevention 2.3
- Keeping Your Safari Data Private
17 Comments RSS · Twitter
@Eugene That’s not correct. Please see my post on this.
Thank you, Michael. I missed that post somehow. Sorry!
[…] the page is a nice marketing effort, there are a few problems. As developer Michael Tsai points out, Apple claims that Safari doesn’t have a browser-level sign-in to sync data, which is true but […]
"Nowhere in the app’s interface does it say that it does this, and you can’t opt out without also losing bookmark syncing."
I'm guessing this also applies to iCloud Tabs? I don't use Bookmarks but I do frequently bounce tabs between devices, and I'm concerned if this means Apple could theoretically snoop on which sites I'm browsing.
Why wouldn't they encrypt the URL and page title?
@Ben Yes, iCloud tabs is not peer-to-peer. I goes to their servers. Encryption is meaningless when they have the key, like for most iCloud content.
This gets to be so confusing. But iMessages are securely encrypted so that even Apple can't see them, right? How do they do that when they have to store them on the server for some amount of time (e.g. to sync later with a devices that's not currently online), but they can't do the same with other iCloud content?
@Ben iMessages are securely sent but not securely backed up. I don’t think they’ve said how the syncing works, if you have that enabled. It is confusing. If you think about how that sort of secure exchange would have to work for other types of data, I can see why they haven’t done that yet.
Yeah and also we now have iCloud Messages, which brings a whole new set of questions. Apple really needs to clear this up. I’m not very well versed on encryption but I’m nearly certain that there’s a (easy?) way to store encrypted data on a server that can’t be unlocked by the server owner, but can be unlocked on a local device with a decryption key that’s private to the device / device owner— isn’t that how PGP email works? Why does Apple need at have a way to decrypt my iCloud data? Shouldn’t I be the only one that has the key?
@Ben I think the issue is that if Apple can’t decrypt your data, that means you need to have the key; they can’t store it for you. But they don’t want to require you to manage/transfer the key yourself, like PGP does. So they use device keys. But that requires that the device itself encrypts the data for the other devices. A new device can’t just download the data from the server; it needs the cooperation of the other devices. That’s probably tricky for large amounts of data. And it’s hard to do any smart processing/syncing on the server if the data is all encrypted.
Per a Safari engineer at this year’s WWDC: in Catalina, iCloud tabs and Safari history are both synced with end to end encryption of the sort iCloud Keychain uses.
@Jake Interesting, thanks. Do you have a session reference for that? Nothing came up when I searched (except for general stuff like MacRumors), and the iOS 13 security guide isn’t out yet.
Chrome might not badger you to sign in, but last year they just did it without asking and without a way to opt out.
And if I install a fresh copy of Chrome on iOS, it already knows who I am. I don’t know how they do it, but it’s creepy as hell.
@Jake As of now, Apple says that Safari data is not end-to-end encrypted.
@Michael I read somewhere the same thing @Jake is saying, though I can't remember where. I believe the switch to end-to-end encryption was referenced as an explanation as to why iCloud tab syncing stopped working between Safari 12 and Safari 13/iOS 13. Would love confirmation of this, however.
@Nigel Would love to see it if you can find the link. I searched WWDC videos, the new platform security guide, and the iCloud security overview and I don’t see anything saying that.
@Michael All I'm turning up now are a few comments on message boards. I haven't found an authoritative source for this info, so who knows if it's true:
https://www.reddit.com/r/iOSBeta/comments/cc4kye/workaround_icloud_tabs_not_syncing/etl5b18/
https://forums.macrumors.com/threads/icloud-tabs-not-syncing.2199543/post-27768896
https://discussions.apple.com/thread/250672750?answerId=251504888022#251504888022
Safari doesn't send your links to Google or Tencent. It's just grabs a list from them with an array of malicious sites. Then Safari would check user's URL locally, without sending any specific address with providers of those lists.