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.
*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.
*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
<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
<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
<mailto: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>.
