Re: [POWER] New vs Legacy functionality (Re: "Requirements for Powerful Features" strawman.)

On Tue, Dec 9, 2014 at 12:33 PM, Mike West <mkwst@google.com> wrote:

> On Tue, Dec 9, 2014 at 9:20 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> If you want to encourage people to move from feature A to feature A',
>> then coupling that move with a secure origins limitation could create
>> additional disincentives to move.
>>
>
> True. However, getting _more_ people to use an insecure API _faster_ seems
> like an anti-pattern that we should avoid.
>
> I guess I'd suggest that the feature needs to be pretty amazingly amazing
> if it is "powerful" in the sense the spec outlines, but we allow concerns
> about adoption rate to override security and privacy concerns. Personally,
> I haven't seen such a feature.
>
> Are there examples that folks have in mind of replacement features that
> really should prioritize usage in this way? It might be easier to have a
> concrete discussion than an abstract one.
>

​Sure. I see EME as a replacement for (some aspects of) <object>. I see
<object> as having much more serious security and privacy issues than EME.
Imposing a secure origin requirement on EME may have the effect of
prolonging the life of <object>. This point should be considered in the
analysis. ​But this is not reflected in any of the cases considered in the
document: EME is clearly not a "legacy" feature but if it was considered in
the "completely new" category, the potentially user-negative effect of
prolonging the life of <object> would not be considered.

[Note also that there is active work to strengthen the security and privacy
properties of EME, for example recent promotion of much of the security and
privacy sections to normative requirements, including the requirement that
identifiers be easily clearable. Whilst those improvements stand on their
own merits, they also widen the gap with <object> and, IMO, reduce the
motivation for EME to be restricted to secure origins].

​...Mark​



>
>
>> It might simply make sense to say that any choice about secure origins
>> should be orthogonal to the continuing evolution of a feature.
>>
>
> I think that's a reasonable way to put it.
>
> That said, the spec only distinguishes between "new" and "legacy" in order
> to make it clear that we intend to put existing features under the lens,
> and to make it clear that we're advocating a sane deprecation process
> rather than saying "It's insecure, turn it off tomorrow." I do not intend
> that distinction to be perceived as anything like a persistent
> grandfathering-in of features that we'd hopefully design differently today.
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> 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.)
>