Closed Bug 1412151 Opened 5 years ago Closed 5 years ago

Allow contentaccessible=yes for locale manifest

Categories

(Core :: XPCOM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox58 --- affected

People

(Reporter: Mardak, Unassigned)

References

Details

In bug 1411452, we're trying to package .js files that contain localized values to allow content-privileged about:home/newtab avoid waiting for messages from main containing those values. However, if we package these files with a locale manifest, we run into NS_ERROR_DOM_BAD_URI:

<script> source URI is not allowed in this document: “chrome://activity-stream/locale/activity-stream-initial-state.js”.

The browser's locale is already exposed via navigator.language, so exposing values that could be used to infer the locale shouldn't increase fingerprintability.
<Mardak> would it be wrong to allow locale manifest entries contentaccessible=yes (instead of only content entries)?
<billm> would that expose the browser's locale to web pages? maybe that's already exposed?
<Mardak> ah i suppose most likely the content of the file would have locale-specific values, so one could figure out the packaged locale, yes. it does seem to be exposed via navigator.language
<billm> well, maybe it's okay then. the main thing we want is to avoid fingerprinting.
There's work to avoid fingerprinting through locale data, those are hooked up to the tracker in bug 1329996.

I also think that this is generally tricky from a security perspective, as it could, in particular on localized builds, give quite some insights into the exact build version someone has installed.
Just to be clear, the set of locales exposed via navigator.language is not the same as languages used by the browser UI.

We separate those two groups and allow users to select which locales they use Firefox in, and which locales they broadcast to the web. The latter is exposed in `navigator.languages` and via Accepted-Locales headers. The former is not accessible from the Web.
Sounds like there would be security and privacy issues of the approach, so I'll just close this.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.