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 >>> >>> >>> 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] >>>>> >>>>> *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). >>>>> >>>>> *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) >>>>> 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) >>>>> 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) 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 >>>>> >>>>> These tests will be updated as part of this change ( >>>>> 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 >>>>> >>>>> *Measurement* >>>>> This is already track with an existing use counters: - JS API - >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/2121 - >>>>> Client Hints: >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/4046 - >>>>> Client Hints (deprecated name): >>>>> 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 >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> 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]. >>>>> 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/1a91490b-1ead-4788-910b-384a547e349bn%40chromium.org.
