Live data from Hacker News

Exploiting IndexedDB API information leaks in Safari 15

fingerprintjs.com

61–70 of 99 posts

Re: Exploiting IndexedDB API information leaks in Safari 15

#61

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.

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.

Adobe Creative Cloud, Microsoft Office, Sketch, Paw, TablePlus

Just named five I use daily...

Re: Exploiting IndexedDB API information leaks in Safari 15

#62
post #2

The IndexedDB API in Safari has been buggy and unstable for a very long time.

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 ex…

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#63
post #49
post #47

Earlier quoted context omitted.

>I rarely (never?) see Apple engineers posting in these threads. You mean on HN? Oh they do, From JSC to Webkit Engineers. Mostly on technical discussions.

Maybe I’m just not reading the right threads then. It’s all a perception.

Maybe you're not checking the right commenter's user bios ;]

Re: Exploiting IndexedDB API information leaks in Safari 15

#64
post #29

Earlier quoted context omitted.

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

Security ≠ privacy.

This is well-tread, mistaken path.

Chromium > all, for security.

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#65
post #2

The IndexedDB API in Safari has been buggy and unstable for a very long time.

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 ex…

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#66
post #39

Earlier quoted context omitted.

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?

How many sites are you actually logged into? I can count maybe 4, 5, and out of that, i use maybe 2 daily.

Re: Exploiting IndexedDB API information leaks in Safari 15

#67
post #39

Earlier quoted context omitted.

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?

How many sites are you actually logged into? I can count maybe 4, 5, and out of that, i use maybe 2 daily.

No joke - at least 50. I use maybe 10 daily, and the other 40 I check monthly.

Re: Exploiting IndexedDB API information leaks in Safari 15

#68

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 update…

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#69

Earlier quoted context omitted.

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.

Adobe Creative Cloud, Microsoft Office, Sketch, Paw, TablePlus Just named five I use daily...

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.

Re: Exploiting IndexedDB API information leaks in Safari 15

#70

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

[1] https://news.ycombinator.com/item?id=12308246

[2] https://googleprojectzero.blogspot.com/2021/04/policy-and-di...

Post reply on HN