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

On Fri, Aug 22, 2014 at 12:44 PM, John Kemp <john@jkemp.net> wrote:

> On 08/22/2014 03:09 PM, Jeffrey Yasskin wrote:
>
> [...]
>
>
>  "be careful" is useless unless we can describe what care is appropriate.
>>
>
> My wife tells me to "be careful" when I go running in the woods. What I
> think she means is:
>
> * Make enough noise to avoid running into a bear or a snake
> * Don't get lost
> * Get back before dark
> * Wear enough clothes
>
> (and see * below)
>
> ... and maybe a few other things. Her advice is vague and open to my
> interpretation, but still useful. But that's mostly because I have lots of
> education of what happens when I ignore her advice (never ignore your
> spouse's advice ;)
>
>
>  And we have to describe it concisely and clearly so that users can read
>> and understand it while it's interrupting the task they want to do.
>>
>
> Getting back to the original issue (opening particular features of the web
> platform to "secure origins") I would say that yes, providing adequate
> education about what is implied by a server requesting access to perform
> operations (of any kind) is an excellent idea. What can a browser tell you
> about an essentially unknown web server?
>
>
>
>> Do you buy things over the internet? Would you send your credit card
>> data over a non-TLS connection just because TLS doesn't give perfect
>> security?
>>
>
> I would separate this question into a couple of other questions:
>
> * Do I give my credit card information to untrusted people in untrusted
> places?
>
> The answer is yes, and I would guess you have heard of credit card
> skimmers?
>
> * Would I like my credit card information to remain confidential?
>
> The answer is again yes. And I do my part to ensure it does. TLS is not
> the only thing required of me to do that.
>
> As I've said previously, I think the encryption available in TLS is
> excellent for transmitting confidential data.
>
> I just don't see that an encrypted transport layer is the same thing as a
> secure way of authenticating a server to perform an operation on the web
> platform.
>

It's definitely not the same thing, but it seems to be a prerequisite.
Specifically, you need an encrypted transport layer *and* some measure of
trust in the entity it's saying you're communicating with *and* some
measure of trust that the CA hasn't been compromised. If you don't have an
encrypted transport layer, the browser can tell you haven't authenticated
the server to perform a confidential operation, so the browser should block
that operation. That's the core of the secure origins proposal, so I'm
having trouble seeing why you disagree with it.

*After* that, we get into the ideas around choosers that, e.g.
https://webbluetoothcg.github.io/web-bluetooth/#widl-BluetoothDiscovery-requestDevice-Promise-BluetoothDevice--sequence-BluetoothScanFilter--filters
takes advantage of, which help find out what data the user trusts the site
with.

Certificate transparency seems to be about the third aspect of the problem.


>
> Regards,
>
> - johnk
>
> * what she actually means is "don't make me have to come and get you!"
>
>
>
>>     -- see the "ceremony" idea you mention above), and also to state
>>     that TLS only protects data while in transit between a user's
>>     network endpoint and the network endpoint with whom they are
>>     communicating. It is not a solution (without additional context at
>>     least) either for authentication of the parties, or for ensuring
>>     that a user's data remain confidential once transmitted to any other
>>     party.
>>
>>     Regards,
>>
>>     - johnk
>>
>
>
>
>
>>
>>
>>
>>