Re: SRI: <a> vs integrity

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

Received on Tuesday, 29 July 2014 00:14:08 UTC