- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 23 Oct 2014 17:21:55 +1100
- To: WebAppSec WG <public-webappsec@w3.org>
Hi, 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... :) Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 23 October 2014 06:22:20 UTC