Re: "Requirements for Powerful Features" strawman.

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.


> 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.

* Attacker can inject an `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.)