Discussing behaviour for browser extensions

[carlosjeurissen]

How should the proposal to limit the amount of languages returned in navigator.languages be handled in browser extension environments and content-scripts? Should navigator.languages and browser.i18n.getAcceptLanguages return the full list or the limited list for browser extensions?

This question popped up after discussing deprecating browser.i18n.getAcceptLanguages in favour of navigator.languages in the webExtensions w3c community.

[Tanych]

@carlosjeurissen Thanks for your information. Ideally, we expect to reduce chrome.i18n.getAcceptLanguages as well, which will only return a single language for browser extensions. Currently chrome.i18n.getAcceptLanguages is directly reading the accept-language from language prefs.
The initial proposal focuses on limiting the HTTP header and JS getter navigator.languages. We might reduce the chrome.i18n.getAcceptLanguages as well in the future phase. For now, I am interested in understanding the impacts when the language reduces to one for the browser extension. It can be an option if we are going to deprecate the i18n.getAcceptLanguages after we understand the impacts.

[hanguokai]

@Tanych an extension page(chrome-extension://) like static website on localhost. They are handled by the browser directly. There is no server side, no HTTP accept-language header negotiation. So the impacts like a static website without server.

Extensions have built-in i18n support. It should not be affected. But due to its functional limitations, such as don't support for switching languages, some extensions use their own i18n solution or third-party javascript i18n libraries. These extensions are affected like static websites.

[carlosjeurissen]

@Tanych the fact accept-language gets reduced makes browser.i18n.getAcceptLanguages useful again. An extension would be able to get the language(s) which the website receives using navigator.language and navigator.languages, while having the full range available using browser.i18n.getAcceptLanguages.

Cutting off browser.i18n.getAcceptLanguages as well seems problematic as described by @hanguokai. There is no plan-b like the content header negotiation. And the list of languages is used for localisation and language-related extensions. What would be the motivation to also reduce browser.i18n.getAcceptLanguages? Seems best to keep it as is.

[Tanych]

@hanguokai @carlosjeurissen , thanks for the information and feedback. Our goal is to minimize passive fingerprinting for the Accept-Language without breaking legitimate content negotiation user cases.

What would be the motivation to also reduce browser.i18n.getAcceptLanguages?

If I understand the extension correctly, the major concern is an extension can still learn user's full accept-language list without users' awareness and send or store to somewhere, which can give up a lot of entropy about the user.

[hanguokai]

If I understand the extension correctly, the major concern is an extension can still learn user's full accept-language list without users' awareness

Yes. Keep it in extension api, because there is no server side for extension pages.

and send or store to somewhere, which can give up a lot of entropy about the user.

No. Extensions only use javascript api get languages list for i18n work. It doesn't send or store it. For example, when extensions use fetch(url) api, it follows your proposal(only one language in HTTP header). Extensions on the Web store are reviewed and audited by reviewers, and follow the web store privacy policy.

[Tanych]

@hanguokai thanks for the clarification. I feel less concern right now and keeping it in extension api makes sense to me. I will also confirm within the team and make sure it won't cause huge impacts for existing behavior.