Re: [Bulk] Proposal: Prefer secure origins for powerful new web platform features

[re-adding all the lists]

On Tue, Jul 15, 2014 at 10:06 AM, 'Kevin Chadwick' via Security-dev
<security-dev@chromium.org> wrote:

> What immediately struck me is that this definition seems misleading.
>
>> Secure origins" are origins that match at least one of the following
>> (scheme, host, port) patterns:
>>
>>     * (https, *, *)
>>     * (wss, *, *)
>
> The below are very likely secure origins and if not the user should
> know? but the above are simply secure transports and the domain needs to
> be checked carefully by the user?

As usual, using the word "secure" is an oversimplification. I was
trying to use it advisedly; but yeah, there is tons of ambiguity.

My goal is for the browser/UA to be able to determine, unassisted and
at run-time, whether or not the code it is running could possibly have
been delivered from an authenticated origin and not tampered with in
transit. Degrees of security higher than this bare minimum are
obviously wonderful, but they do depend on us first nailing down this
bare minimum. They tend to also depend on things outside the browser,
such as user choice or configuration.

There is still the issue of mixed scripting content: Should we give
(https, example.com, 443) access to (say) ServiceWorkers when it loads
script from (http, goats.net, 80)? Surely not; and that is part of the
work Mike West is doing in defining the behavior of mixed content.

> There is certainly already way to much [bs|js] trying to get your
> private data over ssl and without asking.

I'm not sure what you mean. The powerful APIs tend to involve some
kind of user interaction/selection/permission as well, such as
getUserMedia asking which camera to use, the settable and un-settable
permissions like the Page Actions in the Chrome Omnibox and the Page
Info Bubble (that pops up when you click on the Lock icon or on the
Favicon).

If you're worried that (https, example.com, 443) is letting (https,
goats.org, 443) have access to e.g. your camera because example.com
includes script from goats.org, yeah that is tricky. Again, whether or
not that is acceptable to the user is not something the browser can
determine by itself.

>> This list may be incomplete, and may need to be changed. Please discuss!
>
> http over VPN's/IPSEC spring to mind but I don't know what you could do
> about that except ask the user

Right; a VPN is transparent to the browser — the browser could not
make a determination of origin authentication or script integrity
unassisted at run-time. Additionally, VPNs are not end-to-end secure:
the VPN provider can break the "security" "guarantee" in a way that is
not possible for an intermediary when HTTPS is working properly. (Some
VPN designs provide even less security, e.g. those in which the
VPN-using hosts all use the same key material. In that situation, any
user can break the security of the VPN, not just the VPN provider.)

Received on Tuesday, 15 July 2014 17:54:56 UTC