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

On Tue, Dec 9, 2014 at 9:20 PM, Martin Thomson <>

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

> 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 West <>, @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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Tuesday, 9 December 2014 20:34:41 UTC