Re: SRI: <a> vs integrity

Just to be clear, I'm not arguing against SRI for downloads, just for
navigable uses of anchors.
On Jul 28, 2014 5:13 PM, "Chris Palmer" <palmer@google.com> wrote:

> On Mon, Jul 28, 2014 at 4:54 PM, Eduardo Robles Elvira
> <edulix@agoravoting.com> wrote:
>
> >> We just had no interest whatsoever at the time of our rechartering in
> implementing a feature that would have to ask the user something like: "The
> content at the other end of this link is not the same at the content the
> creator of this link specified.  It may have changed and still be
> legitimate content intended by the resource owner, or may be content
> intended by the resource owner but considered illegitimate by the author of
> this link, or the page may have been modified in a manner unauthorized by
> the resource owner, or the author of the link may have incorrectly
> specified what they expected.  We cannot give you *any information
> whatsoever* as to the nature or extent of the changes.  Continue?"
> >
> > Security vs. usability, round 100+1 :-). I understand that what to
> > some (like me or Julian) makes a lot sense now, might not make sense
> > to the people making in the standard at the time. That's why I like
> > that we have an open mailing list to comment these things. The warning
> > doesn't need to be worded as you worded. It sure can, in a hidden
> > optional "more details" section. By default it could just say "This
> > content is labeled as insecure by the web site, do you really want to
> > continue?" or something similar. I'd let usability people figure the
> > wording.
>
> This is not really a case of usability vs. security. (That dichotomy
> is usually false, and this case is a perfect example.)
>
> As Brad's sarcastic-but-realistic dialog box text illustrates, this is
> a case of bad usability + no real security guarantee vs. doing no
> (new) harm. Doing no harm is definitely preferable to creating a bad
> user experience and yet also not providing any real
> (provable/enforceable at run-time) security — the worst of both
> worlds.
>
> No amount of wordsmithing the UI string will fix it.
>
> The run-time provable, run-time enforceable way is for sites to serve
> download pages and the downloaded files themselves via HTTPS with
> valid certificates, and then to make use of (for code downloads)
> whatever code-signing mechanism the destination platform provides
> (every platform provides some kind of code authentication now).
>