W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

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

From: Mike West <mkwst@google.com>
Date: Tue, 9 Dec 2014 21:12:38 +0100
Message-ID: <CAKXHy=eq-g0f6FT7d-N=PvV-qU49g-xFjY274z0OzT6PnrJi_g@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "public-geolocation@w3.org" <public-geolocation@w3.org>, "Nottingham, Mark" <mnotting@akamai.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC