Re: [powerful-features] Some comments

Thanks, Richard!

On Wed, Oct 14, 2015 at 7:28 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
> - It would be helpful to be a little more explicit about what the properties
> are that a "secure context" is supposed to entail, in particular, that the
> website is authentic and that interactions are confidential.

The introduction makes that fairly explicit, doesn't it? What would
you like to see in addition to that second paragraph?

> - That discussion of security model would also help better motivate the
> ancestor checking
> * Notion of authenticity starts at the navigation level and carries down the
> ancestor tree
> * If a link in that chain is broken, then the authorization is broken
> * For example: Supposed user intends to access to example.com
>   * But an active attacker injects a script and a malicioius HTTPS iframe
>   * The attacker can then use the HTTPS iframe to extract data
>   * ... just as if the non-secure page had been allowed access

I've added https://w3c.github.io/webappsec-secure-contexts/#ancestors
in the hopes of spelling this out a bit more clearly. WDYT?

> - In Section 5.1, you note that opening a popup can be a way to circumvent
> these separations.  Is there a reason that we're not using window.opener
> state in the same way as iframe parent state?  This still won't get us to
> perfect isolation, but it would close off another major avenue.

I went back and forth on this, and came down on the side of opening
this hole in the interests of supporting navigational popups. In my
anecdotal experience, these are becoming pretty popular on mobile, and
I think it would be unfortunate if a page to which you navigated
couldn't use [insert feature] based on the fact that you came from a
non-secure page.

> - I find the discussion of sandboxed iframes in Section 3.1 confusing.  Is
> the intent here simply for the same rules to apply to sandboxed iframes as
> for regular iframes?

The intent is to treat securely-delivered sandboxes as secure
contexts. That is, if you want to use WebCrypto in a sandboxed iframe,
you should be able to. The sandbox is a strict reduction in the risk
that the context presents.

How would you suggest clarifying that notion?

> - The idea of adding a WebIDL notation to indicate that an object is
> restricted to secure contexts seems like a good idea to me.  I don't really
> care if that goes in this spec or in WebIDL directly.  (cf.
> https://github.com/w3c/webappsec/issues/262)

I think it's reasonable to put this into WebIDL. That's where it will
need to go, one way or the other. If we agree on a definition in that
bug, and add it to the WebIDL document, we can add some non-normative
text to this document, pointing it out.

> Editorial nits:
> - "minimum security bar" -> "minimum security level"
> - "outlines threat models ... and outline normative requirements ..." ->
> "describes threat models ... outlines normative requirements ..."

Done.

> - Section 1.1 might be better titled "Summary"
> - Also, having a 1.1 is unnecessary, since there's no 1.2.

Dropped the 1.1, upgrading 1.1.* to 1.*.

> - The link to "potentially secure origin" is broken

Fixed.

-mike

Received on Thursday, 15 October 2015 08:14:19 UTC