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 >>>>> >>>>> >>>>> 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/afe59f37-2647-4a5c-bd8b-1af199f79157n%40chromium.org.
