Re: [MIX] feedback

> On 23 Oct 2014, at 6:19 pm, Mike West <mkwst@google.com> wrote:
> 
> Thanks for the feedback, Mark! TL;DR: I've landed https://github.com/w3c/webappsec/commit/93f0a50aced3f67c7e60f6c57759f213368b0159 and https://github.com/w3c/webappsec/commit/5d32821b21f3cb06a651c966f729b3044292a08a to address some of the concerns.
> 
> On Thu, Oct 23, 2014 at 8:21 AM, Mark Nottingham <mnot@mnot.net> wrote:
> # Section 2 - JavaScript global environment
> 
> Is it really necessary to define the scope of what's happening here in terms of the JS global environment? I know we're in a pretty JS-centric world, but am a bit surprised we don't have a better term for this, especially since HTML5 defers to ECMA for the definition.
> 
> I agree. You'll be happy to note that Hixie and Anne agreed as well. :) The latest editor's draft is https://w3c.github.io/webappsec/specs/mixedcontent using the environment settings object and its related browsing context throughout.
>  
> # Section 2 - private URl
> 
> RFC4632 defines CIDR blocks generally; for the loopback/link local address ranges, use RFC6890. For localhost, use RFC6761. RFC6761 might also be useful for .local here.
> 
> Sounds good, thanks for the pointers.
>  
> Is it really necessary to refer to the CAB guidelines for "Internal Name"? That just says "if it doesn't have a TLD...".
> 
> "A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database."
> 
> *shrug* Seems specific enough to defer to that document. Especially since that's the only document which governs server names for which CAs can actually issue certificates.
> 
> +Ryan, who might have a thought here.
>  
> Just a side note - this concept seems to be popping up more, and no doubt will continue; e.g., see [WPD](http://tools.ietf.org/html/draft-nottingham-web-proxy-desc-01#section-2). I wonder if it's worth a separate document...
> 
> I think there's vague concensus in this WG to split the public/private distinction out of MIX and into something else. See the Internet of Things thread over there to the side of this one.

+1 to that then -- not only proxy behaviour, but lots of other potential uses, I think.


>  # Section 2 - potentially secure URL
> 
> You need a reference to RFC6454 here (or explicitly say something like "see below"); otherwise, users will interpret "globally unique identifier" naturally, and that covers a lot of ground (such as domain names). Yes, I know it's linked, but that's a bit subtle, because frankly it's a bad term considering how people already use that phrase.
> 
> *shrug* I don't think it's confusing, but links are cheap.
>  
> # Section 2 - authenticated environment
> 
> What does "impossible not to trust" mean -- how do I evaluate that?
> 
> It's meant to refer to `file:` and loopback URLs. If you don't trust the machine you're working on, you're just flat out screwed. We are obligated to take that as the basis, meaning that those URLs can't be untrusted.

Don't disagree; it's just that this working is making a lot of assumptions about the reader and their context.


>  # Section 4.1 - Resource Fetching
> 
> > 4. Requests for optionally-blockable resources which are mixed content MAY be modified to reduce the risk to users. For example, cookies and other authentication tokens could be stripped from the requests, or the user agent could automatically change the protocol of the requested URL to HTTPS in certain cases.
> 
> Is there an explicit intent here to prevent good interop in these optional cases? Not saying that's a necessarily bad thing, just wondering.
> 
> Less an intent to prevent interop, more an intent to allow and encourage browser vendors to experiment in ways that increase security and privacy. If Firefox does something clearly awesome here, it's a good bet that I'll land it in Blink. And vice versa, I imagine.

I read this as encouraging conflicting behaviours, so that interop in this area won't emerge, thereby encouraging authors to avoid this kind of content. Which may be a good outcome.


> # Section 4.3 Form Submission
> 
> "MAY optionally" is repeating yourself...
> 
> How about "MAY optionally (but are not obligated to and could choose to do something else even if that something else differs from what's written here)"?

I was thinking either "MAY" or "optionally"...

But really, this is a nit that's not worth iteration.


>  # Section 4.5 User Controls
> 
> You need to cite RFC6919 here, and add it to Document Conventions.
> 
> Yes. All jokes are better when they're explained by an RFC. Should that be a normative or non-normative reference? :)

Your call, I think...


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 23 October 2014 07:37:52 UTC