Live data from Hacker News

Exploiting IndexedDB API information leaks in Safari 15

fingerprintjs.com

21–30 of 99 posts

Re: Exploiting IndexedDB API information leaks in Safari 15

#21
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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#23
post #15

Earlier quoted context omitted.

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.

What we need is the web to stop coalescing ever more tightly around Google. Apple's iOS browser monopoly is literally the only thing preventing Google from having a near total monopoly on web standards.

Microsoft has to have wrestled some power away with Edge. They have a seat at the table.

Re: Exploiting IndexedDB API information leaks in Safari 15

#24
post #13

Earlier quoted context omitted.

it's almost like allowing websites to silently create databases on our computers, was a bad idea.

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#25
Safari 14 had this nasty IndexedDB bug last year: https://bugs.webkit.org/show_bug.cgi?id=226547 and I had to add https://github.com/jakearchibald/safari-14-idb-fix to all my sites using IndexedDB. Now this. Why the hell are they messing with IndexedDB?

Last IDB shitstorm was discussed at https://news.ycombinator.com/item?id=27509206.

Re: Exploiting IndexedDB API information leaks in Safari 15

#26
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!

Re: Exploiting IndexedDB API information leaks in Safari 15

#27
post #13
post #8

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's almost like allowing websites to silently create databases on our computers, was a bad idea.

This doesn't really have anything to do with IndexedDB being about databases.

Re: Exploiting IndexedDB API information leaks in Safari 15

#28

Earlier quoted context omitted.

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.

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#29

Earlier quoted context omitted.

All browser vendors are very unhappy that Apple only allows their browser engine on iOS. For security and many other reasons.

Security in this case is broken by actually forcing the browser engine monopoly on ios.

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).

Re: Exploiting IndexedDB API information leaks in Safari 15

#30
post #23
post #15

Earlier quoted context omitted.

What we need is the web to stop coalescing ever more tightly around Google. Apple's iOS browser monopoly is literally the only thing preventing Google from having a near total monopoly on web standards.

Microsoft has to have wrestled some power away with Edge. They have a seat at the table.

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.

Post reply on HN