[Bug 25972] Please require a secure origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

--- Comment #9 from Boris Zbarsky <bzbarsky@mit.edu> ---
> - are *not* similar, nor the same objection.

I think part of your problem is that you're confusing "secure origin" with
"secure transport".

For example, an <iframe srcdoc="whatever" sandbox="allow-scripts"> in an https
document will not be a "secure origin" (because it's a nonce origin), but is a
"secure transport" (because the data came from the https page).  Why should
this API be disabled in that situation?

The point being that all the definitions of "secure origin" I've seen people
suggesting so far are so restrictive that they _do_ in fact cut out cases that
can be secure.

> Having signature verification go over HTTP

Again, you're confusing origins and transports.  The two are not all that
related on the web as it is nowadays, except in the simplest cases.

> the actual security goals of a "signature verification" system
> are immediately defeated by the mutability of the environment when it's an
> insecure environment.

If I have an https page that loads some API in a sandboxed iframe over https
(sandboxed because I don't actually trust the API provider all that much) and
then I want to prove to the API provider that I am actually me and postMessage
stuff to it signed with my key, why should it not be able to perform
client-side signature verification?  Which part of what I described is an
"insecure environment" exactly?

> we should stop the proliferation of insecure-by-default

The rules you plan to adopt are _way_ more restrictive than that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 5 June 2014 00:53:17 UTC