+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/CANh-dXkxG%2Baf4EHAC1LfaURj-Lio2jm67iv%2BF2HKtREudbGhQg%40mail.gmail.com.
