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

Re: [MIX] RfC: WebAppSec's Last Call Working Draft of Mixed Content; deadline December 11

From: timeless <timeless@gmail.com>
Date: Tue, 11 Nov 2014 04:20:55 -0500
Message-ID: <CACsW8eESft_Ls38KWRp8Z7sH40v=ecoJiqFohLEE6j=CigaRCw@mail.gmail.com>
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.htmlhttp://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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC