W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2017

Re: Presentation API in non secure contexts

From: mark a. foltz <mfoltz@google.com>
Date: Wed, 25 Jan 2017 10:13:49 -0800
Message-ID: <CALgg+HE_qJsV-J3c=3-x7Z1MjYHPu9URgEa+rbK3ceu+DWJYeA@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Francois Daoust <fd@w3.org>, WebAppSec WG <public-webappsec@w3.org>, public-web-security@w3.org, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
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

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