w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
599 stars 56 forks source link

Defining Web Extension privacy and security model #71

Open jonathanKingston opened 3 years ago

jonathanKingston commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

jonathanKingston commented 3 years ago

@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".

jonathanKingston commented 1 year ago

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.