Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Christoph Kerschbaumer]

Hey Ehsan,

> On Sep 15, 2017, at 9:28 PM, Ehsan Akhgari  wrote:
> I'm worries about the "FF57" part of this paragraph.  There is almost no time 
> left to test this kind of change on Nightly so this will probably get tested 
> for the first few betas of 57.  Even though the 0.01% number may look too 
> low, is that number enough to give us confidence to do this so late in the 57 
> cycle, given the current focus in avoiding to introduce risk into this 
> release?

we are aware of that risk, that’s why we currently plan to identify fallouts on 
Nightly and Early Beta. I know it’s late in the 57 cycle and I can ensure you 
we are not going to ship that change in behavior if it seems risky for any 
reason.

Cheers,
  Christoph

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

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Ehsan Akhgari]

Hi Christoph,

On 09/15/2017 01:08 PM, Christoph Kerschbaumer wrote:

Hey Everyone,

we plan to prevent web pages from navigating the top-level window to a data: 
URI. Historically data: URIs caused confusion for end users; mostly because end 
users are not aware that data: URIs can encode untrusted content into a URL. 
The fact that data: URIs can execute JavaScript makes them popular amongst 
scammers for spoofing and phishing attacks.

Fantastic!


To mitigate that risk we installed a pref 
(“security.data_uri.block_toplevel_data_uri_navigations”) which blocks all 
top-level navigations to a data: URI. We plan to flip that pref in Nightly 
using “ifdef EARLY_BETA_OR_EARLIER”. In a few weeks we will evaluate whether we 
can flip on that change in behavior for FF57 or whether we are going to wait to 
ship that change in behavior till FF58.


I'm worries about the "FF57" part of this paragraph.  There is almost no 
time left to test this kind of change on Nightly so this will probably 
get tested for the first few betas of 57.  Even though the 0.01% number 
may look too low, is that number enough to give us confidence to do this 
so late in the 57 cycle, given the current focus in avoiding to 
introduce risk into this release?  Also have we looked more into what 
the 0.01% number of navigations which would have been blocked are coming 
from?  For example, hypothetically speaking, do they mostly come from 
external applications?


Thanks,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Michael Kelly]

On 9/15/17 10:08 AM, Christoph Kerschbaumer wrote:
> To mitigate that risk we installed a pref 
> (“security.data_uri.block_toplevel_data_uri_navigations”) which blocks all 
> top-level navigations to a data: URI. We plan to flip that pref in Nightly 
> using “ifdef EARLY_BETA_OR_EARLIER”. In a few weeks we will evaluate whether 
> we can flip on that change in behavior for FF57 or whether we are going to 
> wait to ship that change in behavior till FF58.

This seems like it might be a good candidate for running a Shield
preference-flip study: https://wiki.mozilla.org/Firefox/SHIELD

- Mike Kelly
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Alex Gaynor]

You read my mind -- thanks!

Alex

On Fri, Sep 15, 2017 at 1:16 PM, Christoph Kerschbaumer 
wrote:

>
> On Sep 15, 2017, at 7:14 PM, Alex Gaynor  wrote:
>
> Hi Christoph,
>
> Great stuff!
>
> Are external applications able to trigger loads of data:, e.g. a desktop
> mail application, via the OS protocol handler facilities?
>
>
> Sorry I forgot to mention that explicitly. Since scammers mostly trick
> users by sending emails, those navigations to data: URIs will also be
> blocked.
>
> Alex
>
> On Fri, Sep 15, 2017 at 1:08 PM, Christoph Kerschbaumer  com> wrote:
>
>> Hey Everyone,
>>
>> we plan to prevent web pages from navigating the top-level window to a
>> data: URI. Historically data: URIs caused confusion for end users; mostly
>> because end users are not aware that data: URIs can encode untrusted
>> content into a URL. The fact that data: URIs can execute JavaScript makes
>> them popular amongst scammers for spoofing and phishing attacks.
>>
>> To mitigate that risk we installed a pref 
>> (“security.data_uri.block_toplevel_data_uri_navigations”)
>> which blocks all top-level navigations to a data: URI. We plan to flip that
>> pref in Nightly using “ifdef EARLY_BETA_OR_EARLIER”. In a few weeks we will
>> evaluate whether we can flip on that change in behavior for FF57 or whether
>> we are going to wait to ship that change in behavior till FF58.
>>
>> In more detail, the following cases will be:
>> BLOCKED:
>>  * Navigating to a new top-level data: URI document using:
>>- window.open("data:...");
>>- window.location = "data:..."
>>- clicking > etc).
>>  * Redirecting to a new top-level data: URI document using:
>>- 302 redirects to "data:..."
>>- meta refresh to "data:..."
>>
>> ALLOWED:
>>  * User explicitly entering/pasting "data:..." into the URL bar
>>  * Opening "data:image/*" in top-level window, unless it's
>> "data:image/svg+xml"
>>  * Opening “data:application/pdf” in top-level window
>>  * Downloading a data: URI, e.g. 'save-link-as' of "data:..."
>>
>> Our telemetry indicates that Firefox would have blocked 0.01% of all
>> loads in 55 release. It’s unfortunate that the permalink [1] for
>> DOCUMENT_DATA_URI_LOADS stopped working today, so you have to take my word
>> for it. To be fair, those telemetry numbers include all top-level data: URI
>> navigations. Recently we have refined our blocking mechanism and
>> deactivated blocking data:image/* loads as well as data:application/pdf, so
>> we expect the blockage number to be even smaller.
>>
>> Please note that IE/Edge never supported data: URI navigations [2].
>> Chrome started to print a deprecation warning for top-level data: URI
>> navigations within M57 and started to block such navigations within M60.
>>
>> Overall progress of the project will be tracked here:
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=1380959 > ttps://bugzilla.mozilla.org/show_bug.cgi?id=1380959>
>>
>> Thanks,
>>  Christoph
>>
>> [1] https://mzl.la/2x5pGRX 
>> [2] https://msdn.microsoft.com/en-us/library/cc848897.aspx <
>> https://msdn.microsoft.com/en-us/library/cc848897.aspx>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Christoph Kerschbaumer]

> On Sep 15, 2017, at 7:14 PM, Alex Gaynor  wrote:
> 
> Hi Christoph,
> 
> Great stuff!
> 
> Are external applications able to trigger loads of data:, e.g. a desktop mail 
> application, via the OS protocol handler facilities?

Sorry I forgot to mention that explicitly. Since scammers mostly trick users by 
sending emails, those navigations to data: URIs will also be blocked. 

> Alex
> 
> On Fri, Sep 15, 2017 at 1:08 PM, Christoph Kerschbaumer  > wrote:
> Hey Everyone,
> 
> we plan to prevent web pages from navigating the top-level window to a data: 
> URI. Historically data: URIs caused confusion for end users; mostly because 
> end users are not aware that data: URIs can encode untrusted content into a 
> URL. The fact that data: URIs can execute JavaScript makes them popular 
> amongst scammers for spoofing and phishing attacks.
> 
> To mitigate that risk we installed a pref 
> (“security.data_uri.block_toplevel_data_uri_navigations”) which blocks all 
> top-level navigations to a data: URI. We plan to flip that pref in Nightly 
> using “ifdef EARLY_BETA_OR_EARLIER”. In a few weeks we will evaluate whether 
> we can flip on that change in behavior for FF57 or whether we are going to 
> wait to ship that change in behavior till FF58.
> 
> In more detail, the following cases will be:
> BLOCKED:
>  * Navigating to a new top-level data: URI document using:
>- window.open("data:...");
>- window.location = "data:..."
>- clicking  etc).
>  * Redirecting to a new top-level data: URI document using:
>- 302 redirects to "data:..."
>- meta refresh to "data:..."
> 
> ALLOWED:
>  * User explicitly entering/pasting "data:..." into the URL bar
>  * Opening "data:image/*" in top-level window, unless it's 
> "data:image/svg+xml"
>  * Opening “data:application/pdf” in top-level window
>  * Downloading a data: URI, e.g. 'save-link-as' of "data:..."
> 
> Our telemetry indicates that Firefox would have blocked 0.01% of all loads in 
> 55 release. It’s unfortunate that the permalink [1] for 
> DOCUMENT_DATA_URI_LOADS stopped working today, so you have to take my word 
> for it. To be fair, those telemetry numbers include all top-level data: URI 
> navigations. Recently we have refined our blocking mechanism and deactivated 
> blocking data:image/* loads as well as data:application/pdf, so we expect the 
> blockage number to be even smaller.
> 
> Please note that IE/Edge never supported data: URI navigations [2]. Chrome 
> started to print a deprecation warning for top-level data: URI navigations 
> within M57 and started to block such navigations within M60.
> 
> Overall progress of the project will be tracked here:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1380959 
>  
>  >
> 
> Thanks,
>  Christoph
> 
> [1] https://mzl.la/2x5pGRX   >
> [2] https://msdn.microsoft.com/en-us/library/cc848897.aspx 
>  
>  >
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

[Alex Gaynor]

Hi Christoph,

Great stuff!

Are external applications able to trigger loads of data:, e.g. a desktop
mail application, via the OS protocol handler facilities?

Alex

On Fri, Sep 15, 2017 at 1:08 PM, Christoph Kerschbaumer 
wrote:

> Hey Everyone,
>
> we plan to prevent web pages from navigating the top-level window to a
> data: URI. Historically data: URIs caused confusion for end users; mostly
> because end users are not aware that data: URIs can encode untrusted
> content into a URL. The fact that data: URIs can execute JavaScript makes
> them popular amongst scammers for spoofing and phishing attacks.
>
> To mitigate that risk we installed a pref (“security.data_uri.block_
> toplevel_data_uri_navigations”) which blocks all top-level navigations to
> a data: URI. We plan to flip that pref in Nightly using “ifdef
> EARLY_BETA_OR_EARLIER”. In a few weeks we will evaluate whether we can flip
> on that change in behavior for FF57 or whether we are going to wait to ship
> that change in behavior till FF58.
>
> In more detail, the following cases will be:
> BLOCKED:
>  * Navigating to a new top-level data: URI document using:
>- window.open("data:...");
>- window.location = "data:..."
>- clicking  etc).
>  * Redirecting to a new top-level data: URI document using:
>- 302 redirects to "data:..."
>- meta refresh to "data:..."
>
> ALLOWED:
>  * User explicitly entering/pasting "data:..." into the URL bar
>  * Opening "data:image/*" in top-level window, unless it's
> "data:image/svg+xml"
>  * Opening “data:application/pdf” in top-level window
>  * Downloading a data: URI, e.g. 'save-link-as' of "data:..."
>
> Our telemetry indicates that Firefox would have blocked 0.01% of all loads
> in 55 release. It’s unfortunate that the permalink [1] for
> DOCUMENT_DATA_URI_LOADS stopped working today, so you have to take my word
> for it. To be fair, those telemetry numbers include all top-level data: URI
> navigations. Recently we have refined our blocking mechanism and
> deactivated blocking data:image/* loads as well as data:application/pdf, so
> we expect the blockage number to be even smaller.
>
> Please note that IE/Edge never supported data: URI navigations [2]. Chrome
> started to print a deprecation warning for top-level data: URI navigations
> within M57 and started to block such navigations within M60.
>
> Overall progress of the project will be tracked here:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1380959 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1380959>
>
> Thanks,
>  Christoph
>
> [1] https://mzl.la/2x5pGRX 
> [2] https://msdn.microsoft.com/en-us/library/cc848897.aspx <
> https://msdn.microsoft.com/en-us/library/cc848897.aspx>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Blocking Top-level Navigations to a data: URI

[Christoph Kerschbaumer]

Hey Everyone,

we plan to prevent web pages from navigating the top-level window to a data: 
URI. Historically data: URIs caused confusion for end users; mostly because end 
users are not aware that data: URIs can encode untrusted content into a URL. 
The fact that data: URIs can execute JavaScript makes them popular amongst 
scammers for spoofing and phishing attacks.

To mitigate that risk we installed a pref 
(“security.data_uri.block_toplevel_data_uri_navigations”) which blocks all 
top-level navigations to a data: URI. We plan to flip that pref in Nightly 
using “ifdef EARLY_BETA_OR_EARLIER”. In a few weeks we will evaluate whether we 
can flip on that change in behavior for FF57 or whether we are going to wait to 
ship that change in behavior till FF58.

In more detail, the following cases will be:
BLOCKED:
 * Navigating to a new top-level data: URI document using:
   - window.open("data:...");
   - window.location = "data:..."
   - clicking https://bugzilla.mozilla.org/show_bug.cgi?id=1380959 


Thanks,
 Christoph

[1] https://mzl.la/2x5pGRX 
[2] https://msdn.microsoft.com/en-us/library/cc848897.aspx 


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