Thanks for the update! I wonder if this (and similar values that are likely to increase over time) should be GREASE <https://datatracker.ietf.org/doc/html/rfc8701>d.
On Thu, Mar 19, 2026 at 11:29 AM Barry Pollard <[email protected]> wrote: > 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/CAOmohSLN_FOpiE1BESoCM-eq6VeEhFBjDjSnmDcB8P%2BwrkDaOw%40mail.gmail.com.
