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/0f24e087-2db1-4346-bb8e-38dcaa24d0b1n%40chromium.org.
