IndexedDB on Safari has had issues it feels like since day one. IIRC there was a full rewrite somewhere along the way too, and still problems seemingly every Safari release. My favorites were the iOS upgrades that simply deleted all IDB data.
Super frustrating, makes me glad I’m not currently building anything that relies on significant local storage.
The web could fill so many needs instead of using apps, but with crap like this it’s no surprise that it still doesn’t.
The title is too sensationalized. It leaks the names of IndexedDB databases.
This can in cases where the names follow a known pattern be used to infer domains of other websites in the session and, in the case of YouTube, your Google id which can be used to identify your Google account.
The vulnerability doesn't leak all your browsing history. It leaks a small part of it
It's very interesting seeing exploits like this from this organization. On one hand their service fingerprints users and offers extended metadata like whether the user is in incognito via sketchy web apis.
On the other hand they report (and help close) some gnarly exploits like this via sketchy web apis.
What do you all make of this? It's hard to not see it as some weird "were not doing a bad thing" gaslighting (perhaps even internally to their team).
IndexedDB isn't sketchy, just annoying. It is the only semi-reliable way to store more than a few MBs of data with JS, but the API is awful and it's a pain to use without some kind of wrapper to make it bearable. (LocalForage is good, it provides a LocalStorage-like API on top of IndexedDB or some other APIs in older browsers.)
I had the same thoughts; it seems to present a friendly picture but there are a lot of unanswered problems with this technology, even if only used for fraud protection.
What if clients use it for tracking and other shady purposes, would they do something about it?
Btw I tried with Tor Browser and it did not accurately fingerprint it between sessions which makes me wonder how effective it really is. Especially for fraudsters; intentional bad actors, I think it would be quite easy to bypass.
It's sad how buggy IndexedDB is in Safari, and in general how much pain Safari causes to web developers and consequently their users.
I hope regulators will eventually force support for other browsers (that can install apps) in iOS, I don't understand how Apple is allowed to have such a tight control on the market.
The way they describe the behaviour when the dev tools are used with undeletable database copies being created, this just looks like the whole area is buggy. Which is of course not an excuse for this, but might also indicate that there could be even more attack surface there.
It would seem I’m not alone in thinking that many web features are too implicit. “Dialog fatigue” or “ok-click syndrome” are real problems, but for many features I think the correct behavior is probably not a silent grant. Anything that consumes the user’s resources after navigating away from the page should probably require direct user consent in some form or another.
Yep... look at just the cookie prompts,.. they suck, the users just click "agree", and if they want to disagree, they have to invest sometimes literal minutes, to unheck all the cookie providers.
The default should be always to delete everything after a website/tab is closed. Want to store a login? Set up a button next to the url bar to enable persistant storage for that specific webpage, and you're done.
Almost every web page demands a login today...you want to be the browser vendor dealing with the literal billions of users lodging complaints because they forget to click the save button before closing a tab and now they have to log in again?
I think it would work well if installing web apps as PWAs, with the PWAs’ webviews being sandboxed and backed by their own entirely separate storage, cookies, etc, was what enabled persistent features. It would eliminate several types of fingerprinting in one fell swoop.
Cookie dialogs are set up that way because they know people will agree. A website I visit regularly (and have a subscription for, soundonsound.com), had a very easy cookie dialog. But no longer. Now you must accept their cookies (it’s quite a lot, really). One can only guess why.
People would then just be trained to always click that button, even preemptively, as a magical fix button. And we'd get a whole new Youtubey "remember to smash that button!" but for every website.
Given that there’s really no way around Safari on the iPhone, developers should perhaps just not use IndexedDB if the browser is Safari, given how buggy the implementation is.
It pretty clear that Apple isn’t giving Safari/WebKit the focus it needs, but it’s also clear that developers just continue to push for more and more features in the browser. I’d much prefer that browsers started to cut back. While Google is excellent about updates, remember that critical bugs are found in Chrome constantly.
The problem is there's no alternative. LocalStorage is synchronous and has low limits, but works OK for things like preferences and auth tokens. If you are doing anything bigger like editing files then IndexedDB is your only option.
Maybe the way forward is to forge ahead without Safari, until pressure from customer forces them to implement this (and other web features).
Already on chrome we can go to a URL, click the 'install' button, and have an app on our desktop/homepage. No app store, no massive download. I sincerely hope this is the future and not brilliant dead-end HN will be nostalgic about in 10 years.
new bugs all the time too. in iOS 13 i found a bug where getting data from a store by key would ignore whatever store you pass it, so it would return data from every store that matched the key.
I rarely (never?) see Apple engineers posting in these threads. With other big tech organizations some kind of insider insight is occasionally provided.
Is Apple’s culture of secrecy that strong? Is it a sense of superiority? Is it embarrassment? Are they just not here?
As a mid-career engineer with highly marketable skills and an inbox stuffed with job offers the only two companies I would never entertain an offer from are Facebook and Apple.
Facebook because their fundamental purpose for existence is harmful to society and Apple for their perceived (or actual?) engineering incompetence.
I don’t really have a sense for the kind of engineer that works for Apple. With other big tech orgs I have some sense, even if informed almost entirely by tech forums.
I believe it’s considered a durable offence to give out secret information at Apple. Similar, with few exceptions, Apple employees are not allowed to contribute to open source projects.
It’s a shame really, because otherwise I think I’d quite like working at Apple. Their laser focus on product is right up my street.
My perception of Apple’s (software) engineering capabilities comes from being their customer and using their products daily.
This might be different if I had some perception of what was happening internally or how problems are approached. But from what I see nobody at Apple cares. So the silence contributes to the perception of incompetence by not counter-acting it.
As engineers, we all know that there are different circumstances. Sometimes they are technical, sometimes political. I would say we should always assume goodwill, unless proven wrong. This is irrespective of whether we talk about Apple, Google, Microsoft, Facebook or any other company.
> As engineers, we all know that there are different circumstances. Sometimes they are technical, sometimes political.
Agree. I'm just curious what it is at Apple. Their hardware seems fine, even excellent. But the software is really not at the same level. So I wonder how that happens.
> But from what I see nobody at Apple cares. So the silence contributes to the perception of incompetence by not counter-acting it.
There isn’t silence though. The world doesn’t begin and end at Hacker News. Head over to Twitter, for instance, and you’ll see plenty of Apple developers talking about their work. Or join the WebKit mailing lists or Slack. Or join the Swift forums.
How is this not a P1 thing in the iOS/iPadOS/macOS/security teams at Apple? Seriously? Bare minimum, why didn't they let people know about this? We know the whole "we care about privacy" thing is marketing fluff now but holy F this is just unacceptable.
And this kind of an issue is exactly why Apple needs to stop screwing around and do the following things ASAP:
1. Decouple Safari from the OS so that it can be updated independently to fix critical issues like this and deploy to all customers quickly
2. Let other browser engines on the platform for fuck's sake!
Number 1 is number one on my list. I am literally (right now) just installed an old MBP from an empty disk. Literally could not use Safari to download another browser because it’s “updating.” So I’m literally watching a 10 minute progress bar just to download a browser.
It’s clear that Safari is not a top prio at Apple, even though it’s probably the most important app on their operating systems. Contrast with Google that needs Chrome to exert their control over the web.
Well, Apple does promote native apps a lot nowadays, whereas Google has mostly webapps (think ChromeOS), so Google can't really afford to have Chrome broken.
Is it usual to disclose (what appears to me to be) a vulnerability with massive potential for exploitation towards disastrous ends, before the developers of the software have shipped a fix?
I guess I'm curious as to what the norms are around disclosure of such discovered vulnerabilities are in general.
It's a hot topic of debate. Some people advocate for full disclosure, which means tell everyone as soon as you find it. The idea behind that is that attackers might have already found it and be exploiting it, so people should know in order to protect themselves. Others advocate for coordinated disclosure (sometimes called responsible disclosure, a controversial term[1]), with some sort of time limit. Google Project Zero does that with a 90-day time limit, with some exceptions to extend it or reduce it[2].
You have a point. I initially misread the article as suggesting that the entire DB from other sites was leaked.
Still though:
> Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This means that authenticated users can be uniquely and precisely identified. Some popular examples would be YouTube, Google Calendar, or Google Keep. All of these websites create databases that include the authenticated Google User ID and in case the user is logged into multiple accounts, databases are created for all these accounts.
Well, only if the alternatives are, overall, more secure and private than Safari.
I tend to doubt that's true, mainly because, by far, the most likely alternative is Chrome, and Chrome is specifically designed to leak its users' personal information to Google's customers (the ones that generate the bulk of their revenue, that is).
But for privacy, sacrificed by all of them out of the box (yes, Firefox is a noisy SOB too, no I won't dig up the articles people have written on the traffic captured for you).
Your settings are very, very important to your browser privacy, regardless of which.
Well, don’t get caught up in unimportant distinctions. Security vs. privacy depends on the relationships between the subject of data, the holder of data and those seeking to use the data. Consider the relationships between browser end users, Google, and the parties who provide Google’s revenue. If we want to distinguish privacy from security here, we have to argue about how to characterize these relationships and hash through the details of the flow of data. It’s pointless and unhelpful.
I would trust Chrome to flash GrapheneOS to my Pixel — that's security.
I do not trust it not to report back that I use GrapheneOS, or which internet communities I visit, back to Google for use in who knows what data correlation research — that's privacy.
But I wonder what your definitional difference is.
I think a security issue is one that allows another party to take information or property you have without your consent, and use it for their gain without regard for the harm it may do to you or others.
It's arguable, but I believe that's at the core of Google's business model with regard to Chrome users.
of course not. all software is buggy and browsers are no exception but having multiple options available allows you to navigate around the minefield; when one of them gets openly compromised just use another, apple forbids that at the moment.
What a mess Safari has become. It used to be my preferred browser for navigating AND developing but it has become less and less appealing, especially for the latter (I submitted several bugs to webkit, but my love is fading).
Safari is hell nowadays, bad UX, not compliant with web standards - not just whatever API Google comes up this year, but basic CSS that's common and works in every other browser.
At my last web dev gig, we had to go and get Apple hardware because our visual tests kept failing on Safari. They need to get their shit together or let people port good browser engines.
What we need are companies working on browsers that actually care about the web. Apple have demonstrated time and time again that they don't, because they favor native applications on iOS and macOS over anything web, so we end up with subpar browsers who ship with the OSes. In some cases (iOS), we even end up with a browser-monopoly where no other browser is even welcome.
It’s an improvement over the situation as it was, but Google still has a great deal more muscle than anybody else in steering the development of Blink and the web in general.
Really, at this point I think Chrome/Blink should be spun out as a separate entity. It could be set up as a model similar to that of ARM, or perhaps a non-profit of some kind. Either way, Blink needs to be separated from overwhelming corporate influence.
> I think Chrome/Blink should be spun out as a separate entity
Dear god, no, please.
The Chrome team is a treasure of immense value to the world. They are the only major software team in the world where my bug reports have been triaged and fixed. Again and again and again, and usually very quickly too. Ocassionally I would find some hellish obscure corner case of a bug, ignore it, and it would still get fixed even without my reporting it: the team is just unbelievably effective! I wished Google were not selling advertising, but the downsides for Chrome have been fairly limited. The fact that they have given the source code to Chromium away for free is just plain astonishing. I am blown away by how good Google has been as a custodian of something that is used by so many in the world: it has been a fair gift to us all with surprisingly few caveats.
If you don’t like Google’s guardianship then use a derivative browser, even Microsoft Edge!
Split off Chromium and it would likely turn to shit. How many times have I seen browser vendors go down the path of evil? How many times have I seen important software get sold, and the product focus shift to something execrable?
On browsers: the Safari team is a black hole for bug reports, with a browser full of broken or non-compliant functionality… IndexedDB is just one of many similar symptoms. Firefox has the right social goals, but it hasn’t been delivering guru level engineering, but instead Firefox is continually chasing useless queer features (similar to many other now dead products in the world). The Microsoft Edge team did fix one bug report for me once, but I just happened to report it while they were developing the feature, and I had test cases showing the feature working in Firefox and Chrome. I still have trauma from Microsoft IE6+ (although it was a competitive edge for my business that I could usually make it work, albeit at the cost of years of my life devoted to creating IE workarounds).
Edge adopted chromium because microsoft could not compete with their monopoly power to enforce web standards as “however it is implemented in chrome”. If chrome ships a feature, there 80-90% market share means that every other chromium browser has to ship it or they’re “broken” and people switch to chrome.
if the other chromium wrappers have a seat at the table, that isn’t the table that makes the decisions.
It's good that Apple doesn't care about the web, because that means that developers can't rely on the APIs that Apple refuses to implement, meaning that in the end the web ends up with fewer APIs that can be used in practical terms.
Why would you want less api? Overall at the specification level those APIs are secure even if some implementations aren't. Web is a mature application platform at this point and it's being held back by apple.
Apple has been rapidly addressing shortcomings in WebKit and significantly expanding its team over the last year (at least). They’re clearly investing, so they clearly care in that sense. It’s also obvious that that rapid pace and onboarding could produce defects. But I don’t think it’s accurate at all to say they don’t care about the web.
iOS sure but native mac applications are dead, D-E-A-D, muerto, morte, morto etc on macOS and have been almost entirely ejected in favor of web based SAAS and electron apps over the past 4 years.
I genuinely can’t name a native application released for macOS built with AppKit or SwiftUI or whatever that didn’t come from Apple.
Off the top of my head: Nova (Panic's new code editor) and Craft are both pretty new such apps. Acorn and Pixelmator Pro are both image editors that aren't brand new, but aren't quarter-century old incumbents by any stretch. There's the whole Affinity suite of Adobe competitors. And while BBEdit is a quarter-century old incumbent, of sorts, it's pretty far from being in maintenance mode -- and it certainly has company.
It's certainly true that the center of gravity is tilting toward web apps, but not every kind of app makes a good web app, at least yet.
TablePlus looks cool! Also the only one started in the last decade.
Inertia is the most powerful force in the universe, and gravity is up there as well. Adobe & Microsoft dynastyware dating back to 1990, and two also rans devoured by the web (Figma/Postman). And TablePlus which genuinely looks cool and gives just enough hope to mourn again.
I’ve come around on Figma these days honestly, but will take Paw’s quality over Postman’s funding any day.
I will say as a former Mac developer who came of age and experience during the Carbon Y2K transition days, the fact you can just expect some form of availability regardless of Linux or iOS or macOS or Chrome or Safari is a genuine fucking achievement for the human race, how far and low we’ve come.
I fully support you. Now, getting rid of obsolete, and dead APIs, and features is way more important than adding new ones.
I can recall a dozen of XSLT implementation bugs which were in Chrome from day 1.
XSLT is not going anywhere from browsers, but they also cannot be fixed, because there is so few people using XSLT today to raise above the noise floor for WebKit devs.
Last IDB shitstorm was discussed at https://news.ycombinator.com/item?id=27509206.