iCloud was storing cleared browsing histories(theverge.com)
theverge.com
iCloud was storing cleared browsing histories
http://www.theverge.com/2017/2/9/14559376/apple-icloud-cleared-browsing-history-stored
74 comments
After a crash Safari is nice enough to restore your open windows and tabs... I've noticed several times that it's also nice enough to re-open your private browsing windows, too. That throws up some red flags for me.
That's a MacOS thing, not just a Safari thing. Windows stay open until you close them, even across restarts. MacOS, like iOS, has mostly retired the concept of "quitting an app kills state".
(You can go back to the old behavior via a system setting: "Close windows when quitting an app")
(You can go back to the old behavior via a system setting: "Close windows when quitting an app")
This feature isn't some kind of evil magic... it isn't like it is serializing the virtual memory state of the entire process to disk in the style of unexec(): programs have to manually decide what they think matters for their suspension state; correspondingly, if this happens, Safari would have to be incorrectly saving information that the user clearly doesn't expect or want.
> Safari would have to be incorrectly saving information that the user clearly doesn't expect or want.
This is vestigial thinking from the MacOS perspective. The concept of "saving" is gone. The concept of "memory state" versus "disk" is gone, from the user perspective. Those are all implementation details now. For the user it's simply, your windows stay open until you close them. Quitting does not close windows, so it's not unusual to see them when you return to an app.
By the way, Safari in iOS does exactly the same thing. And given that iOS kills apps on its own, there would be no question that randomly killing private sessions would be a bug.
I mean maybe you could distinguish between a force quit and an OS quit, but why? Just close the windows if you want to clear them. The private window guarantee is there will be no trace after you close the window. It's just vestigial thinking that quitting apps also closes windows.
This is vestigial thinking from the MacOS perspective. The concept of "saving" is gone. The concept of "memory state" versus "disk" is gone, from the user perspective. Those are all implementation details now. For the user it's simply, your windows stay open until you close them. Quitting does not close windows, so it's not unusual to see them when you return to an app.
By the way, Safari in iOS does exactly the same thing. And given that iOS kills apps on its own, there would be no question that randomly killing private sessions would be a bug.
I mean maybe you could distinguish between a force quit and an OS quit, but why? Just close the windows if you want to clear them. The private window guarantee is there will be no trace after you close the window. It's just vestigial thinking that quitting apps also closes windows.
Storing stuff on disk that should be kept purely in-memory is a Mac thing?
Being able to pull the plug/battery on a computer and then having the restored state be exactly the same is a Mac thing, yeah.
In this particular case though it should not do so. Users do expect the private tabs to disappear after the window closes, no matter how it is closed.
I am not sure reopening private windows is a good idea, either, but Mac OS removed the rule "quitting an application closes its windows".
Given that, it is logical that it reopens private windows, just as, for example, TextEdit or Numbers reopen windows with content you never explicitly saved (even across reboots)
Given that, it is logical that it reopens private windows, just as, for example, TextEdit or Numbers reopen windows with content you never explicitly saved (even across reboots)
>Being able to pull the ... battery on a computer... is a Mac thing
Nope!
Nope!
What is "quitting" then? How much state is stored? Between "no state" (window is a dead bitmap) and "all the state" (program is simply paused) is a lot of wiggle room.
As long as this functionality is documented on the incognito start page, similar to "doesn't make you anonymous" warnings, it seems fine (by design) to me.
If anyone has any pointers to documentation on the forensics aspects of this I'd appreciate a link.
It doesn't look like there's that much open source available for the new-ish Windows 8+ hibernation file: https://github.com/volatilityfoundation/volatility/issues/25
If anyone has any pointers to documentation on the forensics aspects of this I'd appreciate a link.
It doesn't look like there's that much open source available for the new-ish Windows 8+ hibernation file: https://github.com/volatilityfoundation/volatility/issues/25
Why would anyone find this behaviour desirable? We should ask that before going to the "If its documented its the user's fault" truncheon.
before going to the "If its documented its the user's fault" truncheon
To be clear to anyone else reading this, that's not what I said nor close to what I meant. I think I understand where you're coming from though.
To be clear to anyone else reading this, that's not what I said nor close to what I meant. I think I understand where you're coming from though.
sorry for the quotes didn't intend to make it look like you said that.
Well to be honest they don't say that the browser doesn't store your browsing data temporarily. As a matter of fact it has to do that in order to provide you with caching, cookies and local storage for your private browsing session. Normally this data gets wiped out when you close the window, but when the browser crashes it doesn't have chance to do so, so they restore the windows for you so you can make the decision whether to close them or not.
> As a matter of fact it has to do that in order to provide you with caching, cookies and local storage for your private browsing session.
This is solved by knowing what is stored is private browsing data, which should be marked anyways. Safari just isn't that well thought out of a browser.
This is solved by knowing what is stored is private browsing data, which should be marked anyways. Safari just isn't that well thought out of a browser.
> Safari just isn't that well thought out of a browser
Safari is just a browser that has made a different set of tradeoffs.
Safari is just a browser that has made a different set of tradeoffs.
What tradeoff? Both chrome and Firefox treat private browsing data differently, and if they crash, will not be able to just restore it. Even if they did, its still bad design. The point of private browsing is to make it so when that window exits, that data doesn't exist anymore. You can still pull it up in new tabs in Firefox, but not if the window itself closes.
I'm just speculating here, but since macOS/iOS have native APIs that automatically enable state restoration, Safari might be using those instead of reinventing the wheel for cross-platform compatibility like Chrome and Firefox need to.
Leveraging native APIs means less code (fewer bugs), less disk usage, less RAM usage, etc.
Leveraging native APIs means less code (fewer bugs), less disk usage, less RAM usage, etc.
>> Both chrome and Firefox treat private browsing data differently
>> The point of private browsing is to make it so when that window exits, that data doesn't exist anymore.
When defining what private browsing is supposed to do we should keep in mind Safari was the first major browser to introduce the feature.
>> The point of private browsing is to make it so when that window exits, that data doesn't exist anymore.
When defining what private browsing is supposed to do we should keep in mind Safari was the first major browser to introduce the feature.
Sure, but it also didn't save/restore any window or tab state at that time. All those features came later, so this represents a change in how things act between Safari versions.
> The point of private browsing is to make it so when that window exits, that data doesn't exist anymore
Who defined it that way? And how do you define 'exit', 'data' and 'exist'?
Who defined it that way? And how do you define 'exit', 'data' and 'exist'?
What is reality anyway?
Typically in macos, closing windows doesn't quit applications and quitting applications doesn't close windows.
[deleted]
Sounds like a mistake rather than some nefarious data collection strategy.
Apple doesn't rely on advertising revenue like Google or Facebook so in the past they've been much more likely to avoid collecting data whenever it could get in the way of their self-professed privacy narrative.
Apple doesn't rely on advertising revenue like Google or Facebook so in the past they've been much more likely to avoid collecting data whenever it could get in the way of their self-professed privacy narrative.
Storing data on Apple's cloud services is a privacy risk given their inability to keep it secure. We had the celebrity iCloud hack, caused at least in part by Apple not using 2FA for iCloud logins. And now this privacy failure.
Storing your data on a cloud service that isn't competent is a privacy risk.
And a reliability risk, as I found out last year when my albums on iCloud Photos disappeared. Not the photos themselves, just the albums in which I organised them, but organising data can take a lot of time, and any data loss is unacceptable. They weren't in trash.
Apple's "self-professed privacy narrative" is partly right, but partly marketing, and partly disingenous, as if collecting data has no other purpose than advertising: https://dcurt.is/privacy-vs-user-experience To be clear, I'm not taking a black-and-white view; it's partly right, partly wrong.
BTW, The Verge wasn't clear — was the forensics firm getting data from an iDevice or Mac's local storage, or across the Internet from iCloud servers?
Storing your data on a cloud service that isn't competent is a privacy risk.
And a reliability risk, as I found out last year when my albums on iCloud Photos disappeared. Not the photos themselves, just the albums in which I organised them, but organising data can take a lot of time, and any data loss is unacceptable. They weren't in trash.
Apple's "self-professed privacy narrative" is partly right, but partly marketing, and partly disingenous, as if collecting data has no other purpose than advertising: https://dcurt.is/privacy-vs-user-experience To be clear, I'm not taking a black-and-white view; it's partly right, partly wrong.
BTW, The Verge wasn't clear — was the forensics firm getting data from an iDevice or Mac's local storage, or across the Internet from iCloud servers?
Apples approach to security is nicely summarized by the fact, that you're not allowed to use 2FA for iCloud at all on a Mac if you don't own an iPhone.
Also, you're forced to use silly old password reset questions (from a predefined list). I just recently had to do this for my dev account (not Apple user otherwise) and was mildly shocked. There were no questions people knowing me couldn't answer with moderate research effort...
Both two step authentication and two factor authentication can be set up to use text message or phone call verification to an arbitrary phone number.
According to this: https://support.apple.com/en-us/HT204915
a "trusted device" is only an Apple device, phone calls are for backup when you lose them. Even after that it's significant inconvenience in comparison to any other vendor using a standardized OTP approach working with any application that implements the standard. It's one of the little ways how Apple makes not owning an iOS device inconvenient for mac users.
a "trusted device" is only an Apple device, phone calls are for backup when you lose them. Even after that it's significant inconvenience in comparison to any other vendor using a standardized OTP approach working with any application that implements the standard. It's one of the little ways how Apple makes not owning an iOS device inconvenient for mac users.
[deleted]
It's extremely confusing, but Apple has two types of multple-factor authentication solutions in use.
The 'legacy' (my phrasing, only because it was the first implemented) MFA is SMS-based, and thus has not dependency on iPhones.
There's a newer (about a year or two old by this point) solution which has a 'richer user experience' and depends on having other Macs or iPhones to receive the MFA authentication dialogs.
The 'legacy' (my phrasing, only because it was the first implemented) MFA is SMS-based, and thus has not dependency on iPhones.
There's a newer (about a year or two old by this point) solution which has a 'richer user experience' and depends on having other Macs or iPhones to receive the MFA authentication dialogs.
The newer solution ("Two-factor authentication") also allows non-Apple phones to receive a code on their "trusted phone number". From the support page linked in a nearby comment:
What if I don’t have access to a trusted device or didn't receive a verification code?
If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text or a phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device.
What if I don’t have access to a trusted device or didn't receive a verification code?
If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text or a phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device.
I believe Apple prefers that people use a trusted device as from their point of view this is more secure as they can verify the entire communications loop so they view this as a fallback option, but you certainly can use non-Apple devices to authenticate. They also don't appear to throw up any roadblocks to doing so.
Isn't the fallback only SMS/phone? That seems like a roadblock compared to say Google Authenticator.
Actually the new 2FA method they introduced somewhat recently does allow this.
We had the celebrity iCloud hack, caused at least in part by Apple not using 2FA for iCloud logins.
iCloud has offered 2 step authentication since 2013 [0]. From what I can tell, the celeb hack happened a few weeks before the public release in mid-2014.
[0] https://9to5mac.com/2013/03/21/apple-beefs-up-icloud-apple-i...
iCloud has offered 2 step authentication since 2013 [0]. From what I can tell, the celeb hack happened a few weeks before the public release in mid-2014.
[0] https://9to5mac.com/2013/03/21/apple-beefs-up-icloud-apple-i...
Apple's iAd advertising network only closed down a few months ago. They still have searchads for their apps stores and iTunes. Advertising isn't a big part of their business, but they do have good reason to collect data for targeting.
If you're concerned about artifacts being left around, then you should also know that there is a log file of every file you've ever downloaded, including in private browsing mode. You can see it with this: https://macdaddy.io/cleandisk/
Today I learned that $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 is a sqlite database. The LSQuarantineEvent table contains every file you ever downloaded, the source URL is in the LSQuarantineDataURLString column.
sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'select LSQuarantineDataURLString from LSQuarantineEvent'
sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'delete from LSQuarantineEvent'
sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'select LSQuarantineDataURLString from LSQuarantineEvent'
sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'delete from LSQuarantineEvent'
It's directly loadable using a GUI too (eg sqlitebrowser.org), for anyone that prefers the graphical approach.
And yeah, it had all kinds of interesting stuff I've downloaded over the years in mine. Now cleared. ;)
And yeah, it had all kinds of interesting stuff I've downloaded over the years in mine. Now cleared. ;)
Interesting. But I see only fairly old stuff there. And I'd guess only downloads from a single day or week a few years ago.
Select gives me 22 rows. I'm pretty sure I've download much more. Maybe per session?
I saw stuff in there I downloaded days or maybe even weeks ago. (Couldn't tell you exactly when since I've deleted it all now.) I've heard reports of people seeing downloads from years ago.
Here is a SQL to view timestamps:
SELECT datetime(LSQuarantineTimeStamp + 978307200, "unixepoch", "localtime") as LSQuarantineTimeStamp from LSQuarantineEvent
(Based on http://www.forensicswiki.org/wiki/Mac_OS_X with modification.)
In my testing, only downloads from Safari are logged here, not those from Firefox (haven't tested Chrome). If you don't use Safari as your primary browser, that might explain not seeing many downloads.
Here is a SQL to view timestamps:
SELECT datetime(LSQuarantineTimeStamp + 978307200, "unixepoch", "localtime") as LSQuarantineTimeStamp from LSQuarantineEvent
(Based on http://www.forensicswiki.org/wiki/Mac_OS_X with modification.)
In my testing, only downloads from Safari are logged here, not those from Firefox (haven't tested Chrome). If you don't use Safari as your primary browser, that might explain not seeing many downloads.
No, it's permanent. Try the app and I think you'll see a longer history.
Won't even start without admin password, I'll pass.
Apple engineers are not different from the rest of people - deliver first, fix when fails. Wiping tombstones in constantly-syncing environment is a cumbersome piece of engineering.
That's why I'm wary of browser sync as a concept. Maybe it's not as convenient, but I would better transfer bookmarks as an export file, and passwords as a password manager encrypted container. As for browsing history I'm not even sure it has any long-term importance - useful browsed links can be bookmarked, saved to delicious/diigo/pinboard, tweeted, upvoted on reddit/hn, whatever.
FF used to have browser-sync that you could send to your own server. Last I checked they had disabled it, but I wish it could be revitalized.
I didn't try but it doesn't seem to be disabled. They have two guides
Self hosted sync server https://docs.services.mozilla.com/howtos/run-sync-1.5.html
Self hosted accounts server https://docs.services.mozilla.com/howtos/run-fxa.html#howto-...
The latter includes instructions about how to add the accounts server url to about:config
Self hosted sync server https://docs.services.mozilla.com/howtos/run-sync-1.5.html
Self hosted accounts server https://docs.services.mozilla.com/howtos/run-fxa.html#howto-...
The latter includes instructions about how to add the accounts server url to about:config
Both the old and new sync encrypt all data before storing it on the server.
Has anyone heard about an open source extension doing the same thing?
I wanted to make one for Vivaldi but it doesn't use Chromium bookmarks API and there was a discussion about it already where it was said to be implemented with the option to sync on a self-hosted server. (https://forum.vivaldi.net/topic/5816/sync-settings-and-bookm...)
I've also been working on one for Chrome but haven't had time lately to work on it.
Firefox has the ability to save bookmarks and all settings for that matter to a local folder upon closing the browser, you could then use an open source and hopefully encrypted sync tool to replicate those backups. Might be a bit clunky at first but if it catches on I'm sure one of the open source sync tools will come up with some sort of integration.
Original, non-blogspam article: http://www.forbes.com/sites/thomasbrewster/2017/02/09/apple-...
That's not good, but at least they had this going for them?
> Unlike most iCloud data, the records don’t seem to have been accessible to law enforcement requests. Apple declined to comment when reached by The Verge.
> Unlike most iCloud data, the records don’t seem to have been accessible to law enforcement requests. Apple declined to comment when reached by The Verge.
I would like more clarification as to what this means. Does this mean the histories are purely client-side? If that's not the case, I don't see how they can make this claim.
>If that's not the case, I don't see how they can make this claim.
Nobody knew it was even available?
Nobody knew it was even available?
That whole sentence seems mistaken since no iCloud data is available to law enforcement. iCloud is AES encrypted with keys that are held by the user-only (not Apple).
As people have pointed out, yes, Apple is a trusted part of the system and could release a new iOS/macOS update that captures these keys but short of that, neither Apple nor law enforcement have any access to your iCloud data.
As people have pointed out, yes, Apple is a trusted part of the system and could release a new iOS/macOS update that captures these keys but short of that, neither Apple nor law enforcement have any access to your iCloud data.
I think Apple has keys for your iCloud data.
"iCloud uses a minimum of 128-bit AES encryption and never provides encryption keys to any third parties."
If I interpret this correctly I am first party, Apple is second and third is everyone else.
https://support.apple.com/en-us/HT202303
"iCloud uses a minimum of 128-bit AES encryption and never provides encryption keys to any third parties."
If I interpret this correctly I am first party, Apple is second and third is everyone else.
https://support.apple.com/en-us/HT202303
[deleted]
backup system probably supports do not follow links, just need to add safari cache to the list. seems pretty innocuous. And if you are doing illegal stuff in your non-private browsing session, on a device that automatically backs up all of your data to the cloud... pretty sure you've left plenty of paper trail elsewhere.
wildchild(1)
Doesn't matter, it's Apple and not Microsoft or Google, all is forgiven.