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. > 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.)
Received on Tuesday, 9 December 2014 20:34:41 UTC