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 ins
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 the
> 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.
>
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
y. 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 <mailto:ckers...@gmail.com>> wrote:
> Hey Everyone,
>
> we plan to prevent web pages fro
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 t
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 we
> On Sep 22, 2017, at 4:24 PM, Anne van Kesteren wrote:
>
> On Fri, Sep 22, 2017 at 4:18 PM, Christoph Kerschbaumer
> 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
>
> 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
> child-src will also ha
> On Oct 18, 2017, at 11:25 AM, James Graham 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
> On Oct 18, 2017, at 11:41 AM, James Graham wrote:
>
> On 18/10/17 10:35, Christoph Kerschbaumer wrote:
>>> On Oct 18, 2017, at 11:25 AM, James Graham wrote:
>>>
>>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>>>> Hey Everyone,
>>&
ttps://bugzilla.mozilla.org/show_bug.cgi?id=1409706
>
> -mike
>
> On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer <mailto:ckers...@gmail.com>> wrote:
>
> > On Oct 18, 2017, at 11:41 AM, James Graham > <mailto:ja...@hoppipolla.co.uk>> wrote:
>
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
> 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://bugz
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:
> 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
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 sen
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
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
19 matches
Mail list logo
