search

WICG / pending-beacon

A better beaconing API
Other
43 stars 8 forks source link

Blocking with extensions #60

Open sandstrom opened 1 year ago

sandstrom commented 1 year ago

One problem with giving these a dedicated resource type, is that ad-blocker extensions may just auto-block all requests of this particular type.

If they would share the resource type with fetch requests (after all, they'd be similar to a keepAlive fetch in many regards), with no way for an extension to discern them from other fetch requests, then the ad-blocker extension would need to look at the URL to determine whether to block it or not.

By forcing them to look at the URL, it's likely that ads and third-party scripts would still be easy to block, but legit first-party usage, such as a SaaS-application, could still rely on it (as long as that particular SaaS-domain isn't added to a blacklist).

I understand there are drawbacks to this too, but something to consider.

mingyc commented 1 year ago

I assume you are talking about the beacon type in webRequest.ResourceType.

The current API proposal actually doesn't specify to support webRequest listener, i.e. using beacon won't get you to handle the Pending*Beacon requests. I think it's reasonable as this API delegates request-sending to browser, and in some cases, it's impossible to listen to PendingBeacon requests in JS, as the document where the request was created may longer exist when the browser sends PendingBeacon requests or gets PendingBeacon responses.

To disable PendingBeacon API or filter URLs, the extension has to replace the global PendingGetBeacon/PendingPostBeacon ctor with empty functions or a custom functions with filter in it.