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

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 9 Dec 2014 12:51:34 -0800
Message-ID: <CABkgnnWjfAVxkmuX1WVnhvdO=WEaL4XW9-5ggFKs5XBT6czuLw@mail.gmail.com>
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

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