- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 2 Feb 2015 12:32:39 -0800
- To: POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>
- Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Harry Halpin <hhalpin@w3.org>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>, "public-web-security@w3.org" <public-web-security@w3.org>, Brad Hill <hillbrad@fb.com>
- Message-ID: <CACvaWvZqWk4w0mHc0pztj9oDULji6gV3XDYcR77LVc+Ru7V7eA@mail.gmail.com>
On Mon, Feb 2, 2015 at 5:28 AM, POTONNIEE Olivier < Olivier.Potonniee@gemalto.com> wrote: > Ryan, > > > > What I’m saying is: WebRTC and geolocation API give access to personal > information (your voice, or your position). Any origin may request access > to these services, and the access control to these services is not based on > **same-origin policy** but on permissions. Your same voice, and > potentially your same position, may be shared with multiple origins. Both > can be used to track you. > > Of course the access control mechanism to a service has to be adapted to > the level of privacy/risk associated to the disclosed information. And I’m > not saying the existing one is not adapted to WebRTC and geolocation API. > > What we are willing to define in W3C is a hardware backed-up crypto > service protected with an access control matching the sensitive nature of > secure hardware tokens. > > -- > > Olivier > > > Oliver, The comparison here is about as apples and oranges as you can get. First, let's be clear: The access control to these services IS based on the same origin policy. It is ALSO based on permissions. It is not "either/or", but "and", and that is a critical distinction to note and realize. Granting permission to Origin A access to any of your capabilities does not and should not grant access to Origin B. That's (part of) what we mean by the same origin policy - only the SAME ORIGIN that was originally granted access to something continues to have access to it. Second, I think it's important to realize how flawed proposals are that rely on sharing access to the same device across multiple origins when that device has a level of persistence. That fundamentally violates many of the key security guarantees of the web, in that now Origin A and Origin B can independently influence eachother, collaborate, or otherwise be granted transient and ambient permissions. For example, when I grant Origin A access to my microphone, Origin B has no ability to influence that access whatsoever. It does not receive access, it can not influence how my voice is presented, nor can it simulate my voice to Origin A. Similarly, when I grant geolocation to Origin A, the capabilities granted to it have no ability to influence how Origin B behaves. Now, consider what's being proposed here by the hardware vendors on the list trying to ensure an insecure technology stays relevant in a web world where security is no longer optional: If I grant Origin A access to key material, it can impersonate messages from Origin B (if Origin B also has access). Similarly, if Origin A creates a key, Origin B can discover this key. Both of these fundamentally violate the origin separation that is crucial to the web. This is where the relevance to FIDO is all the more important - even though a single hardware token may be involved: - Origin A and Origin B have NO shared key store - Messages from Origin A are identified as such explicitly as part of the message construction, preventing it from being compared with Origin B - Persistent identifiers are (effectively) opaque, and thus user agents can provide a number of privacy enhancing means on this I hope you realize how geolocation/microphone permission models are thus apples & oranges to what has been proposed by Gemalto and Typhone, and similarly how FIDO and the legacy APDU-based smartcards are, similarly, night and day. ANY solution that attempts to expose these capabilities MUST have, as a first class citizen and intrinsic to the design, a model that recognizes origins as the basis for all security decisions. Keys MUST NOT be shared between origins AND messages MUST be attributable to origins are two basic requirements that are needed for any serious consideration.
Received on Monday, 2 February 2015 20:41:15 UTC