Intent to prototype: Mixed Content Auto Upgrading of display content (image, audio, video)

[Christoph Kerschbaumer]

Summary: This security enhancing feature will automatically upgrade mixed 
display content from HTTP to HTTPS if the top-level document is HTTPS. 
Previously this would result in the mixed content indicator. Loads of type 
image, audio, and video will be upgraded by rewriting the URL from http: to 
https: without any fallback if the resource is not available over HTTPS.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1633743 

Standard: https://w3c.github.io/webappsec-mixed-content/level2.html 

Platform coverage: All

Preference: security.mixed_content.upgrade_display_content

Devtools bug: No extra work is required for devtools.

Other browsers: Chrome has been shipping that behaviour since Chrome 81; no 
public signal from Apple.

web-platform-tests: There are none but we will add some within 
https://bugzilla.mozilla.org/show_bug.cgi?id=1673594 



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

Removing preference for 'treating data: URIs as same origin' in FF83

[Christoph Kerschbaumer]

Hey Everyone,

within Firefox 57, we started to treat data: URIs as unique opaque origins; in 
other words we stopped inheriting the security context for data: URIs. For more 
information see the ‘intent to ship’ from August 2017: 
https://lists.mozilla.org/pipermail/dev-platform/2017-August/019376.html 


Now, three years later it’s time to also remove the pref from our codebase 
entirely, we will do that within 
https://bugzilla.mozilla.org/show_bug.cgi?id=1552168 
 which will land within 
this cycle, Firefox 83.

Thank you,
  Christoph






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

Re: Intent to implement and ship: Referrer Policy for CSS

[Christoph Kerschbaumer]

> On Oct 5, 2018, at 4:25 PM, David Burns  wrote:
> 
> Are there web platform tests for this feature?

Yes there are. Thomas added web platform tests within:
https://bugzilla.mozilla.org/show_bug.cgi?id=1330487 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1330487>


> 
> David
> 
> On Fri, 5 Oct 2018 at 13:32, Christoph Kerschbaumer  <mailto:ckers...@gmail.com>> wrote:
> We just realized we have never sent an intent to implement and ship for 
> extending coverage of Referrer Policy to style sheets. Please accept my 
> apology for not sending the intent-email earlier. Anyway, we are planning to 
> ship that extension of Referrer Policy coverage to CSS in Firefox 64.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1330487 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1330487>
> Link to standard: https://www.w3.org/TR/referrer-policy/#integration-with-css 
> <https://www.w3.org/TR/referrer-policy/#integration-with-css>
> 
> Platform coverage: everywhere.
> 
> Estimated or target release: 64
> 
> Is this feature enabled by default in sandboxed iframes? Yes, it is
> 
> DevTools bug: No devtools support.
> 
> Do other browser engines implement this? Chromium, since 59.
> 
> Is this feature restricted to secure contexts? No, it isn’t.
> 
> Cheers,
>   Christoph
> 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform 
> <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 implement and ship: Referrer Policy for CSS

[Christoph Kerschbaumer]

> On Oct 5, 2018, at 4:20 PM, Boris Zbarsky  wrote:
> 
> On 10/5/18 8:31 AM, Christoph Kerschbaumer wrote:
>> DevTools bug: No devtools support.
> 
> Though it would be nice if we had devtools support for determining the 
> referrer policy that applied to a given request in general.  Do you happen to 
> know whether we already do that, or have a bug on adding it?
> 

I agree, that would be nice. FWIW, I just filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=1496742 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1496742>


> -Boris
> ___
> 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 implement and ship: Referrer Policy for CSS

[Christoph Kerschbaumer]

We just realized we have never sent an intent to implement and ship for 
extending coverage of Referrer Policy to style sheets. Please accept my apology 
for not sending the intent-email earlier. Anyway, we are planning to ship that 
extension of Referrer Policy coverage to CSS in Firefox 64.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1330487
Link to standard: https://www.w3.org/TR/referrer-policy/#integration-with-css

Platform coverage: everywhere.

Estimated or target release: 64

Is this feature enabled by default in sandboxed iframes? Yes, it is

DevTools bug: No devtools support.

Do other browser engines implement this? Chromium, since 59.

Is this feature restricted to secure contexts? No, it isn’t.

Cheers,
  Christoph


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

Re: Intent to implement: Feature Policy

[Christoph Kerschbaumer]

> On Sep 15, 2018, at 12:54 AM, Ehsan Akhgari  wrote:
> 
> We also have https://bugzilla.mozilla.org/show_bug.cgi?id=1449501 open to
> display the CSP policy, perhaps it might make sense to expose both in
> similar ways (or at least for similar contexts, e.g. iframes).

FWIW, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1491748 
 to get some devtools 
support for feature policy.

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

Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 3:30 PM, Mike West <mk...@chromium.org> wrote:
> 
> We do have `worker-src` tests, FWIW: 
> https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/
>  
> <https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/>.
>  We'll likely need to adjust things based on the fallback mechanism y'all are 
> running with (and Chrome will need to drop the weird contortions we 
> implemented for back-compat), but I'd hope you would be able to use those 
> rather than writing mochitests.

Quick update on worker-src:
- We are going to ship worker-src with the fallback to child-src, script-src, 
default-src within Firefox 58.
- There are some web-platform-tests, as pointed out by Mike, which we are going 
to extend within [1] to account for the fallback.

Thanks,
  Christoph

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1409706

> 
> -mike
> 
> On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer <ckers...@gmail.com 
> <mailto:ckers...@gmail.com>> wrote:
> 
> > On Oct 18, 2017, at 11:41 AM, James Graham <ja...@hoppipolla.co.uk 
> > <mailto:ja...@hoppipolla.co.uk>> wrote:
> >
> > On 18/10/17 10:35, Christoph Kerschbaumer wrote:
> >>> On Oct 18, 2017, at 11:25 AM, James Graham <ja...@hoppipolla.co.uk 
> >>> <mailto:ja...@hoppipolla.co.uk>> wrote:
> >>>
> >>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
> >>>> Hey Everyone,
> >>>> within CSP2 workers used to be governed by the child-src directive [0]. 
> >>>> CSP3 introduces the worker-src directive [1] wich governs Workers, 
> >>>> SharedWorkers as well as ServiceWorkers. Please note that the child-src 
> >>>> directive has been deprecated within CSP3 in favor of worker-src as well 
> >>>> as frame-src.
> >>>> For backwards compatibility child-src will still be enforced for:
> >>>>   * workers (if worker-src is not explicitly specified)
> >>>>   * frames  (if frame-src is not explicitly specified)
> >>>> We plan to ship the CSP directive worker-src within Firefox 58.
> >>>
> >>> Do we have cross-browser (i.e. web-platform) tests for this feature?
> >> Not yet. We just agreed with Chrome on the same fallback mechanism, see 
> >> [1].
> >> We are about to add mochitests for all the different fallback mechanisms 
> >> though.
> >
> > What's the reason for writing mochitests? It seems like this is something 
> > where we benefit from shared tests.
> 
> Reason is simple, I have already written the mochitests for it. But I agree, 
> we should have web-platform tests for it.
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform 
> <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 ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 11:41 AM, James Graham <ja...@hoppipolla.co.uk> wrote:
> 
> On 18/10/17 10:35, Christoph Kerschbaumer wrote:
>>> On Oct 18, 2017, at 11:25 AM, James Graham <ja...@hoppipolla.co.uk> wrote:
>>> 
>>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>>>> Hey Everyone,
>>>> within CSP2 workers used to be governed by the child-src directive [0]. 
>>>> CSP3 introduces the worker-src directive [1] wich governs Workers, 
>>>> SharedWorkers as well as ServiceWorkers. Please note that the child-src 
>>>> directive has been deprecated within CSP3 in favor of worker-src as well 
>>>> as frame-src.
>>>> For backwards compatibility child-src will still be enforced for:
>>>>   * workers (if worker-src is not explicitly specified)
>>>>   * frames  (if frame-src is not explicitly specified)
>>>> We plan to ship the CSP directive worker-src within Firefox 58.
>>> 
>>> Do we have cross-browser (i.e. web-platform) tests for this feature?
>> Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
>> We are about to add mochitests for all the different fallback mechanisms 
>> though.
> 
> What's the reason for writing mochitests? It seems like this is something 
> where we benefit from shared tests.

Reason is simple, I have already written the mochitests for it. But I agree, we 
should have web-platform tests for it.

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

Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 11:25 AM, James Graham <ja...@hoppipolla.co.uk> wrote:
> 
> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>> Hey Everyone,
>> within CSP2 workers used to be governed by the child-src directive [0]. CSP3 
>> introduces the worker-src directive [1] wich governs Workers, SharedWorkers 
>> as well as ServiceWorkers. Please note that the child-src directive has been 
>> deprecated within CSP3 in favor of worker-src as well as frame-src.
>> For backwards compatibility child-src will still be enforced for:
>>   * workers (if worker-src is not explicitly specified)
>>   * frames  (if frame-src is not explicitly specified)
>> We plan to ship the CSP directive worker-src within Firefox 58.
> 
> Do we have cross-browser (i.e. web-platform) tests for this feature?

Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
We are about to add mochitests for all the different fallback mechanisms though.

[1] https://github.com/w3c/webappsec-csp/issues/239#issuecomment-337488401

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

Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Sep 22, 2017, at 4:24 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Fri, Sep 22, 2017 at 4:18 PM, Christoph Kerschbaumer
> <ckers...@gmail.com> wrote:
>> We plan to ship the CSP directive worker-src within Firefox 58.
> 
> Will we also start enforcing script-src for workers? It seems good
> that if you restrict script it actually stops all scripts.

If worker-src is not present in an enforced policy, but script-src is, then yes.


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

Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

Hey Everyone,

within CSP2 workers used to be governed by the child-src directive [0]. CSP3 
introduces the worker-src directive [1] wich governs Workers, SharedWorkers as 
well as ServiceWorkers. Please note that the child-src directive has been 
deprecated within CSP3 in favor of worker-src as well as frame-src.

For backwards compatibility child-src will still be enforced for:
  * workers (if worker-src is not explicitly specified)
  * frames  (if frame-src is not explicitly specified)

We plan to ship the CSP directive worker-src within Firefox 58.

Overall progress will be tracked here [2].

Thanks,
  Christoph

[0] https://www.w3.org/TR/CSP2/#directive-child-src
[1] https://w3c.github.io/webappsec-csp/#directive-worker-src
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1302667

___
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]

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

[Christoph Kerschbaumer]

> On Sep 15, 2017, at 7:14 PM, Alex Gaynor <agay...@mozilla.com> 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 <ckers...@gmail.com 
> <mailto:ckers...@gmail.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 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1380959> 
> <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 <https://mzl.la/2x5pGRX> <https://mzl.la/2x5pGRX 
> <https://mzl.la/2x5pGRX>>
> [2] https://msdn.microsoft.com/en-us/library/cc848897.aspx 
> <https://msdn.microsoft.com/en-us/library/cc848897.aspx> 
> <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 <mailto:dev-platform@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform 
> <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

Re: Intent to ship: Treating 'data:' documents as unique, opaque origins

[Christoph Kerschbaumer]

> On 11 Aug 2017, at 23:08, s.h.h.n@gmail.com wrote:
> 
> When are you expecting to land this to nightly?

There are a few more tests to convert to comply with the new data URI 
inheritance model and some other cleanups. Let's target Monday, 21st of august 
to flip the switch.

> ___
> 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 ship: Treating 'data:' documents as unique, opaque origins

[Christoph Kerschbaumer]

Hey Everyone,

we plan to change the handling of data: URLs for FF57. Rather than inheriting 
the origin of the settings object responsible for the navigation, data: URIs 
will be treated as unique, opaque origins [0]. In other words, data: URLs 
loaded inside an iframe are not same-origin with their including context 
anymore. Not only will that behavior mitigate the risk of XSS, it will also 
make Firefox spec compliant [0] and compliant with the behavior of other 
browsers which all have been shipping that behavior for a long time.

Over the past weeks we have converted hundreds of tests within our test suite 
to comply with the new data: URI inheritance model. Please note that we have 
test coverage for both worlds, the new, as well as the old behavior. By now we 
have a green TRY run for Linux, but have to do a few follow ups for other 
platforms since some of the failing tests were disabled on Linux. Anyway, 
currently this feature lives behind the pref 
|security.data_uri.unique_opaque_origin| which we plan to flip for FF57 so 
data: documents become unique, opaque, origins.

Even though we have good test coverage we are currently extending web platform 
tests to make sure behavior is consistent across browsers. We don’t think that 
adding those additional tests should hold us back from flipping the pref. 
Ideally we suggest to flip the pref rather sooner than later to eliminate 
potential issues early in Nightly.

Overall progress of the project will be tracked here [1].

Thanks,
 Christoph, Ethan, Henry, and Yoshi

[0] https://html.spec.whatwg.org/multipage/origin.html#origin 

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 

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

Changing the behavior for inheriting the Security Context of data: URLs

[Christoph Kerschbaumer]

Hey everyone,

we are in the process of changing the handling of data: URLs to which user 
agents navigate. Rather than inheriting the origin of the settings object 
responsible for the navigation, they will be treated as unique, opaque origins. 
In other words that means that data: URLs loaded inside an iframe are not 
same-origin with their including context anymore. (Other browsers are already 
doing that). Overall progress of the project will be tracked here [1].

Important when adding new tests:
At the moment we are updating our test suite to align with this new security 
inheritance model. Please do *not* add new tests that rely on the old security 
inheritance model. If in doubt, please flip the pref 
security.data_uri.inherit_security_context [2] to make sure your test succeeds 
before landing on inbound.

Cheers,
  Christoph

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 
 - Treat 'data:' 
documents as unique, opaque origins
[2] https://hg.mozilla.org/mozilla-central/rev/c11fe7c58837#l1.14 


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

NewChannel API deprecated

[Christoph Kerschbaumer]

Hi everyone,

we are about to move security checks from 'before creating a channel' in
Gecko to 'when the channel is actually opened' in Necko.
We do this for several reasons:

(i) If no security check is performed in Gecko before creating the channel,
then no security check is performed at all. We would like to move away from
that practice and make sure that security checks are always performed
before a channel is opened. Also, different channels need different
security checks (SOP, CORS, CSP, MixedContent, etc.) and it was hard to
follow what security checks are performed at each callsite. When moving
security checks into Necko, we have one central point, that all channels
have to pass through before the channel is actually allowed to be opened.

(ii) Once a channel was created, we didn't know who initiated the load or
what content type the channel is loading. Hence we attach a loadInfo object
at creation time of every channel. This loadinfo allows us to reason about
security throughout the lifetime of a channel. From now on, we don't allow
any channels to be created using the old NewChannel-API. Please use
NewChannel2 and provide the necessary security/loadinfo arguments. Please
find a description of each argument here [1].

(iii) Further, this loadInfo also allows us to perform security checks
after redirects at one central point in our code.


=== Attention Addon developers ===
Addons using the deprecated NewChannel-API will continue to work in release
code. If used in debug builds however, those addons will also hit the newly
added assertions in NewChannel (see [2]). Please be aware and start
migrating your addons to use new NewChannel2 API for creating channels.

I am happy to answer any additional questions!

Cheers,
  Christoph


[1]
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl#73
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1162657
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform