I take it there are no affordances for Bookmarklets? Bookmarklets are _THE ONLY_ agency users have on mobile, still, in the Year of Our Lord 2026 (which is outrageous in itself). This Connection Allowlist will summarily block good decent folks trying to do things like use their preferred bookmark site's bookmarklet. I'm highly disappointed the user's especially on mobile keep having less and less power and that the site defines and enforces more and more the Terms of Service against any user desire. This feature massively tilts the game in terms of the site's preference & away from the user. This is a titan sized violations of RFC 8890 The Internet is For End Users. To me this feels like a terrible change that once again leaves users high and dry and unable to use the web as they please.
One example of a bookmarklet that is under threat from this "feature" (this great constrainer, limiter, closer-up, de-featuring, de-possibilitying): https://bsky.app/profile/semble.so/post/3mkqftm2jua2f On Thursday, June 25, 2026 at 3:00:39 PM UTC-4 Chromestatus wrote: > *Contact emails* > [email protected], [email protected], [email protected] > > *Explainer* > https://github.com/WICG/connection-allowlists > > *Specification* > https://wicg.github.io/connection-allowlists > > *Summary* > Connection Allowlists is a feature designed to provide explicit control > over external endpoints by restricting connections initiated via the Fetch > API or other web platform APIs from a document or worker. The proposed > implementation involves the distribution of an authorized endpoint list > from the server through an HTTP response header. Prior to the establishment > of any connection by the user agent on behalf of a page, the agent will > evaluate the destination against this allowlist; connections to verified > endpoints will be permitted, while those failing to match the entries in > the list will be blocked. More details on the proposal can be found here: > https://github.com/WICG/connection-allowlists Design doc: > https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA/edit?usp=sharing > > Implementation Design: > https://source.chromium.org/chromium/chromium/src/+/main:docs/connection_allowlist_design.md > > > *Blink component* > Blink>SecurityFeature>ConnectionAllowlist > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EConnectionAllowlist%22> > > *Web Feature ID* > Missing feature > > *Motivation* > Developers wish to have control over the resources loaded into their > pages' contexts and the endpoints to which their pages can make requests. > This control is necessary for several purposes, including limiting the ways > in which users' data can flow through the user agent (mitigating > exfiltration attacks) and ensuring control over a site’s architecture and > dependencies. Content Security Policy addresses some of this need, but does > so in a way that is more granular than necessary for the most critical use > cases, and with a syntax and grammar that’s complicated by the other > protections CSP is used to deploy. `Connection-Allowlist` steps back from > CSP, and focuses on the single use case of controlling the explicit > requests a page may initiate through Fetch and other web platform APIs > (Navigations, preload, DNS Prefetch, WebRTC, Web Transport, etc) in a way > that aims to be straightforward and comprehensive. Example: > Connection-Allowlist: (response-origin "https://cdn.example"; > "https://*.example.:tld"; \ "https://api.example:*";); > report-to=ReportingAPIEndpoint > > *Initial public proposal* > https://github.com/WICG/proposals/issues/235 > > *Search tags* > Connection Allowlists <http:///features#tags:Connection%20Allowlists> > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/1173 > > *TAG review status* > Pending > > *Origin Trial Name* > Connection Allowlists > > *Goals for experimentation* > Origin Trial's goal was to gain insights on websites' usage of Connection > Allowlist header and receive feedback from developers on whether there are > any updates that would be useful. As was mentioned in the I2E, at the start > of OT, the following network endpoints were implemented: Subresources > fetch, Navigations, Redirects, fetches from local scheme navigations (via > connection allowlists inherited from the navigation's initiator), > history.back/forward navigations, rel=prefetch, rel=preconnect, > rel=preload, rel=modulepreload, , rel=dns-prefetch, and their link header > equivalents. As OT progressed, support was added for remaining known > network endpoints including webRTC, WebTransport, WebSocket and others. > Connection allowlists support documents, dedicated workers, shared workers > and service workers. > > *Chromium Trial Name* > ConnectionAllowlist > > *Origin Trial documentation link* > https://developer.chrome.com/blog/connection-allowlists-origin-trial > > *WebFeature UseCounter name* > kConnectionAllowlist > > *Risks* > > > *Interoperability and Compatibility* > This is a new feature. We are interacting with other browsers via > discussions on GitHub and in the Community Group. However, there is no > official signal yet from any other browser vendors about their > implementation plans. > > *Gecko*: No signal ( > https://github.com/mozilla/standards-positions/issues/1322) We think > there's agreement on the value of this functionality, but differences of > opinion on what the header looks like. There has been good interaction on > some of the issues in the repo and in the WebAppSec meetings. > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/583) No official > position, but there has been good interaction on some of the issues in the > repo and in the WebAppSec meetings. > > *Web developers*: Positive ( > https://github.com/WICG/proposals/issues/235#issuecomment-3463775783) We > have had multiple developers using Connection Allowlists through the Origin > Trial and are planning to continue to use it. Microsoft is also > collaborating on enhancements like > https://github.com/WICG/connection-allowlists/issues/1 > > *Other signals*: Edge: Positive ( > https://github.com/WICG/proposals/issues/235#issuecomment-3463775783) > > *Ergonomics* > This feature will be frequently used in tandem with existing Web Platform > Security mechanisms like Content Security Policy, Sandbox etc. We expect no > impact on Chrome's performance. > > *Activation* > No challenges for developers to take advantage of this feature immediately. > > *Security* > This feature should be beneficial for security because it allows documents > and workers to restrict network communication that could exfiltrate > sensitive data. > > *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? > No. This is a new feature. > > > *Debuggability* > To assist developers in debugging malformed headers, parsing errors are > reported directly to the DevTools Issues tab. Additionally, the reporting > infrastructure for Connection-Allowlist was introduced to support both > enforced violation reporting and a "report-only" mode, allowing developers > to monitor potential breakages without interrupting service. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > > https://github.com/web-platform-tests/wpt/tree/master/connection-allowlist/tentative > > *Flag name on about://flags* > connection-allowlists > > *Finch feature name* > ConnectionAllowlists > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > True > > *Tracking bug* > https://issues.chromium.org/issues/447954811 > > *Measurement* > UseCounter has been added for measuring the usage of the feature > > *Availability expectation* > Feature is available only in Chromium browsers for the foreseeable future. > > *Adoption expectation* > Feature is used by specific partner(s) to provide functionality within 12 > months of launch in Chrome. > > *Adoption plan* > Some of the partners are already participating in the Origin Trial and > they are expected to adopt the feature as it ships in Chrome. The use > counter can be seen here: > https://chromestatus.com/metrics/feature/timeline/popularity/5867 > > *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? > None > > *Estimated milestones* > Shipping on desktop 152 > Origin trial desktop first 148 > Origin trial desktop last 151 > Shipping on Android 152 > Origin trial Android first 148 > Origin trial Android last 151 > Shipping on WebView 152 > Origin trial WebView first 148 > Origin trial WebView last 151 > > *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). > https://github.com/WICG/connection-allowlists/issues Note that issues > marked as enhancement, like > https://github.com/WICG/connection-allowlists/issues/1, > https://github.com/WICG/connection-allowlists/issues/28 are not included > in this entry and will be launched via a separate I2S, but are additive and > backward-compatible. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5175745573945344?gate=6083622706741248 > > *Links to previous Intent discussions* > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a779c1.050a0220.1426e8.0068.GAE%40google.com > > > 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/49e293ad-dd5e-4d2b-81cc-44f4a569856fn%40chromium.org.
