Sure, I enabled the flag in Chrome Beta and navigated around each of the examples. I didn't notice any issues. However, since as I mentioned I'm not sure how they're using the API, I can't ensure I'm using up quota. On Wednesday, January 22, 2025 at 9:47:24 AM UTC-5 Yoav Weiss wrote:
> 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/52931d13-91e2-4197-bf57-10bfbb4fe383n%40chromium.org.
