- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 9 Dec 2014 11:59:50 -0800
- 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>
- Message-ID: <CAEnTvdCat_=xyo7mbVMUCf9RB267e4OLw+jxv2h+N0PYptwq_w@mail.gmail.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. ...Mark > > >> 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:19 UTC