Re: [seceng] Changed the loading behavior of resource:// URI since Nightly 57

[Ethan Tseng]

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  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
>  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
> , 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
>
> 
>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
>   
> 
>   and jsonview
>   
> 
>   .
>
>
> == 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
> .  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

Changed the loading behavior of resource:// URI since Nightly 57

[Chung-Sheng Fu]

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 
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
, 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
   

   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
  

  and jsonview
  

  .


== 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
.  We will try the
best to resolve the compatibility issue.


Best regards,

Chung-Sheng Fu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform