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

Re: [Integrity] Comments/Questions on Subresource Integrity spec

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Mon, 21 Apr 2014 19:47:36 -0700
Message-ID: <CAPfop_1TC9c80UJ-6YRW14jzb=c5uzs5z5tESJAMumASex2BwQ@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi

Thanks for all the feedback! Comments inline:

> Here it says that fonts are covered, but I don't see anything about fonts in
> the spec.

I have filed https://github.com/w3c/webappsec/issues/17
I imagine one of the editors will get around to it in a future round of edits.

> We could allow mixed active content loads that pass an integrity check
> (instead of blocking them) and use the UI for mixed display content in these
> cases (instead of showing the lock).

yeah. That was one of the possibilities. There are arguments against
it too, but the spec is not trying to prescribe anything here.
Personally, I think this is best left to the browsers and how they
feel their users are best served.

> 2.1 - Key Concepts and Terminology
> "The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of
> cryptographic hash functions defined..."
> Looks like SHA-384 isn't used anywhere in the spec.

I believe RFC6920 allows for using SHA-384. The spec only mandates
SHA-256 and SHA-512. It might make sense to remove mention of SHA-384,
but I am not sure if it is doing much damage right now.


> Was there a discussion that these restrictions came out of?  I understand
> the need for them but am worried if about overly constraining the feature.
> Are there common instances where a resource may not be publicly cachable but
> wouldn't have any private data or leak information?

There was a bunch of discussion a while back. Unfortunately, it is
spread over two threads because the initial thread had too much
happening. See http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0005.html
and http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0018.html
The examples Michal came up with were pretty scary, imo.


>
> 3.5 Verification of HTML document subresources
> "...a new integrity attribute is added to the list of content attributes for
> the a, audio, embed, iframe, link, object, script, source, track, and video
> elements."
> images are missing from this list.

thanks! fixed.


> 3.5.2 - Noncanonical source

[skipping these parts since Brad seems to have already answered these]


> 3.5.4 - Handling integrity violations
> Why have separate block and fallback modes?  If the site didn't want to
> fallback, they wouldn't have included a noncanonical source.

I believe this is for cases where they don't have the noncanonical
source and the integrity is applied to the main source.

> 3.5.5.1 - The a element
> "If subject has an integrity attribute whose value is not the empty string,
> then:..."
> What does subject refer to here?

I think this is defined in the HTML5 spec
http://www.w3.org/TR/html5/links.html#following-hyperlinks


> 'If response’s integrity state is corrupt and the document’s integrity
> policy is report, the user agent MUST report a violation, and can continue
> with the download.'

fixed!

thanks again!

regards
Dev
Received on Tuesday, 22 April 2014 02:48:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 April 2014 02:48:26 UTC