You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blocking webRequest is the only tool available to developers to create custom authentication schemes.
Common methods to send credentials with top level requests are: cookies, basic HTTP authentication and client-side certificates.
Cookies have a number of disadvantages: were never intended to prevent linking requests from the same user; are stored in the browser and can leak easily; are included in all requests to a given domain (even when they are not needed).
Browsers do not provide built-in tools for using token-based authentication (oauth, etc) in top level requests.
Blocking webRequest allows reading, modifying and removing http headers, which allows developers to experiment with new authentication models.
The WebExtension cookie permission is not a solution, as cookies are being set globally.
Examples
There are use-cases that cannot be implemented without the help of WebExtension:
The Ghostery search (https://glowstery.com/)
is a website that uses server side rendering. It is public, but displays private sponsored links unless a user has a subscription. To prove that a request is from a subscribed user, a token is inserted (generated in advance with a blind signature scheme). The token is inserted as a custom HTTP header.
Cookies cannot be used in for private search engines, as they would link all requests and thus reveal the user's search history.
Currently, it is implemented as follows:
Subscribed users have to install the Ghostery search extension. The extension observes requests from glowstery.com, generates a token, and updates the requests by setting the custom header (here the blocking webRequest API is used)
On the server side, depending on whether theis is a valid token or not, either the ad-free page is served or the fallback to the page showing ads.
Valid tokens were prepared by the extension in advance (by the blind signature scheme, which involves communication with the server).
The text was updated successfully, but these errors were encountered:
Blocking
webRequest
is the only tool available to developers to create custom authentication schemes.Common methods to send credentials with top level requests are: cookies, basic HTTP authentication and client-side certificates.
Cookies have a number of disadvantages: were never intended to prevent linking requests from the same user; are stored in the browser and can leak easily; are included in all requests to a given domain (even when they are not needed).
Browsers do not provide built-in tools for using token-based authentication (oauth, etc) in top level requests.
Blocking
webRequest
allows reading, modifying and removing http headers, which allows developers to experiment with new authentication models.The WebExtension
cookie
permission is not a solution, as cookies are being set globally.Examples
There are use-cases that cannot be implemented without the help of WebExtension:
Ghostery example: Private Search
The Ghostery search (https://glowstery.com/)
is a website that uses server side rendering. It is public, but displays private sponsored links unless a user has a subscription. To prove that a request is from a subscribed user, a token is inserted (generated in advance with a blind signature scheme). The token is inserted as a custom HTTP header.
Cookies cannot be used in for private search engines, as they would link all requests and thus reveal the user's search history.
Currently, it is implemented as follows:
glowstery.com
, generates a token, and updates the requests by setting the custom header (here the blocking webRequest API is used)The text was updated successfully, but these errors were encountered: