W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

[MIX] feedback

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 23 Oct 2014 17:21:55 +1100
Message-Id: <7685AEAB-1235-45C3-BE18-F3637BAE2D9C@mnot.net>
To: WebAppSec WG <public-webappsec@w3.org>

I looked over the 14 September ED, and overall this looks good to me; mostly editorial suggestions / questions below (perhaps excepting the first issue).

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

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

Is it really necessary to refer to the CAB guidelines for "Internal Name"? That just says "if it doesn't have a TLD...".

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

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

# Section 2 - authenticated environment

What does "impossible not to trust" mean -- how do I evaluate that?

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

# Section 4.3 Form Submission

"MAY optionally" is repeating yourself...

# Section 4.5 User Controls

You need to cite RFC6919 here, and add it to Document Conventions.

# Integration with Fetch

> This is certainly the intent.

That's good to know... :)


Mark Nottingham   https://www.mnot.net/
Received on Thursday, 23 October 2014 06:22:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC