LGTM2
On Wednesday, January 21, 2026 at 5:03:36 PM UTC+1 Barry Pollard wrote:
Done. Apologies as I thought API reviewers approved first (my
first feature change!).
On Wed, 21 Jan 2026 at 15:49, Vladimir Levin <[email protected]>
wrote:
Hey,
Can you please request various review chips as well? (Privacy,
Security, etc)
Thanks,
Vlad
On Tuesday, January 20, 2026 at 3:11:47 PM UTC-5
[email protected] wrote:
It seems like a bit of a design footgun to have
different thresholds across platforms, and we do see
16+GB Androids very commonly, so I'm wondering if we
can't use a unified list in the update?
I'm not averse to keeping them the same and this is
something I brought up with the WebPerf WG when I
discussed this as I too would have preferred not to have
different limits.
However, saying that, 16GB on Android still seems super
rare from our own internal stats (unfortunately I don't
have approval to share exact details) and 32GB even more
so. Rarer in fact than some of the values I'm proposing
dropping here for privacy reasons. I've also looked at
this globally, and again that introduces more concerns for
certain regions.
Then again, they may not be rarer than the 8GB was when
the original API was added. And, as you point out, they
are only likely to become more common.
If you and the other API owners feel strongly about this,
I can speak to Privacy about this (and they'll need to
sign this off anyway) and/or seek permission to get stats
to share. But my personal point of view is with the limits
I've recommended for now, despite the fact they differ
between device type. Hopefully with the precedent being
set here, and some of the spec work to make this easier to
update in the future having been completed already, adding
16GB or above when the time is right won't be as big or a
burden in the future.
As you know, it has been an ongoing frustation of mine
that these values (and those for networks in netinfo)
are so outdated.
I did wonder about netInfo when making this change, but
personally I've become convinced that the ECT buckets are
not good and not worth updating. I think the RTT value is
a better one (and in Chrome ECT is currently only based on
RTT anyway since Downlink proved less reliable, so doesn't
match the spec) and doesn't require updating. So my
preference is to retire ECT and depend on RTT instead,
perhaps with non-normative advice on how to group them
into categories. But anyway, that's off topic.
On Tue, 20 Jan 2026 at 19:53, Alex Russell
<[email protected]> wrote:
First, wanted to thank you deeply for pushing this
forward, Barry. As you know, it has been an ongoing
frustation of mine that these values (and those for
networks in netinfo) are so outdated.
It seems like a bit of a design footgun to have
different thresholds across platforms, and we do see
16+GB Androids very commonly, so I'm wondering if we
can't use a unified list in the update?
Regardless, a grateful LGTM1 from me.
Best,
Alex
On Monday, January 19, 2026 at 4:02:59 PM UTC-8
[email protected] wrote:
It seems to me that the privacy concerns with
this and similar APIs are primarily concerned
with random webpages. In the case of installed
PWA, IWA, WebExtension, etc, which have a
higher level of trust, it makes sense to me
that the values could be untruncated, both
retaining those smaller values and perhaps
also going upwards beyond 32. What do you think?
Potentially, though I'm not sure we have precedent
for this? Or if that risks its own web
compatibility concerns and risks (e.g.
functionality that works differently, or not at
all, depending on whether it's installed or not).
Can you explain the use case/value of knowing
beyond below 2GB or beyond 32GB at this point? I'm
not sure I can see a pressing need based on my
knowledge of how the API is used, and the limited
value small numbers, outside of the current
values, delivers.
Also whether you'd also be looking for a more
granular breakdown between the currently coarsened
values (e.g. knowing if it's 24GB as opposed to
16GB that would currently be reported with this
change). The latter would require a spec change
though because although the capping is noted as
independent the "power-of-two" levels is not. So
any such change would need to be discussed with
the Web Perf Working Group first of all by opening
an issue on the spec repo:
https://github.com/w3c/device-memory/issues
<https://github.com/w3c/device-memory/issues>
On Mon, 19 Jan 2026 at 23:49, Daniel Herr
<[email protected]> wrote:
It seems to me that the privacy concerns with
this and similar APIs are primarily concerned
with random webpages. In the case of installed
PWA, IWA, WebExtension, etc, which have a
higher level of trust, it makes sense to me
that the values could be untruncated, both
retaining those smaller values and perhaps
also going upwards beyond 32. What do you think?
On Mon, Jan 19, 2026, 5:52 PM 'Barry Pollard'
via blink-dev <[email protected]> wrote:
*Contact emails*
[email protected]
<mailto:[email protected]>
*Summary*
Set a new set of possible values for the
Device Memory API:
- Android: 2, 4, 8
- Others: 2, 4, 8, 16, 32
Replacing the old values of 0.25, 0.5, 1,
2, 4, 8 which have grown outdated.
This will reduce the fingerprinting risks
at the lower end since device capabilities
have improved since these were set.
It will also allow better usage and
segmenting of high-end devices as
requested by developers
(https://github.com/w3c/device-memory/issues/50
<https://github.com/w3c/device-memory/issues/50>).
*Blink component*
Blink>JavaScript>API
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EJavaScript%3EAPI%22>
*Web Feature ID*
device-memory
<https://webstatus.dev/features/device-memory>
*Search tags*
DeviceMemory
<https://chromestatus.com/features#tags:DeviceMemory>,
memory
<https://chromestatus.com/features#tags:memory>,
Sec-CH-DeviceMemory
<https://chromestatus.com/features#tags:Sec-CH-DeviceMemory>
*Risks*
*Interoperability and Compatibility*
While this does not introduce a new API
and the values were somewhat*
non-standardised the current values have
been around for some time for
Chromium-based browsers (the only
implementor at this time).
* Note: the ambiguity has been cleared up
in the spec to make it super clear the
values are implementation-defined and so
subject to change.
As such , I foresee two risks here:
- Some web apps have gated some features
on < 2GB RAM and these devices will now
start to report as the minimum 2GB RAM and
so enable features the devices may not be
capable of using.
- Some webpages may have incorrectly coded
to presume no value >8 will ever be reported.
The compatibility risk here however seems
small, and the privacy risk of remaining
as is is not small.
However the feature has been gated behind
a feature flag so, should the worst
happen, we can revert to the original values.
/Gecko/: No
signal
(https://groups.google.com/g/mozilla.dev.platform/c/cfydu35XdnY/m/3IqYn0oJAQAJ
<https://groups.google.com/g/mozilla.dev.platform/c/cfydu35XdnY/m/3IqYn0oJAQAJ>)
Firefox didn't go as far as giving a
negative signal AFAIK but have raised
concerns. They have not blocked updating
these limits.
/WebKit/:
Negative
(https://github.com/w3c/device-memory/issues/24
<https://github.com/w3c/device-memory/issues/24>)
Webkit are negative to the original API
but have not blocked updating these limits.
/Web developers/:
Positive
(https://github.com/w3c/device-memory/issues/50
<https://github.com/w3c/device-memory/issues/50>)
Proposal
/Other signals/: This was discussed in the
WebPerf WG group on 2026-01-15 and we were
in agreement to change this.
*Ergonomics*
Very low-end devices may no longer be
excluded from features web developers have
previously restricted to >= 2GB RAM.
*Activation*
None, other than those noted in
Interoperability and compatibility risks.
*Security*
Internal stats were reviewed to confirm
the lower bounds are rarely used and so
present a privacy risk.
This was also confirmed with discussions
with external RUM providers.
Additionally the new upper bounds were
decided upon based on similar data review
(internal only, since these values are not
currently exposed—which is what we are
trying to fix).
Finally, the upper bounds are not planned
to be increased (yet) on Android since
>8GB RAM is still rare for mobile devices.
*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?
Kill switch
(kUpdatedDeviceMemoryLimitsFor2026) included.
*Debuggability*
The feature is available from standard
APIs, but it is not currently possible to
emulate the values (since that will only
change the reported value and not the
amount of RAM used so is of limited use).
*Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?*
Yes
Note different values on Android and other
platforms
*Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
https://wpt.fyi/results/device-memory?label=experimental&label=master&aligned
<https://wpt.fyi/results/device-memory?label=experimental&label=master&aligned>
These tests will be updated as part of
this change
(https://chromium-review.git.corp.google.com/c/chromium/src/+/7410045
<https://chromium-review.git.corp.google.com/c/chromium/src/+/7410045>).
*Flag name on about://flags*
/No information provided/
*Finch feature name*
kUpdatedDeviceMemoryLimitsFor2026
*Non-finch justification*
I am not planning on rolling this out via
finch giving the low risk, but will
include a feature flag
(`kUpdatedDeviceMemoryLimitsFor2026`) to
allow it to be turned off if the worst
should happen.
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/454354290
<https://issues.chromium.org/issues/454354290>
*Measurement*
This is already track with an existing use
counters: - JS API -
https://chromestatus.com/metrics/feature/timeline/popularity/2121
<https://chromestatus.com/metrics/feature/timeline/popularity/2121> -
Client Hints:
https://chromestatus.com/metrics/feature/timeline/popularity/4046
<https://chromestatus.com/metrics/feature/timeline/popularity/4046> -
Client Hints (deprecated name):
https://chromestatus.com/metrics/feature/timeline/popularity/2017
<https://chromestatus.com/metrics/feature/timeline/popularity/2017>
*Availability expectation*
Feature is available only in Chromium
browsers for the foreseeable future.
*Adoption expectation*
RUM Providers using this feature can
validate increased usefulness of the new
values.
*Adoption plan*
Present at RUM CG on the change and ask
for feedback after implementation.
*Non-OSS dependencies*
Does the feature depend on any code or
APIs outside the Chromium open source
repository and its open-source
dependencies to function?
No
*Estimated milestones*
Shipping on desktop 146
Shipping on Android 146
Shipping on WebView 146
*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).
Spec issues resolved:
https://github.com/w3c/device-memory/pull/53
<https://github.com/w3c/device-memory/pull/53>
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/6330376953921536
<https://chromestatus.com/feature/6330376953921536>
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
[email protected]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH6JyLQFDfe%3Dv2LS0-XWh2nDhP0_7_K6o4mAiK_FAA0ZZrZ1KA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH6JyLQFDfe%3Dv2LS0-XWh2nDhP0_7_K6o4mAiK_FAA0ZZrZ1KA%40mail.gmail.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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afe59f37-2647-4a5c-bd8b-1af199f79157n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afe59f37-2647-4a5c-bd8b-1af199f79157n%40chromium.org?utm_medium=email&utm_source=footer>.
