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