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/CAH6JyLR8y1RQRvJoid%2BX3HYi8jk8TNbXgNgKVC4AcyzkyW%2BzZQ%40mail.gmail.com.
