Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking webRequest use case - alternative authentication schemes #168

Open
chrmod opened this issue Mar 3, 2022 · 0 comments
Open

Blocking webRequest use case - alternative authentication schemes #168

chrmod opened this issue Mar 3, 2022 · 0 comments
Labels
topic: dnr Related to declarativeNetRequest

Comments

@chrmod
Copy link

chrmod commented Mar 3, 2022

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:

  • 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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: dnr Related to declarativeNetRequest
Projects
None yet
Development

No branches or pull requests

2 participants