Re: Requiring secure contexts for new features

2018-01-17 Thread Anne van Kesteren 
On Wed, Jan 17, 2018 at 12:02 AM, Martin Thomson  wrote:
> Either of these criteria are sufficient, right?  However, I expect
> that we'll want to hold the line in some cases where other browsers
> ship anyway.  How do we plan to resolve that?  One potential
> resolution to that sort of problem is to ship in secure contexts
> anyway and ask other browsers to do the same.
>
> My expectation is that we'll discuss these and exercise judgment.  But
> I thought that I'd raise this point here.  I want to avoid creating an
> expectation here that we're happy with lowest common denominator when
> it comes to these issues.

I was hoping that the section "Exceptions to requiring secure
contexts" makes it quite clear that it is indeed an appeals process.
We already have a process for shipping new features ("intent to
implement/ship") and now you need to present justification if you want
to ship a feature available on insecure contexts. It is likely that an
exception is granted for either of the reasons given, but it's not a
guarantee. The dev-platform community can still object and if that is
sustained by the Distinguished Engineers I would expect us to not ship
it (or ship it restricted to secure contexts).

I have clarified https://wiki.mozilla.org/ExposureGuidelines that
secure contexts needs to be part of the "intent to implement" emails
and also linked the secure contexts post from the suggested
implementation process.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

2018-01-16 Thread Jonathan Kingston 
> One potential resolution to that sort of problem is to ship in secure
contexts anyway and ask other browsers to do the same.

It would be really great from a HTTPS adoption standpoint if we can hold
back as many features from being shipped to insecure contexts.

Perhaps Firefox could ship new features to HTTPS and provide prefs to
enable to insecure, which would allow flexibility for webcompat if we
needed to change the stance in stable.

Could we have a process to handle when to withhold these incompatibilities
from insecure contexts?

On Tue, Jan 16, 2018 at 11:02 PM, Martin Thomson  wrote:

> Great news.  Thanks to all those involved for getting to this point.
>
> Anne, your posting suggests an exception is likely if:
>
> * other browsers already ship the feature insecurely
> * it can be demonstrated that requiring secure contexts results in
> undue implementation complexity.
>
> Either of these criteria are sufficient, right?  However, I expect
> that we'll want to hold the line in some cases where other browsers
> ship anyway.  How do we plan to resolve that?  One potential
> resolution to that sort of problem is to ship in secure contexts
> anyway and ask other browsers to do the same.
>
> My expectation is that we'll discuss these and exercise judgment.  But
> I thought that I'd raise this point here.  I want to avoid creating an
> expectation here that we're happy with lowest common denominator when
> it comes to these issues.
>
> On Wed, Jan 17, 2018 at 5:11 AM, Anne van Kesteren 
> wrote:
> > Yesterday Mozilla announced Firefox will be restricting new features
> > to secure contexts (i.e., HTTPS):
> >
> >   https://blog.mozilla.org/security/2018/01/15/secure-
> contexts-everywhere/
> >
> > I'm glad to report that thus far this has been very well received.
> >
> > I'm posting this here per suggestion from Ben Kelly and because:
> >
> > * Not all module owners and peers might have seen the blog post and
> > this might impact them if their module currently, or in the future,
> > exposes features to web content.
> > * Modules might want to look into ways of enforcing this
> > programmatically, to ease ongoing maintenance and guide everyone to do
> > the right thing without having to ask/review/etc. E.g.,
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> > for enforcement around our bindings.
> > * Mozillians might have questions not addressed in the post and this
> > seems like a good place to centralize those and address them.
> >
> > Insofar as documenting this policy elsewhere goes I've updated
> > https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
> > update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
> > manner. (The latter will probably also need to be generalized as
> > currently it suggests it's for APIs only.)
> >
> > Hope that helps,
> >
> >
> > --
> > https://annevankesteren.nl/
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

2018-01-16 Thread Martin Thomson 
Great news.  Thanks to all those involved for getting to this point.

Anne, your posting suggests an exception is likely if:

* other browsers already ship the feature insecurely
* it can be demonstrated that requiring secure contexts results in
undue implementation complexity.

Either of these criteria are sufficient, right?  However, I expect
that we'll want to hold the line in some cases where other browsers
ship anyway.  How do we plan to resolve that?  One potential
resolution to that sort of problem is to ship in secure contexts
anyway and ask other browsers to do the same.

My expectation is that we'll discuss these and exercise judgment.  But
I thought that I'd raise this point here.  I want to avoid creating an
expectation here that we're happy with lowest common denominator when
it comes to these issues.

On Wed, Jan 17, 2018 at 5:11 AM, Anne van Kesteren  wrote:
> Yesterday Mozilla announced Firefox will be restricting new features
> to secure contexts (i.e., HTTPS):
>
>   https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
>
> I'm glad to report that thus far this has been very well received.
>
> I'm posting this here per suggestion from Ben Kelly and because:
>
> * Not all module owners and peers might have seen the blog post and
> this might impact them if their module currently, or in the future,
> exposes features to web content.
> * Modules might want to look into ways of enforcing this
> programmatically, to ease ongoing maintenance and guide everyone to do
> the right thing without having to ask/review/etc. E.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> for enforcement around our bindings.
> * Mozillians might have questions not addressed in the post and this
> seems like a good place to centralize those and address them.
>
> Insofar as documenting this policy elsewhere goes I've updated
> https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
> update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
> manner. (The latter will probably also need to be generalized as
> currently it suggests it's for APIs only.)
>
> Hope that helps,
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

2018-01-16 Thread Ben Kelly 
On Tue, Jan 16, 2018 at 1:11 PM, Anne van Kesteren  wrote:

> * Modules might want to look into ways of enforcing this
> programmatically, to ease ongoing maintenance and guide everyone to do
> the right thing without having to ask/review/etc. E.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> for enforcement around our bindings.
>

FYI, Boris landed a change that requires the author to mark the test for an
interface as "insecureContext: true" if it should be permitted outside of a
secure context.  Obviously this should only be permitted going forward if
it meets one of our exception criteria.

Thanks.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Requiring secure contexts for new features

2018-01-16 Thread Anne van Kesteren 
Yesterday Mozilla announced Firefox will be restricting new features
to secure contexts (i.e., HTTPS):

  https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

I'm glad to report that thus far this has been very well received.

I'm posting this here per suggestion from Ben Kelly and because:

* Not all module owners and peers might have seen the blog post and
this might impact them if their module currently, or in the future,
exposes features to web content.
* Modules might want to look into ways of enforcing this
programmatically, to ease ongoing maintenance and guide everyone to do
the right thing without having to ask/review/etc. E.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
for enforcement around our bindings.
* Mozillians might have questions not addressed in the post and this
seems like a good place to centralize those and address them.

Insofar as documenting this policy elsewhere goes I've updated
https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
manner. (The latter will probably also need to be generalized as
currently it suggests it's for APIs only.)

Hope that helps,


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform