feat: Implement EME per-site permission #189

celenity commented 2026年05月29日 12:14:09 +02:00

This works by leveraging the already-existing logic/implementation for GeckoView

This also adds the relevant localizations from Fenix and A-C, which we can also leverage/re-use in many cases

(Also see librewolf/settings#134)

Signed-off-by: celenity celenity@celenity.dev

This works by leveraging the already-existing logic/implementation for GeckoView This also adds the relevant localizations from Fenix and A-C, which we can also leverage/re-use in many cases *(Also see https://codeberg.org/librewolf/settings/pulls/134)* Signed-off-by: celenity <celenity@celenity.dev>

alyx161 commented 2026年05月30日 17:41:32 +02:00

Any details about why?

I assume the translations need proper accreditation?

Any details about why? I assume the translations need proper accreditation?

celenity commented 2026年05月30日 23:33:33 +02:00

@alyx161 wrote in #189 (comment):

Any details about why?

Sure, I apologize if the rationale wasn't clear from the PR/commits (was quite tired when I opened this...).

In addition to posing user freedom concerns (which is the currently stated reason that LibreWolf disables EME by default), EME also poses various privacy and security concerns.

Adding a per-site permission prompt helps mitigate these concerns and provides more control for users by only allowing specific sites, if any, to use EME (This is especially useful because random websites do abuse EME that don't actually need it - ex. I've seen random news websites in the past). I also suspect that many users who enable EME are likely only doing so to use it on just a handful of sites (ex. Netflix/Prime Video/Hulu/Disney+/etc.) - so why allow all websites to use it, instead of just the ones that a user actually wants to be able to use it?

In part due to these concerns, Mozilla implemented the permission prompt for Android (where it is enabled/set to always prompt by default), but they unfortunately didn't implement it for Desktop. But because the underlying permission/logic was already implemented for GeckoView (and exists in core/shared toolkit code), we can re-use that existing implementation to implement this prompt/permission with minimal effort/maintenance required (for reference, this is significantly less complex than ex. the WebGL patch).

For reference, due to these concerns, other privacy-and-security oriented browsers, such as Vanadium, also enable a permission prompt for EME by default.

At the cost of privacy and security, at their own risk, users can disable the permission prompt by simply setting media.eme.require-app-approval to false.

So this is ultimately a feature that would directly improve the privacy, security, and control for users.

I assume the translations need proper accreditation?

What would you have in mind? For reference, the strings I added were taken nearly verbatim from the strings.xml files already contained in mozilla-central (under the mobile/android/android-components/components/feature/sitepermissions/src/main/res and mobile/android/fenix/fenix/app/src/main/res directories - I'll also note that the original strings.xml files are licensed under MPL-2.0 as well, so no conflicts there).

I did also add comments to the files here and here to document where the strings originated from.

But if there's some way I can better/further accredit these, please LMK.

@alyx161 wrote in https://codeberg.org/librewolf/source/pulls/189#issuecomment-16193933: > Any details about why? Sure, I apologize if the rationale wasn't clear from the PR/commits *(was quite tired when I opened this...)*. In addition to posing user freedom concerns *([which is the currently stated reason that LibreWolf disables EME by default](https://librewolf.net/docs/faq/#how-do-i-enable-drm))*, EME also [poses various privacy and security concerns](https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-we-just-lost-web-what-we-learned-it-and-what-we-need-do-next). Adding a per-site permission prompt helps mitigate these concerns and provides more control for users by only allowing specific sites, if any, to use EME *(This is especially useful because random websites do abuse EME that don't actually need it - ex. I've seen random news websites in the past)*. I also suspect that many users who enable EME are likely only doing so to use it on just a handful of sites *(ex. Netflix/Prime Video/Hulu/Disney+/etc.)* - so why allow all websites to use it, instead of just the ones that a user actually wants to be able to use it? In part due to these concerns, Mozilla implemented the permission prompt for Android *(where it is enabled/set to always prompt by default)*, but they unfortunately didn't implement it for Desktop. But because the underlying permission/logic was already implemented for GeckoView *(and exists in core/shared `toolkit` code)*, we can re-use that existing implementation to implement this prompt/permission with minimal effort/maintenance required *(for reference, this is significantly less complex than ex. the WebGL patch)*. For reference, due to these concerns, other privacy-and-security oriented browsers, such as Vanadium, [also enable a permission prompt for EME by default](https://github.com/GrapheneOS/Vanadium/blob/main/patches/0037-ask-before-playing-protected-media-by-default.patch). At the cost of privacy and security, at their own risk, users can disable the permission prompt by simply setting `media.eme.require-app-approval` to `false`. So this is ultimately a feature that would directly improve the privacy, security, and control for users. > I assume the translations need proper accreditation? What would you have in mind? For reference, the strings I added were taken nearly verbatim from the `strings.xml` files already contained in `mozilla-central` *(under the `mobile/android/android-components/components/feature/sitepermissions/src/main/res` and `mobile/android/fenix/fenix/app/src/main/res` directories - I'll also note that the original `strings.xml` files are licensed under `MPL-2.0` as well, so no conflicts there)*. I did also add comments to the files [here](https://codeberg.org/librewolf/source/src/commit/ad9e8497dfa7b04313df24af22718e6f4631acf8/l10n/en-US/browser/browser/preferences/preferences.inc.ftl#L76) and [here](https://codeberg.org/librewolf/source/src/commit/ad9e8497dfa7b04313df24af22718e6f4631acf8/l10n/en-US/browser/chrome/browser/browser.inc.properties#L3) to document where the strings originated from. But if there's some way I can better/further accredit these, please LMK.

alyx161 commented 2026年05月30日 23:57:35 +02:00

Thanks, that clears things up a little.
Do you have more resources regarding the privacy aspect here?
The EFF reference.. feels very political / opinionated and doesn't really goes much into anything technical.

If there is something more to it it would be great if we could add this to our documentation.
Because, I personally think, the freedom concerns don't really provide an argument for a per site permission.
If anything its just as much a political / opinionated statement as the EFF article.

Thanks, that clears things up a little. Do you have more resources regarding the privacy aspect here? The EFF reference.. feels very political / opinionated and doesn't really goes much into anything technical. If there is something more to it it would be great if we could add this to our documentation. Because, I personally think, the freedom concerns don't really provide an argument for a per site permission. If anything its just as much a political / opinionated statement as the EFF article.

celenity commented 2026年05月31日 06:23:55 +02:00

@alyx161 wrote in #189 (comment):

Thanks, that clears things up a little. Do you have more resources regarding the privacy aspect here? The EFF reference.. feels very political / opinionated and doesn't really goes much into anything technical.

If there is something more to it it would be great if we could add this to our documentation. Because, I personally think, the freedom concerns don't really provide an argument for a per site permission. If anything its just as much a political / opinionated statement as the EFF article.

I agree that the freedom concern isn't really an argument for a per-site permission (though the per-site permission does provide more control over EME and how/when its used), so that's fair. There's a great research paper on this here to provide more details on the technical privacy and security concerns, but a lot of it comes down to concerns with fingerprinting/tracking (due to ex. EME's use of identifiers - websites can also query which CDMs are supported by the user) and the added attack surface.

@alyx161 wrote in https://codeberg.org/librewolf/source/pulls/189#issuecomment-16210412: > Thanks, that clears things up a little. Do you have more resources regarding the privacy aspect here? The EFF reference.. feels very political / opinionated and doesn't really goes much into anything technical. > > If there is something more to it it would be great if we could add this to our documentation. Because, I personally think, the freedom concerns don't really provide an argument for a per site permission. If anything its just as much a political / opinionated statement as the EFF article. I agree that the freedom concern isn't *really* an argument for a per-site permission *(though the per-site permission does provide more control over EME and how/when its used)*, so that's fair. There's a [great research paper on this here](https://arxiv.org/abs/2308.05416) to provide more details on the technical privacy and security concerns, but a lot of it comes down to concerns with fingerprinting/tracking *(due to ex. EME's use of identifiers - websites can also query which CDMs are supported by the user)* and the added attack surface.

any1here commented 2026年06月01日 18:37:13 +02:00

@celenity Would you mind creating a condensed version why one should/shouldn't allow access for the popup to link to?

@celenity Would you mind creating a condensed version why one should/shouldn't allow access for the popup to link to?

celenity commented 2026年06月03日 09:18:27 +02:00

@any1here wrote in #189 (comment):

@celenity Would you mind creating a condensed version why one should/shouldn't allow access for the popup to link to?

Sure, I went ahead and made a PR to document this: librewolf/website#146

@any1here wrote in https://codeberg.org/librewolf/source/pulls/189#issuecomment-16302656: > @celenity Would you mind creating a condensed version why one should/shouldn't allow access for the popup to link to? Sure, I went ahead and made a PR to document this: https://codeberg.org/librewolf/website/pulls/146