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

2018-10-05 Thread Christoph Kerschbaumer
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

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

2018-10-05 Thread 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 req

Intent to implement and ship: Referrer Policy for CSS

2018-10-05 Thread 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.

Re: Intent to implement: Feature Policy

2018-09-17 Thread 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

Re: Intent to ship: CSP directive worker-src

2017-10-30 Thread Christoph Kerschbaumer
hristoph [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...@hoppip

Re: Intent to ship: CSP directive worker-src

2017-10-18 Thread 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,

Re: Intent to ship: CSP directive worker-src

2017-10-18 Thread 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 d

Re: Intent to ship: CSP directive worker-src

2017-09-25 Thread Christoph Kerschbaumer
> On Sep 22, 2017, at 10:27 PM, Daniel Veditz wrote: > ​Christoph said > For backwards compatibility child-src will still be enforced for: > * workers (if worker-src is not explicitly specified) > > ​But the spec says the fallback is script-src. Surely anyone who uses >

Re: Intent to ship: CSP directive worker-src

2017-09-22 Thread 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 st

Intent to ship: CSP directive worker-src

2017-09-22 Thread 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

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

2017-09-15 Thread 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

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

2017-09-15 Thread Christoph Kerschbaumer
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 Ev

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

2017-09-15 Thread 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

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

2017-08-12 Thread 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. >

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

2017-08-08 Thread 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

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

2017-04-05 Thread 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

NewChannel API deprecated

2015-05-18 Thread 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.