On Tue, Jan 21, 2025 at 8:08 PM Reema A <ree...@chromium.org> wrote:
> Sorry for the delayed response! > > > 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? > Quota is 60% of total disk space per origin. For UMA-enabled Chrome > installations on Android, ~3% of weekly active clients have less than > 16.67GB of total storage and thus less than 10GB of quota. > For WebView, we can't get per-device quota numbers; we can only get data > about the number of UMA records, which means some devices will be counted > multiple times. With that caveat, <4% of UMA records come from devices with > less than 10GB of quota. The fraction of low quota devices may be similar > to the fraction of records, but this cannot be verified. > > > 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? > I looked at a few examples. > > Methodology: > - I searched in the Sources tab in Developer Tools for scripts using > estimate() and checked if the same script had references to > QuotaExceededErrors. > - I skipped scripts that seemed to just be logging the quota estimate to > the console. > - I skipped scripts that seemed to be fingerprinting, which was the > majority of examples. > > Major caveat: It’s very hard to tell what these sites are doing due to > code minification, obfuscation, the lack of context, etc. > > I found 9 examples I looked at that were not obviously fingerprinting, > although I couldn’t always tell what they were using the API for. Of these, > I saw references to QuotaExceededErrors in 5 instances. > Is it possible to test these instances out with the flag for this feature, to see if they are likely to break or not? > > On Thursday, December 19, 2024 at 2:54:55 PM UTC-5 Reema A wrote: > >> > 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? >> >> Still working on sampling some sites to provide this analysis, will get >> back to you ASAP. So far the only one I’ve found that doesn’t have minified >> JS and have been trivially able to Ctrl+F for relevant strings does seem to >> be handling the error. >> >> > 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? >> >> There is some data on this available internally here >> <https://uma.googleplex.com/p/chrome/timeline_v2?sid=9ee25b5a495da6245b706c020008ea0e>. >> I’ll see if I can follow up with more specifics. >> >> > 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? >> >> Incognito uses in-memory storage only to avoid data leaks to persistent >> storage. In theory this could be changed and it would fix the underlying >> problem but doing so would be a much, much larger effort (for example, >> here’s >> <https://docs.google.com/document/d/1RzkoiCx_ZgffCPo5iWXDC9mzywCG95gNjyanmqt0bs4/edit?tab=t.0#heading=h.7nki9mck5t64> >> a prior proposal). I don’t think there’s a way to increase incognito quota >> to be significantly closer to non-incognito quota while still using >> in-memory storage. >> >> > 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) >> >> Yes, it’s possible, but as mentioned in my reply above sites should >> already be handling QuotaExceededErrors since the estimate can already be >> quite different than the actual quota (more data about this to come as per >> Mike’s request). >> >> On Wednesday, December 18, 2024 at 11:40:15 AM UTC-5 Yoav Weiss wrote: >> >>> 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/CAOmohSKvjpg0t3QLvC%2Bi_%2BOPZD44tR%3DfgRU5zhai_2aMKdeEeQ%40mail.gmail.com.
