- From: timeless <timeless@gmail.com>
- Date: Tue, 11 Nov 2014 04:20:55 -0500
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Mike West wrote: > I've accepted most of your feedback right off, but one or two things > deserve a note; I'll do that inline. > > I rephrased this to "A resource’s TLS-protection is said to be deprecated > if a user agent refuses to trust the resource’s TLS handshake, even if it > doesn’t sink down to the level of weakly TLS-protected. This determination > is vendor-specific." > > Does that make more sense? Yes >> > An origin can be called authenticated when it either refers to a source >> which is impossible not to trust (e.g. localhost), >> File:///localhost/Users/untrusted/Public/index.html >> File:///localhost/Volumes/downloaded-disk-image/index.html >> Http://localhost:9234/ >> >> Perhaps some notes about objects not owned / owned by the current >> user, and lacking any "taint" bits? > We've dropped the `authenticated` bit, but the point you're making is still > relevant. Do you have a suggestion around phrasing here that would make the > point clear? You probably can't take the following as is, but: If a UA has reason not to trust a "local" resource, it should be obligated to treat it as trusted. Computers can be shared, either between users, or even applications of differing levels of trust. Files created / hosted by a different user / application can easily fall into these categories. If the host enables the UA to distinguish between user owned / managed content, OS host content (e.g. Traditional low numbers ports), and content owned by other users, the UA should consider this. > I also don't understand the "taint" bits portion of your comment. > Could you explain? com.apple.quarantine http://lorentzen.blogspot.ca/2012/05/comapplequarantine.html http://weblogs.asp.net/dixin/understanding-the-internet-file-blocking-and-unblocking http://msdn.microsoft.com/en-us/library/dn392609.aspx >> > Given a request request, a user agent determines whether the Request >> request should proceed or not via the following algorithm: >> >> Why only capitalize the second Request request? > The first "Request" refers to the "Request" interface defined in Fetch (and > is linked as such). The second is marked up as a variable, named "request". > This seems clear to me, but perhaps adding the word "named" in between the > two "request"s would be helpful? I should have been clearer, there are four "request"s there > Given a (1)request (2)request, a user agent determines whether the (3)Request (4)request I asked why 3 of 3-4 was capitalized, but not 1 of 1-2. But, yes, something should be done :)
Received on Tuesday, 11 November 2014 09:21:22 UTC