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. 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/fcb7e266-cf11-433e-a848-ab7636be24ecn%40chromium.org.
