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

Defining Web Extension privacy and security model #71

Open
jonathanKingston opened this issue Sep 2, 2021 · 6 comments
Open

Defining Web Extension privacy and security model #71

jonathanKingston opened this issue Sep 2, 2021 · 6 comments
Labels
documentation Improvements or additions to documentation inconsistency Inconsistent behavior across browsers topic: csp Related to content security policy enforcement

Comments

@jonathanKingston
Copy link

jonathanKingston commented Sep 2, 2021

Defining where the security boundaries of extensions are and what expectations they should have from a user and browser stand point would be beneficial to defining future features.

Often times the WebExtension security model is considered to match that of the browser and act on behalf of the user however:

  1. Various URLs are blocked within the extensions to prevent permission escalation.
    • Firefox for example consciously decides to block modifications to Mozilla domains to prevent extensions from elevating permissions defined within the extension (if an extension can modify the Mozilla pages the extension could auto install a more powerful extension without user consent).
  2. An extension can't open popup UI without user activation.
  3. Extensions can override CSP and other APIs the web exposes.
  4. Firefox also adds the extension icon to context menus to prevent confusion with the native menu items.
@Jack-Works
Copy link

An extension can't open popup UI without user activation.

Is that the case? IIRC browser.windows.create / browser.tabs.create can be called freely.

@carlosjeurissen
Copy link
Contributor

@Jack-Works They are talking about opening the extension popup programmatically. Which should be possible using browser.browserAction.openPopup(). Yet this is unsupported in most browsers or only using a user action.

However, the fact an extension can always create new tabs and browser windows is the perfect argument for allowing browserAction.openPopup or action.openPopup as well.

@jonathanKingston
Copy link
Author

However, the fact an extension can always create new tabs and browser windows is the perfect argument for allowing browserAction.openPopup or action.openPopup as well.

Right, the justification for this was that it was annoying to users but clearly the extension can do just as many damaging things; either:

  1. The browser should prevent the extension doing things that annoy the user.
  2. Other protections should be removed with the benefits of usability.

@xeenon
Copy link
Collaborator

xeenon commented Sep 9, 2021

Issue #15 covers browser.browserAction.openPopup().

@xeenon xeenon changed the title Web extension privacy and security model Defining Web Extension privacy and security model Sep 9, 2021
@xeenon xeenon added documentation Improvements or additions to documentation inconsistency Inconsistent behavior across browsers labels Sep 9, 2021
@jonathanKingston
Copy link
Author

@xeenon Right I saw that before raising this, but that doesn't cover the previous discussions that have happened at Mozilla that rejected the idea on the 'annoyance' rationale. Perhaps the decision should be overturned as it doesn't fit with our current thinking of what the security boundaries are.

Firefox also adds the extension icon to context menus to prevent confusion with the native menu items.

I'm interested in there being some level documented reasons why browsers made these decisions. That way we know what the boundaries of web extensions should be aka a website security model is commonly the "line of death".

@xeenon xeenon added the topic: csp Related to content security policy enforcement label Aug 31, 2022
@jonathanKingston
Copy link
Author

One example of this is TrustedScript as outlined here: https://bugs.chromium.org/p/chromium/issues/detail?id=1427382.

The spec states that extensions should be permitted to work around this CSP enforcement as if it weren't a policy and yet the current issue means it can't be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation inconsistency Inconsistent behavior across browsers topic: csp Related to content security policy enforcement
Projects
None yet
Development

No branches or pull requests

4 participants