Apple Fails To Remove 'Deleted' Safari Web Browser Histories From iCloud (betanews.com) 29
Reader BrianFagioli writes: Apple was storing Safari browsing histories in iCloud, even after they had been 'deleted' by the user, with such records being kept going back to 2015 -- although apparently this was an accidental by-product of the way the cloud syncing system works rather than anything malicious, and the issue has now been fixed. This information first came to light in a Forbes report, which cited Vladimir Katalov, the chief executive of Elcomsoft, a Russian security firm (which focuses on password/system recovery). Katalov stumbled onto the issue when reviewing the browsing history on his iPhone, when he discovered his supposedly deleted surfing history still present in iCloud, being able to extract it by using his company's Phone Breaker tool.
Backup and Syncing (Score:1)
This is what happens when you combine a syncing service with a backup service into one product. Though browser history doesn't offer versioned restores as far as I'm aware, so this is probably just poor planning and design.
Re: (Score:3, Informative)
As reported by MacRumors [macrumors.com] The deleted browser history was listed in a record called literally named "tombstone" that was separate from other iCloud functions.
That doesn't like an accidental defect in design in any sense.
Re: (Score:2)
Oh it's definitely intentional in some respect. It's probably based in a fear of accidental mass data corruption/deletion, that they can still successfully recover from. Or maybe an abandoned attempt at versioning that they thought they might want someday.
Re: (Score:2)
> It's probably based in a fear of accidental mass data corruption/deletion
Wait, so the one part of your ios device- which may store documents you need professionally, financially relevant documents, or even irreplaceable personal stuff- that gets this special "deleted just means moved to a special hidden place" treatment is YOUR BROWSER HISTORY?
Lets be real here, there's no way that's possible. And this is a backup copy of USER DELETED items, mind you.
Re: (Score:2)
Data stored on the IOS device isn't synced between devices. Is browser history?
The "backup" in question is on the device, not iCloud (which follows a sane retention policy, I think FTA). It's just being controlled by iCloud.
I'm not saying they were giving it a special status - just that they abandoned something they started and never cleaned up after themselves.
Re: (Score:2)
Yes, browser history is synced between everything - Macs and iOS devices all share the browser history. So if you visit the site on your Mac, you can revisit it on the road on your iPhone or iPad by browsing your Mac's browser history.
Of course, this then raises the question of what does it show if you haven't touched the browser on your Mac in a little while? Say you last used it a month ago, and you've been referencing the mont
Re: (Score:2)
Keeping some deleted data would be useful for syncing, since it could resolve whether it was "deleted" rather than just missing on the device that doesn't have it. I assume that's what the 2-week retention of deleted stuff was for in the first place.
This whole thing just sounds like a bug where the items retained as essentially just syncing metadata never got properly deleted.
Re: (Score:2)
When you upgrade your Firefox web browser, the old cache directories still remain there in .mozilla/firefox/*.defaulted.
Law enforcement have always been pushing for Internet usage and browser histories to be archived. Remember the fuss over various Windows media players sending back lists of movies watched.
Re: (Score:1)
iCloud most likely uses Cassandra in at least some parts, and tombstones are simply how distributed deletes are in done by this DB and a lot of other NoSQL databases.
Educate thysefl: http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html
And I speculate that iCloud is likely using Cassandra because Apple has contributed significant patches to it. Cassandra's website says that Apply has over 75,000 nodes.
Re: (Score:1)
This is what happens when you combine a syncing service with a backup service into a cloud product.
FTFY
accident my ass (Score:5, Insightful)
"Accidentally", yeah... I've got a bridge to sell, cheap, then.
As details of this case are not yet know, let's take a look at Google's 8.8.8.8. It is widely advertised as anycasted, and indeed, it is. However, have you noticed that, no matter where you are, all those anycast targets are located in a single country, despite the very purpose of anycast being geographic proximity? You can't suspect Google of technical incompetence, what could the real reason be, then?
Let's see... we have 2nd most nosy company, all targets are in the 1st most nosy country, both of which have extensive machinery to cross-match this kind of data. But, Google is perfectly capable of serving DNS from any of their datacenters, and only then coalescing the logs, so they have no incentive to degrade user satisfaction they'd be able to trivially fix. Thus, it's clear who's evil here.
So, is your resolver set to 8.8.8.8 or 8.8.4.4? Do you enjoy the metadata on every single TCP/IP connection you make that's not using a numeric literal being logged by someone who received a nice fat NSL?
I guess that Apple, with all their evilness elsewhere, is not the party to blame here.
Re: (Score:2)
As details of this case are not yet know, let's take a look at Google's 8.8.8.8. It is widely advertised as anycasted, and indeed, it is. However, have you noticed that, no matter where you are, all those anycast targets are located in a single country, despite the very purpose of anycast being geographic proximity? You can't suspect Google of technical incompetence, what could the real reason be, then?
That there are only Google DNS servers located in that one country, perhaps?
Even if the service is supposed to route based on geography -- it can only go to servers that actually exist. Even if Google has offices in many places, they don't necessarily recreate all their individual services in every office for every market to route to.
Re: (Score:2)
They already have more than one physical server, so spinning up another one in a different location is trivial for them -- if someone gets such automation right, it's Google. And the benefit to users is high, as you issue a DNS request before every single connection, so you shave >100ms every time.
As an extremely competent company, I don't even entertain the though they didn't consider this. Hurting users while giving themselves no benefit is so unlike Google that targetting the blame is obvious.
Re: (Score:2)
They already have more than one physical server, so spinning up another one in a different location is trivial for them -- if someone gets such automation right, it's Google.
I would suggest they want to keep all the servers in the U.S. for legal reasons perhaps (I don't what that would be).
Re: (Score:2)
You have far more to lose due to browser fingerprinting than you do with DNS requests
Browser fingerprinting goes over SSL so the three letter agency would need to NSL every single hosting company, which is too much work even in the US, and impossible on those without US presence. On the other hand, DNS requests are issued before every single connection (no browser/etc caches them), work for every protocol rather than just http/https, and, if you can get people to use 8.8.8.8, you get everyone, including employees of Russian government, your campaign donator's competitors, and so on.
and nobody does a single thing about browser fingerprinting
Are you
Re: (Score:2)
Deflect from discussion! Blame competitor A!
I don't like Apple, I consider them the Monsanto of software world, far worse than Oracle or Microsoft, but even if you hate someone, you shouldn't expect them to be always in the wrong.
Except Lennart. He has no redeeming qualities.
Re: (Score:2)
So, is your resolver set to 8.8.8.8 or 8.8.4.4? Do you enjoy the metadata on every single TCP/IP connection you make that's not using a numeric literal being logged by someone who received a nice fat NSL?
If the government wants my metadata, they will ask my ISP for it under another NSL, which my ISP will not bother to fight as they are barely staying in business as it is. (Their hardware is frequently on the blink, they pay the lowest wages in the industry...) Then my ISP will log all my DNS (and whatever) activity, burn it to a fucking DVD because the FBI is in the stone ages, and hand it over.
Re: (Score:2)
they will ask my ISP for it under another NSL, which my ISP will not bother to fight
This is a concern for you, yeah. But I for one don't live in the US, and would really prefer my metadata to not be given to your spooks. Those in my country can't find their ass with both hands, so while just as vile (our current govt in Poland is outright national socialist), they don't know how to get useful info from Internet data.
Re: (Score:2)
Hmm, correction... I did investigate this a few months ago, and 8.8.8.8 + 8.8.4.4 led to servers in the US both from machines in all locations I control, and from a bunch of random public tools [traceroute.org] to do so. I just re-checked, it seems to be fine today, with pings that can't possibly go to the US.
So something must have changed...?
Don't trust proprietary SW or their services (Score:1)
It appears that multiple posters are buying right into the unproven, undefended assertions the article makes. A couple of strong claims go well beyond the article author's knowledge.
For all one knows, Safari, a proprietary program running on proprietary OSes, uploads data to the