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

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

From: Mark Watson <watsonm@netflix.com>
Date: Tue, 9 Dec 2014 11:59:50 -0800
Message-ID: <CAEnTvdCat_=xyo7mbVMUCf9RB267e4OLw+jxv2h+N0PYptwq_w@mail.gmail.com>
To: Mike West <mkwst@google.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 11:45 AM, Mike West <mkwst@google.com> wrote:

> On Tue, Dec 9, 2014 at 5:54 PM, Mark Watson <watsonm@netflix.com> wrote:
>> ​I think there should be explicit consideration for the case where a new
>> feature is widely seen as a replacement for an old. perhaps different,
>> feature. Especially where there is a desire to remove the old feature
>> altogether. The existing users of such a legacy feature should be factored
>> into this discussion in just the same way as the existing users of features
>> which match the geo-location example.
> What would you like the spec to say about these kinds of features?

I think the considerations should be similar to those for pre-existing
features (if the objective is to deprecate or restrict the old feature).

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

If, on the other hand, there is no desire to deprecate or restrict the old
feature, then I agree, there is no relevant difference.


>> I'm still not sure the reference to EME is Section 3, item 4, is correct.
>> If the intention in that bullet is to capture anything that could expose
>> temporary identifiers then it would be clearer if you included Web Storage
>> / IndexedDB as well. If the intention is specifically to capture things
>> which expose identifiers that cannot easily be cleared by the user, then
>> EME is not an example since it is now *normatively* required that
>> identifiers exposed by EME *can* be easily cleared by the user.
> I think the terms I chose there are misleading: to be clear, I see three
> categories of identifiers that should be discussed:
> * EME (and cookies, and IDB, and etc) expose an identification mechanism
> that sticks around until the user takes explicit action to remove the
> identifier.
> * Session storage clears itself within some reasonable period, and without
> explicit user action (in theory).
> * Device-level identifiers are not clearable.
> I'll attempt to clarify the intent.
> --
> 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:00:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:10 UTC