On Wed, Jul 8, 2026 at 7:10 PM Morgaine (de la faye) <[email protected]> wrote:
> I take it there are no affordances for Bookmarklets? > Can you expand? This is about site-initiated network requests. AFAICT, bookmarklets are user-initiated JS snippets, so they are totally orthogonal and unaffected by this. Maybe you have a specific scenario in mind that you think this affects? > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/49e293ad-dd5e-4d2b-81cc-44f4a569856fn%40chromium.org?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/CAJn%3DMYardM1oyCJ1gB2%2BA8SucsVagScR_LAuw96MPceyu4uzGA%40mail.gmail.com.
