[HN Gopher] Exploiting IndexedDB API information leaks in Safari 15
___________________________________________________________________
Exploiting IndexedDB API information leaks in Safari 15
Author : danpinto
Score : 168 points
Date : 2022-01-15 16:05 UTC (6 hours ago)
(HTM) web link (fingerprintjs.com)
(TXT) w3m dump (fingerprintjs.com)
| iqanq wrote:
| What the web needs is fewer APIs.
| capableweb wrote:
| 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.
| iqanq wrote:
| 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.
| kyriakos wrote:
| 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.
| cmsj wrote:
| 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.
| basch wrote:
| Microsoft has to have wrestled some power away with Edge.
| They have a seat at the table.
| oldsj wrote:
| Edge is just Chromium now
| https://finance.yahoo.com/news/microsoft-edge-chrome-
| chromiu...
| tata71 wrote:
| Chromium is "just" a logical, security first base OSS
| project,
|
| that (theoretically) any org can adopt and strap
| additional modules onto.
| kitsunesoba wrote:
| 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.
| eyelidlessness wrote:
| 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.
| finiteseries wrote:
| 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.
| vehemenz wrote:
| Adobe Creative Cloud, Microsoft Office, Sketch, Paw,
| TablePlus
|
| Just named five I use daily...
| eyelidlessness wrote:
| I mean, I'm not agreeing or disagreeing (and I've felt both
| ways depending on context and mood), but it's not like this is
| an exceptionally new API.
| baybal2 wrote:
| 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.
| oefrha wrote:
| 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.
| tehbeard wrote:
| I'm currently fighting a safari IDB bug where blobs stop being
| returned or all reference the same data.
|
| Apple just doesn't care about IDB or the web.
| matt7340 wrote:
| 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.
| argvargc wrote:
| > and in all browsers on iOS and iPadOS 15
|
| Wow. I wonder what Brave thinks of this?
| streptomycin wrote:
| All browser vendors are very unhappy that Apple only allows
| their browser engine on iOS. For security and many other
| reasons.
| kyriakos wrote:
| Security in this case is broken by actually forcing the
| browser engine monopoly on ios.
| jmull wrote:
| 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).
| kyriakos wrote:
| The problem is when a zero day is found on safari engine
| there's no alternative one can use till it gets patched.
| tata71 wrote:
| 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.
| sangeeth96 wrote:
| 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!
| withinboredom wrote:
| 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.
| [deleted]
| parhamn wrote:
| 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).
| matkoniecz wrote:
| Maybe they help to close exploits used by competition?
|
| Or ones they are not planning to use anyway, but are possible
| to be used by competition?
|
| Or for marketing purposes to be not known as 100% clearly evil?
|
| Or for marketing purposes to be better known?
| toomuchtodo wrote:
| Managing the Overton window and anchoring wrt browser tracking.
| easrng wrote:
| 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.)
| codeptualize wrote:
| 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.
| mobileexpert wrote:
| Apple's tight-fisted control of browser engines on iOS leads to
| worse security and privacy for the whole platform.
| fabian2k wrote:
| 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.
| cmsj wrote:
| it's almost like allowing websites to silently create databases
| on our computers, was a bad idea.
| jmull wrote:
| This doesn't really have anything to do with IndexedDB being
| about databases.
| kitsunesoba wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| tgv wrote:
| 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.
| kitsunesoba wrote:
| 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.
| nexuist wrote:
| 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?
| ajsnigrutin wrote:
| How many sites are you actually logged into? I can count
| maybe 4, 5, and out of that, i use maybe 2 daily.
| nexuist wrote:
| No joke - at least 50. I use maybe 10 daily, and the
| other 40 I check monthly.
| hombre_fatal wrote:
| 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.
| fabiospampinato wrote:
| 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.
| davidatbu wrote:
| agys wrote:
| 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).
| cerved wrote:
| 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
|
| edit: title is changed now
| mulmen wrote:
| 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.
| gleenn wrote:
| Why does (near) silence equate to incompetence?
| mulmen wrote:
| 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.
| evercast wrote:
| 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.
| [deleted]
| mulmen wrote:
| > 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.
| ksec wrote:
| >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.
| mulmen wrote:
| Maybe I'm just not reading the right threads then. It's all a
| perception.
| tata71 wrote:
| Maybe you're not checking the right commenter's user bios
| ;]
| nicoburns wrote:
| 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.
| [deleted]
| anony23 wrote:
| meibo wrote:
| 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.
| michelb wrote:
| 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.
| [deleted]
| keewee7 wrote:
| The IndexedDB API in Safari has been buggy and unstable for a
| very long time.
| mrweasel wrote:
| 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.
| easrng wrote:
| 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.
| LAC-Tech wrote:
| 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.
| gwill wrote:
| 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.
___________________________________________________________________
(page generated 2022-01-15 23:01 UTC)