Re: [webappsec] Rechartering: force secure-only child browsing contexts

At N+1 layer of nesting, yes.

  Since there is interest, here's a more thorough summary:

  The essence of the request was, from sites that are https-only but
include content from ad networks, "Don't allow anything in an iframe to
break the top-level secure UI treatment that we have worked so hard to
get."

  Sentiment in the group was mixed:  Allowing a parent to force, e.g.
script content from a child to not load can break that child in unexpected
ways, including related to security.  But if the content was not over
https anyway, there was little sympathy for the idea that it was secure to
begin with.

  I think the group might be convinced to reconsider if a more concrete
proposal describing the goals and a means of enforcing it were proposed,
and someone wanted to step up to own editing/testing the feature.  I think
dropping this was mostly done out of the need to triage a very big
wishlist down to what we have resources to manage, more than it was
principled objections.

-Brad

On 11/10/14, 1:11 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

>On Mon, Nov 10, 2014 at 1:07 AM, Brad Hill <hillbrad@gmail.com> wrote:
>> Based on our survey results and discussion at TPAC, there is strong
>> consensus NOT chartering work on enforcing secure only child browsing
>> contexts at any level of nesting.
>>
>> The consensus was that this could be handled reasonably with existing
>> mechanisms, such as only framing content from origins that themselves
>> express an HSTS policy.
>
>How exactly is that enforcement? The user can easily navigate away, no?
>
>
>-- 
>https://urldefense.proofpoint.com/v1/url?u=https://annevankesteren.nl/&k=Z

>VNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=prmMr
>Ziza1oM5owFGi5aP4sufTKKq66r1erMW3QXhog%3D%0A&s=b243b3ac2d304127b8b57154d5a
>aac5ab4e0dcefbabd6d77c3368c34d2bffef6
>

Received on Monday, 10 November 2014 18:45:25 UTC