- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 9 Dec 2014 12:51:34 -0800
- To: Mike West <mkwst@google.com>
- Cc: Mark Watson <watsonm@netflix.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "public-geolocation@w3.org" <public-geolocation@w3.org>, "Nottingham, Mark" <mnotting@akamai.com>
On 9 December 2014 at 12:33, Mike West <mkwst@google.com> wrote: > 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's perhaps a little contrived, but there are two entry points to getUserMedia, one of which was only recently added. The newer one returns a Promise, whereas the old one uses callbacks. It's a powerful feature, no question. But saying that the new one is automatically subject to new rules around secure origins could cause some interesting issues. > 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. Yes, this cuts both ways. If the statement is simply: "you are (strongly) encouraged to examine APIs (old and new) based on this statement and debate whether actions are necessary", then this is perfectly fine. I don't think that we can force the reconstitution of old groups for the purposes of making this one change, but encouragement is always OK.
Received on Tuesday, 9 December 2014 20:52:02 UTC