Any more info I can provide? On Wednesday, January 22, 2025 at 11:42:20 AM UTC-5 Reema A wrote:
> 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/aa8719be-df07-4e3f-944b-b730389ba56dn%40chromium.org.
