On Mon, Jan 23, 2017 at 1:27 PM, Richard Barnes <rbarnes@mozilla.com> wrote: > I'm not trying to apply a "powerful feature" standard. You'll notice that > the spec that used to be called "powerful features" is now called "secure > contexts" because it can be applied to *all* features. > New features continue to be developed and shipped on insecure contexts (e.g., IntersectionObserver). What criteria are now used to determine which are allowed? > Our starting assumption here should be that any new feature should be > restricted to secure contexts. I'm looking for an argument that that > restriction would be harmful, pointless, etc. before we open it up to > non-secure contexts. > That is a different position than the one that was offered by WebAppSec during the previous review. Does WebAppSec have a position paper or spec explaining the reasoning for this change I could take back to the group? m. > > On Mon, Jan 23, 2017 at 4:17 PM, mark a. foltz <mfoltz@google.com> wrote: > >> On Mon, Jan 23, 2017 at 9:06 AM, Richard Barnes <rbarnes@mozilla.com> >> wrote: >> >>> What is the rationale for why this API needs to be available to >>> non-secure contexts? >>> >> >> At the time the group considered this, it was judged to not be a powerful >> feature. >> We have asked for an updated rubric for evaluating what is a powerful >> feature, and have not yet received a reply. >> >> m. >> > >
Received on Wednesday, 25 January 2017 18:14:41 UTC