Re: [MIX] feedback

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.


> # 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.


> # 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.


> # 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)"?


> # 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? :)

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)