It means there is no need to use the "No Resource URI Leak" add-on [1] anymore.
[1] No Resource URI Leak: Deny resource:// access to Web content: We fill the hole to defend against fingerprinting. Very important to Firefox privacy. A direct workaround for bugzil.la/863246 https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/ -- Ethan Tseng Engineering Manager, Mozilla On Wed, Aug 30, 2017 at 11:36 AM, Chung-Sheng Fu <c...@mozilla.com> wrote: > Hi everyone, > > > == Background == > > Firefox and add-ons use the resource:// scheme to load resources > internally, but some of the information is available to sites the browser > connects to as well. > > This means a web page can run internal scripts and inspect internal > resources of Firefox Browser, including the default preferences, which > could be a serious security and privacy issue. > > == Threats == > > For example, a script on Browserleaks > <https://www.browserleaks.com/firefox> highlights what Firefox reveals > when queried by a simple script running on the site (you can find the code > in https://browserleaks.com/firefox#more). > > The file firefox.js passes preference names and values to the pref() > function. > > Example: http://searchfox.org/mozilla-central/rev/ > 48ea452803907f2575d81021e8678634e8067fc2/browser/app/ > profile/firefox.js#575 > > Web sites can easily collect Firefox default preferences by overriding > this pref() function and using the script “resource:///defaults/ > preferences/firefox.js”. > > Furthermore, some default values of preferences differ between build > configurations, such as platform and locale, which means web sites could > identify individual users using this information. > > == Solution == > > In order to fix these issues, we changed the behavior of loading > resource:// URIs in bug 863246 > <https://bugzilla.mozilla.org/show_bug.cgi?id=863246>, which has been > landed in NIghtly 57. Now, web content is not able to access resource:// > URIs by default, unless the resource:// URI is declared > contentaccessible=yes in the manifests. > > For Mozilla developers who need to load resource:// URIs in the web > content, here are some tips. > > 1. > > Simple resource files: add them to CONTENT_ACCESSIBLE_FILES in > moz.build > > <http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/layout/style/moz.build#305> > and they will be located in resource://content-accessible/. Currently > we have these files moved: > 1. > > resouce://gre/res/ImageDocument.css => > resource://content-accessible/ImageDocument.css > 2. resource://gre/res/TopLevelImageDocument.css => > resource://content-accessible/TopLevelImageDocument.css > 3. resource://gre/res/TopLevelVideoDocument.css => > resource://content-accessible/TopLevelVideoDocument.css > 4. resource://gre-resources/viewsource.css => > resource://content-accessible/viewsource.css > 2. > > Folders: > 1. > > Move your folder to resource://content-accessible/. If not > applicable, > 2. > > Add the contentaccessble=yes flag in jar.mn where you define the > URI mapping, e.g., about:newtab > > <http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/browser/extensions/onboarding/jar.mn#8> > and jsonview > > <http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/devtools/shared/jar.mn#7-8> > . > > > == Follow-up == > > If there is anything which was impacted by this change and not caught by > us, or you are not sure how to deal with resource:// URIs in your case, > please file a bug and set it as depending on bug 863246 > <https://bugzilla.mozilla.org/show_bug.cgi?id=863246>. We will try the > best to resolve the compatibility issue. > > > Best regards, > > Chung-Sheng Fu > > > > _______________________________________________ > SecEng mailing list > sec...@mozilla.org > https://mail.mozilla.org/listinfo/seceng > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
