On Wed, Dec 18, 2024 at 5:32 PM Mike Taylor <miketa...@chromium.org> wrote:
> We discussed this in our OWNERs meeting, and agreed this should be an I2S > that requires 3LGTMs to ship. But, we can just use this thread - no need to > send more mail. Some other folks have other questions, but I'll let them > send them independently. > On 12/13/24 12:57 PM, Mike Taylor wrote: > > Thanks Reema - these are helpful answers. And it seems you're most of the > way to an I2S here - I think "PSA" was probably the incorrect category. > > > We have manually looked at how sites seem to be using > navigator.storage.estimate() and most of the cases we’ve seen seem to be > using it for incognito detection. > > I'd like to better understand the risk to sites who are not using this for > incognito detection. Could you do a random sampling of say, 10 non-FP > usages of quota estimation and see if they are in fact handling > QuotaExceededErrors? > > One more question: what are the actual Quota limits for storage on mobile > (including low-end devices), and WebView? Are any of them lower than 10GiB? > On 12/12/24 1:41 PM, Reema A wrote: > > Thanks for the feedback. Wrote out some more details and answers to > questions that have been asked below: > > *Problem:* > It is trivially easy to detect if a user is in incognito mode through the > Storage Manager’s estimate API because the amount of storage made available > in incognito mode is significantly smaller than in regular mode. We have > found some libraries that seem to be taking advantage of this fact and > using navigator.storage.estimate() to detect if a user is in incognito mode. > > Probably a silly question, but why is the storage made available in incognito inherently smaller than regular mode? Couldn't we increase the incognito quotas, while still keeping them ephemeral? > > *Goals:* > Mitigate detecting incognito mode through navigator.storage.estimate() and > navigator.storageBuckets.estimate() > Reduce fingerprinting value of the estimate() API > Allow estimate() to still be functional for sites with unlimited storage > permissions > Leave quota enforcement unaffected > Minimize potential site breakages > > *Non-goals:* > Mitigating all possible methods of incognito mode detection > Mitigating detecting incognito mode through quota exhausted errors > > *Relevant spec:* > The storage spec <https://storage.spec.whatwg.org/#usage-and-quota> > defines quota as follows: “The storage quota of a storage shelf is an > implementation-defined conservative estimate of the total amount of bytes > it can hold. This amount should be less than the total storage space on the > device. It must not be a function of the available storage space on the > device.” > > *Current state:* > The value returned by estimate() is already just an estimate and in some > cases the actual amount of space available to use may be different. > > *Proposed change:* > Return an artificial quota equal to usage + 10 GiB in the Storage Manager > and Storage Bucket APIs estimate() method in both incognito mode and > regular mode. However, continue to return the old value returned if the > site has unlimited storage permission. Additionally, enforced quota will be > unaffected. > > Would that cause issues for sites where `quota`-`usage` < 10GB ? Would developers run a risk of thinking they are safe to save more data when in fact they are out of quota? (I guess I'm not familiar with how developers use `estimate()` today and how confident they are that the estimate is accurate) > > *Details:* > navigator.storage.estimate().quota returns usage + 10 GiB. For storage > buckets, StorageBucket.estimate().quota will return either the requested > quota set when opening the bucket or usage + 10 GiB if the default quota is > being used. > > *FAQ:* > Q: What about sites that rely on the quota value returned? > As mentioned in the spec, the quota is only an estimate and sites should > already be handling QuotaExceededErrors. > > Q: Why not just return some error indicator? > A: This is more likely to unexpectedly break sites. > > Q: Why return the same value in incognito and non-incognito? > A: To ensure that they’re indistinguishable. > > Q: Why 10 GiB? > This number was proposed because it is likely to be sufficiently high > enough that sites are unlikely to change their behavior based on the quota > estimate being too low for their use case. It is also similar to the > Firefox implementation. > > Q: Why not a random value? > This could result in a unique ID that could be used for fingerprinting. > > Q: Why (usage + 10 GiB) and not just 10 GiB? > A: To ensure that usage is always less than the quota estimate to avoid a > counterintuitive behavior that might break a site. > > Q: What do other browsers do? > Firefox: In best-effort mode, Firefox returns the minimum of 10GiB or 10% > of the total disk size. If the origin has been granted persistent storage, > then it returns the min of 8 TiB or 50% of the total disk size. [source 1 > <https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria>, > source 2 > <https://searchfox.org/mozilla-central/source/dom/quota/ActorsParent.cpp#6828> > ] > Safari: The docs > <https://www.webkit.org/blog/14403/updates-to-storage-policy/> say “Note > that the quota is an upper limit of how much can be stored — there is no > guarantee that a site can store that much, so error handling for > QuotaExceededError is necessary. Also, to reduce fingerprinting risk > introduced by exposing usage and quota, quota might change based on factors > like existing usage and site visit frequency.” > > Q: Have you looked at different use cases and how they might be impacted? > We have manually looked at how sites seem to be using > navigator.storage.estimate() and most of the cases we’ve seen seem to be > using it for incognito detection. > > Q: Do we have test coverage? > Yes, we have unit tests, browser tests, and web platform tests. CLs > <https://chromium-review.googlesource.com/q/a:reemaa+quota> > > Q: What if sites break? > Developers can disable this change via > chrome://flags/#predictable-reported-quota to validate if this is the > cause of the breakage. We can also flip the flag off via Finch if needed. > > *Notes:* > This is based on an investigation and solution proposed by > t...@chromium.org. > > Thanks! > Reema > > On Monday, December 9, 2024 at 6:18:21 AM UTC-5 Mike Taylor wrote: > >> On 12/6/24 5:48 AM, Chromestatus wrote: >> >> Contact emails ree...@chromium.org >> >> Specification None >> >> Summary >> >> Report a predictable storage quota from StorageManager's estimate API for >> sites that do not have unlimited storage permissions. It is possible to >> detect a user's browsing mode via the reported storage quota because the >> storage space made available is significantly smaller in incognito mode >> than in regular mode. This is a mitigation that prevents detection of a >> user's browsing mode via the storage API by reporting an artificial quota, >> equal to usage + 10 Gib, in all browsing modes for sites with limited >> storage permissions. Sites with unlimited storage permissions will be >> unaffected. Enforced quota will also be unaffected. >> >> A small explainer (or more details) would be useful here, it's not >> immediately obvious what changes you're proposing to make. Are we making >> this change only to incognito mode, or to regular mode as well? Do we need >> to update a spec somewhere, or is this already allowed (pointer to the >> relevant spec would be useful)? >> >> Blink component Blink>Storage>Quota >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EQuota> >> >> TAG review None >> >> TAG review status Not applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> Could you flesh out interop and compat risks here please, i.e. What do >> other browsers do? What do we expect to break (or not) as a result? You >> mention Incognito mode detection (I'm making an educated guess that "user's >> browsing mode" refers to) - have you looked at different use cases and how >> they might be impacted? Do we have test coverage? >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> None >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? No >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? No >> >> Flag name on about://flags predictable-reported-quota >> >> Finch feature name StaticStorageQuota >> >> Requires code in //chrome? False >> >> Tracking bug https://issues.chromium.org/issues/369865059 >> >> Estimated milestones >> Shipping on desktop 133 >> Shipping on Android 133 >> Shipping on WebView 133 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> None >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/4977371751645184?gate=4955779474653184 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/675211ae.050a0220.55f02.00d8.GAE%40google.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/675211ae.050a0220.55f02.00d8.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/866e1227-d7b2-4a7c-bb9e-026cdfc376f7%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/866e1227-d7b2-4a7c-bb9e-026cdfc376f7%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJRJ5Z486%3Dbd%3DM8od%2BJdfBE2G8D%3D%3DLbzjnYQmxbc-K2NA%40mail.gmail.com.
