On Tue, Dec 9, 2014 at 8:59 PM, Mark Watson <watsonm@netflix.com> wrote: > > My initial feeling is that there's no relevant difference between a new >> feature introduced because it's independently awesome, and a new feature >> which is introduced in order to replace an old feature. >> > > The relevant difference is that *if it's an objective to deprecate or > restrict the legacy feature*, then barriers to the adoption of the new > feature also slow down deprecation / restriction of the old one. No such > consideration exists for a brand new feature. > I don't believe the intent of a feature has much of anything to do with the attack surface it exposes. Deprecating an insecure feature is a good thing! It is substantially less good if deprecating it doesn't improve the security situation. If the new feature doesn't solve the security and privacy issues in the existing feature, then I'd suggest that adoption _should_ be slow. The slower, the better, in fact. If, on the other hand, there is no desire to deprecate or restrict the old > feature, then I agree, there is no relevant difference. > Great. That's somewhere we certainly agree! -mike -- 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.)
Received on Tuesday, 9 December 2014 20:13:27 UTC