Re: [w3c/IndexedDB] SSD wear: does it sound like a real risk? (Issue #511)

asutherland left a comment (w3c/IndexedDB#511)

I think the fundamental problem is that absent human-level analysis it's impossible for a browser to determine whether a site actually needs storage, whether it's efficiently minimizing its storage use, or if it's got a buggy implementation.  And a real limitation is that most sites will entirely break if denied storage and aren't interested in correcting that.  (That said, note that Firefox's tracking protection mechanism does try and maintain a known set of trackers and either tries to avoid loading the scripts or denies them access to storage.)

This makes it hard for the browser to usefully do anything in terms of informed user consent, especially without creating prompt fatigue problems, as in many cases the situation ends up being "press allow if you want to keep using the site / let the site work" and the user's decision to not close the tab or hit the back button is effectively already the same thing.  That said, I think there is some possibility for browsers to have a storage analog of the "slow site" info-bar Firefox pops up if a site's JS is making the tab/browser unresponsive.  The storage analog could be noting how much I/O the site has done and whether it seems commensurate with the user's interaction with the site (to attempt to mitigate a situation where a user might be using a web video editor and have it suddenly stop working part-way through a long batch process).  But there's again risk with this since if JS is allowed to continue to execute and if there are no data-dependencies on intentionally stalled storage APIs or backpressure handling it may continue to issue requests against storage APIs that accumulate in memory until an OOM happens.  That might be something that could be mentioned non-normatively in the WHATWG storage spec but I'm not sure it would impact specific storage specs like IDB.

I should also note that most browsers do have some kind of privacy-preserving "known bad site" mechanism; Firefox uses Google's [Safe Browsing service](https://safebrowsing.google.com/) as does Chrome, and I believe Edge has its own database.  In the event there are sites out there intentionally and maliciously, that's arguably a major part of a mechanism for mitigating, especially since that can be augmented by automated crawling that detects hostile patterns/runtime behaviors but without slowing individual user's browsing or needing their private usage data.

In terms of buffering, because IndexedDB explicitly has transactional semantics (which section 2.7 calls "durable"), I think specifying any kind of memory buffering would be at odds with the spec.

But I'd also note that buffering IDB data in memory could itself lead to SSD churn by causing virtual memory swapping (to SSD), although my greater concern would be causing browser OOM crashes.  https://data.firefox.com/dashboard/hardware says that users with 8GB of RAM are still the most populous.  I think there's also the question of whether a site that could safely fit its IDB data in memory is the kind of site that actually would be causing high levels of SSD churn.  (A caveat is trackers again might fit this classification, as it is an unfortunately common idiom for sites to want to report user activity on the site and to buffer it to storage in case of transient transmission failure, although we expect that to be O(user activity on the site) rather than a non-stop I/O flood.  But again in Firefox if we can know something is a tracker we have special user-controllable handling that attempts to mitigate the tracking entirely rather than the I/O impact.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/511#issuecomment-6725385964
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/511/6725385964@github.com>