> 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 <m...@mozilla.com> 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 <ann...@annevk.nl> > 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
