feat: Implement EME per-site permission #189
alyx161
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "celenity/source:main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
librewolf.eme.warning.infoURLpref to set the value of the learn more URL for the EME per-site permission promptAny details about why?
I assume the translations need proper accreditation?
@alyx161 wrote in #189 (comment):
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
toolkitcode), 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-approvaltofalse.So this is ultimately a feature that would directly improve the privacy, security, and control for users.
What would you have in mind? For reference, the strings I added were taken nearly verbatim from the
strings.xmlfiles already contained inmozilla-central(under themobile/android/android-components/components/feature/sitepermissions/src/main/resandmobile/android/fenix/fenix/app/src/main/resdirectories - I'll also note that the originalstrings.xmlfiles are licensed underMPL-2.0as 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.
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.
@alyx161 wrote in #189 (comment):
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.
@celenity Would you mind creating a condensed version why one should/shouldn't allow access for the popup to link to?
ad9e8497dfc6955f54f0media.eme.enabled*actually* disable EME + make per-site permission depend onmedia.eme.enabled@any1here wrote in #189 (comment):
Sure, I went ahead and made a PR to document this: librewolf/website#146
e5f8bfaaeddd13379738