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
<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>.
--
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/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>.
