Re: "Requirements for Powerful Features" strawman.

On Fri, Nov 21, 2014 at 8:38 AM, Mike West <mkwst@google.com> wrote:

> On Fri, Nov 21, 2014 at 5:28 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> One further comment on item (4) in [1]. Is exposing a temporary
>> identifier really a sufficient condition for "powerful" ?
>>
>
> This depends a bit on the definition of "temporary". I'll attempt to
> clarify in the doc.
>
>
>> Wouldn't that catch IndexedDB, since a site can clearly install a
>> temporary identifier there ?
>>
>
> It would. Also WebSQL, DOM Storage, Cookies, ETags, etc. Identifiers
> should be delivered via secure channels.
>
> Mark (Nottingham) noted that we need to distinguish between "new" features
> and features whose historical context created decisions that are suboptimal
> today. I'll certainly be adding text to the doc to make a path forward for
> those types of APIs more clear.
>

​There's a distinction between entirely new functionality and new
replacements for to-be-deprecated, but widely used, functionality.
Completely new functionality has no existing users (sites) so you have a
true "green field" situation (e.g. Service Workers). If you are trying to
replace some existing widely-used legacy functionality, the situation is
different, since too many barriers in the path of the new thing may just
lead people to stick with the legacy solution longer.


>
>
>> We're working on normative definitions in EME​, but I think there is only
>> a concern if an identifier is not easily clearable, is shared across
>> origins or actually encodes some information rather than being an opaque
>> temporary identifier.
>>
>
> Given that insecure origins are implicitly shared across origins in the
> presence of an active network attacker*, I'd suggest that each of the above
> items meets the definition you're advancing here.
>

​We're discussing in the EME context an additional consideration, which is
that identifiers should be ​encrypted at the EME layer. What properties
that gives you depends a lot on exactly how its done, obviously, so I'll
not make any claims here except to say that the situation is potentially
different from, say, cookies.


>
> * Attacker can inject an `http://example.com/` <http://example.com/>
> iframe whose contents they control, and either postMessage or XHR their way
> to any and all data that origin contains, even if you never visit the
> origin.
>
>
>> I think you should at least say "Some implementations of" EME, since
>> several UAs have worked / are working very hard to eliminate problematic
>> identifiers here.
>>
>
> That's a fair point, thanks!
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>