Hey all, Just to keep you informed we got another report <https://issues.chromium.org/issues/454354290#comment9> yesterday of a site being blocked with this change (currently in Chrome Beta). This was a highly obfuscated bit of code owned by a bot protection service (Kasada). Checking the HTTP Archive I found 141 sites using this service (including 3 top 1,000 sites, 4 top 5,000 sites), but could not repeat the blocking on those (I could on the originally reported site) so not sure if this DeviceMemory signal is only part of the signal.
Anyway, I reached out to the Kasada who released a fix overnight (thanks!) to include the new limits and the original reported site is no longer blocked. I don't think there is anything further to do here, and it's good that they were able to deploy a fix so quickly, but I'm just letting the API owners know that there is a non-zero risk that we will see similar issues with other sites and bot protection providers when this starts to roll out to stable next month. The Device Memory API is being used on over 40% of navigations and origins <https://chromestatus.com/metrics/feature/timeline/popularity/2121> with a potential additional 5% using one <https://chromestatus.com/metrics/feature/timeline/popularity/2017> of the two <https://chromestatus.com/metrics/feature/timeline/popularity/4046> client hints that expose this. In most cases I expect this is more for reporting back to RUM, so no issue (and they will likely be glad of the further breakdown this change will provide). Some may be limiting or progressively enhancing their site based on the values returned by this API and low-end devices will not report as high values which may unlock capabilities they might struggle with, but likely those devices are already struggling with the modern web. Finally, given the latest issue, it's impossible to know how many bot protection services are using this as a signal to block in particular because this is often obfuscated code and also because this can be one of many signals. Anyway, I've done another round of searching the web and GitHub and reached out to a few people/companies, but it remains a risk. Hopefully the next update will be less painful as the ecosystem becomes aware these values are not set forever. Thanks, Barry On Monday, February 23, 2026 at 8:09:54 PM UTC [email protected] wrote: > +1: I don't think there's a need to delay this change in order to figure > out whether and how to remove the upper limit. > > On Mon, Feb 23, 2026 at 3:15 AM Barry Pollard <[email protected]> > wrote: > >> I've not heard any push back from API owners to stop this change, or to >> take a different approach (the opposite in fact with a suggestion to go >> further by removing the upper limit >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/vXtAmrVZeDk/m/kO39WH6NAwAJ>), >> >> so I've opened a CL to re-enable this change again for 147 >> <https://chromium-review.googlesource.com/c/chromium/src/+/7594551>. >> >> Jeffrey, I've followed up on that other thread with Privacy to discuss >> removing the upper limit. As mentioned there, I'm not seeing the pressing >> need for this (I doubt people are optimising for >32GB on desktop, or >8GB >> on mobile given the few users on that) so am more comfortable with the >> current proposed limits, though it would help with future maintenance (i.e. >> not going through this again in a few years time). >> >> Given the rocky road this (simple, or so I thought!) change has had so >> far—with the lower limit change causing a regression in our test suite, and >> the upper limit affecting at least one major site—I suggest we proceed as >> is currently proposed for this first update since the original limits and >> revisit this discussion next time, when hopefully it will be a simpler >> change given the groundwork here! >> >> Barry >> >> On Friday, February 13, 2026 at 6:01:35 PM UTC Michal Mocny wrote: >> >>> The latest Spec changes remove a formal hard limit in place for evolving >>> soft limits. Somewhat the best of both worlds in that this is expected to >>> grow over time but only as some sufficient number of users meet certain >>> thresholds. >>> >>> Right now it requires a human in the loop to update these values, but it >>> could potentially be automated (or rely on reminders). (The latest >>> proposal was to update every year at TPAC. I know thats a bit of a soft >>> answer.) >>> >>> On Fri, Feb 13, 2026 at 12:33 PM Jeffrey Yasskin <[email protected]> >>> wrote: >>> >>>> FWIW, I think you should remove the upper limit. Yes, it will >>>> more-precisely fingerprint people with very large amounts of memory, but >>>> it >>>> will also allow sites to accurately use the hardware that people bought. >>>> People don't buy hardware to leave it unused. It will put some burden on >>>> those early adopters to file bugs with sites who don't expect them, but >>>> it'll also help GREASE this signal. >>>> >>>> Jeffrey >>>> >>>> On Fri, Feb 13, 2026 at 8:49 AM Daniel Bratell <[email protected]> >>>> wrote: >>>> >>>>> My LGTM still stands. It's one site that did something weird, but as >>>>> Aristotle said, one swallow does not a summer make. I appreciate your >>>>> careful approach though. >>>>> >>>>> /Daniel >>>>> >>>>> (cutting away most of the history in an attempt to get Google's mail >>>>> servers to accept it) >>>>> On 2026-02-13 15:31, Barry Pollard wrote: >>>>> >>>>> 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 >>>>> >>>>>> -- >>>>> 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/d9b2f4a2-38f1-4713-9a86-eb8c24e7e3fc%40gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9b2f4a2-38f1-4713-9a86-eb8c24e7e3fc%40gmail.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/b0c4d9de-ca3b-4084-a773-dad5aa9ec42cn%40chromium.org.
