A further update on this Intent to Ship. While testing Chrome Beta, Google testers discovered the new values (16, and presumably 32 as well) caused blockages to x.com (formerly Twitter) logins. We reached out to that team who made the change to accept these new values too, and we've confirmed we no longer see the issue. Unfortunately we've no way of measuring this since the blockage was done server side and was only apparent when the new values were sent. In addition it seems it was one of many signals used my X to decide blockage (our testing team in India noticed this, but myself in EMEA and others in USA could not repeat it). I've asked X for more details if they can share, as a lot of this is presumption based on my side and they've only confirmed the issue was resolved with a change at their side.
This leaves us in a bit of a predicament as we cannot be sure that other sites may not also have similar logic to block functionality on seeing unexpected values. However, I don't want to accept that no new values can be added, as that severely limits the usefulness of the API. Especially as we 1) drop older values, and 2) introduce new features that depend on higher memory usage (e.g. on-device AI). This is gated behind a feature flag, we can disable these new number with a kill switch if we do see issues. An alternative is for a gradual rollout but, as per previous discussions, we try to avoid APIs returning different values as this leads to more confusion than helpfulness. And in this example, there was already enough confusion since the behaviour was inconsistent. Therefore, I'd like to proceed with the release with the kill switch option if necessary.* Do API owners agree and/or have alternative suggestions?* In the meantime it has been disabled by default again and I've updated the shipping milestone to 147 to allow more time for feedback. Thanks, Barry On Tuesday, January 27, 2026 at 6:42:22 PM UTC Michal Mocny wrote: > Looking at some field data by browser session, it seems like this device > class is only a small fraction of a percentage of overall usage, and so > suggesting to raise the minum cap to 2gb seemed prudent. However, with > this new context, I now took a look at the fraction of unique users splut > by total memory, rather than looking at total browsing sessions, with an > assumption that these users are less active. Numbers are slightly > higher... but still quite low. > > That said, users that are in this situation surely rely on access to such > services as Search, and if those services have gone out of their way to > optimize down to this class of usage (and the test case seems to prove it > is possible), it seems worthwhile to retain support for the time being. > > -Michal > > On Tue, Jan 27, 2026 at 9:42 AM 'Barry Pollard' via blink-dev < > [email protected]> wrote: > >> All, I've an update on this Intent to Ship. >> >> After enabling this change we have seen a regression in our test suite, >> whereby Search stories on Android show an increase in memory usage. Not >> crashes, but a regression nonetheless. I'm trying to get to the bottom of >> why. The test suite does use an Android device with 900MB of RAM (though >> confusingly labelled as wembley_2GB!) meaning that with this change it >> would now report 2GB of total device memory instead of the 1GB that would >> have previously been used. I'm guessing this triggers more features that >> were previously disabled but am following up with Search to confirm as I >> can't quite identify where that happens myself from the outside. >> >> Anyway, the good news is that allowing back 1GB on Android seems to fix >> the regression. >> >> There's a good question as to whether that 900MB RAM is a good test >> device nowadays, but it did make me have another look at this and upon >> reviewing internal device usage stats again, I'm going to tweak this change >> slightly to continue to allow 1GB on Android. In hindsight removing it may >> have been a little premature and not being able to differentiate between >> 2GB and lower on mobile is maybe not ideal yet. Longer term Search may wish >> to consider upping their lower limit for if/when we remove 1GB in the >> future. >> >> Usage of 1GB Device Memory of non-mobile devices remains very low so I >> don't want to enable that, but since we've already accepted different >> thresholds at the upper end, having similar at the lower end seems OK too. >> I'll confirm this with privacy too. >> >> The alternative is to accept the regression and/or upgrade our test >> devices but I'm comfortable with including 1GB on Android for now. >> >> Let me know if you've any concerns with this slightly tweaked approach. >> It still represents a big overall privacy improvement. >> >> Thanks, >> Barry >> >> On Wed, 21 Jan 2026 at 21:29, Andy Luhrs <[email protected]> wrote: >> >>> This came up at TPAC - I think the rough consensus was it makes sense to >>> be a recurring TPAC session for the WebPerfWG specs. >>> ------------------------------ >>> *From:* Alex Russell <[email protected]> >>> *Sent:* Wednesday, January 21, 2026 8:51 AM >>> *To:* blink-dev <[email protected]> >>> *Cc:* Daniel Bratell <[email protected]>; [email protected] < >>> [email protected]>; [email protected] <[email protected]>; >>> Alex Russell <[email protected]>; Vladimir Levin < >>> [email protected]>; Yoav Weiss <[email protected]> >>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Update Device >>> Memory API limits >>> >>> Excited that this will ship. Thanks for the response about thresholds >>> and the user population, Barry. I'll trust your best judgement here. >>> >>> It does re-open the question of how we can get the various WGs that have >>> maintenance responsibility to occasionally revisit these lists. Perhaps >>> something we should discuss with the TAG? >>> >>> Best, >>> >>> Alex >>> >>> On Wednesday, January 21, 2026 at 8:16:03 AM UTC-8 Daniel Bratell wrote: >>> >>> LGTM3 >>> >>> /Daniel >>> On 2026-01-21 17:14, Yoav Weiss (@Shopify) wrote: >>> >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afe59f37-2647-4a5c-bd8b-1af199f79157n%40chromium.org?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/b632e691-7206-49e4-bed0-85236f7475dan%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b632e691-7206-49e4-bed0-85236f7475dan%40chromium.org?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/CAH6JyLRJmBPSMgTnBd29ZhE9OriHRqAZD%2BkNpQk9AMAaR4_3aQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH6JyLRJmBPSMgTnBd29ZhE9OriHRqAZD%2BkNpQk9AMAaR4_3aQ%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/deea317e-f202-4e5b-afc0-e5ae94797034n%40chromium.org.
