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

Thank you very much! This is great feedback.

Unfortunately, it looks like you reviewed a slightly out-of-date version of
the spec; Brad's announcement was slightly premature, as the LCWD isn't
going to be officially published until Thursday. I'd suggest evaluating the
ED, as it's always going to be up to date:
https://w3c.github.io/webappsec/specs/mixedcontent/

I've accepted most of your feedback right off, but one or two things
deserve a note; I'll do that inline.


On Tue, Nov 11, 2014 at 9:02 AM, timeless <timeless@gmail.com> wrote:

> > deprecated TLS-protection
> > A resource’s TLS-protection is said to be deprecated if it is not weakly
> TLS-protected, but the user agent chooses to refuse it anyway.
>
> "Not" here is ambiguous. I can read this as "A resource’s
> TLS-protection is said to be deprecated if it is strongly
> TLS-protected"
>

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?


> Please move [CAB] before the period to match ‎"[RFC1918].‎" above.
>

Done throughout.


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

I also don't understand the "taint" bits portion of your comment. Could you
explain?


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


> > A conformant server must implement all the requirements listed in this
> specification that are applicable to servers.
>
> I can't find any such requirements.
>

Ah, boilerplate.

Yes. I'll drop this from the final draft.

Thanks again, this is great feedback.

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