Re: Secure contexts required for new web platform features
On 7/1/15 2:49 AM, Anne van Kesteren wrote: Platform. There was no strong opposition to the Intent to deprecate: Insecure HTTP thread and in Whistler everyone attending the deprecating non-secure HTTP session agreed. Do you think this needs to be approached differently? Yes. Because taken at face value, the given proposal of conditioning every single new piece of DOM, CSS, JS, etc functionality on the secure context thing (assuming we can even agree on how to define it) would lead to code that's a nightmare to maintain, slower than it should be, and makes web developers cry bloody tears. Might I ask how many of the relevant module owners were at the Whistler session you mention? what the definition of new web platform features is (e.g. does the webperf translateTime thing count? Yes, anything for which Platform creates Intent to Implement/Ship threads. Ignoring for the moment that _that_ decision is somewhat arbitrary Do you really think that shipping CSS Grid only in secure contexts is a good idea? The idea is that you indicate in the Intent to Implement/Ship thread whether you want an exception to the secure context restriction. We add lots of features without such Intent threads all the time. Just FYI. There's a definition Google and us use to implement service workers. Link, please? Module owners, based on dev.platform input to the Intent to Implement/Ship threads. No criteria were established. Hopefully something that can be learned over time. I suspect that different people involved in this conversation have vastly different ideas of what constitutes a feature and how much pain it is to make things conditional. Resolving those differences is key to even having this conversation. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
I'll leave some of your points/questions for Richard. On Wed, Jul 1, 2015 at 10:30 AM, Boris Zbarsky bzbar...@mit.edu wrote: We add lots of features without such Intent threads all the time. Just FYI. I hope that we can get somewhat better on this. It is rather useful to have a somewhat large set of people have insight as to what goes into Platform. Link, please? https://w3c.github.io/webappsec/specs/powerfulfeatures/ is what we use for service workers. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
On 7/1/15 4:43 AM, Anne van Kesteren wrote: I hope that we can get somewhat better on this. It is rather useful to have a somewhat large set of people have insight as to what goes into Platform. Sure. I'm just saying that I suspect people underestimate the number of features we add, the granularity we add them at, and the number of is this a secure context? checks we'd need to sprinkle like pixie dust to implement the proposal as written. Put another way, I think the presumption that everything should be secure-context-only unless proven otherwise is not necessarily the right one for all modules and I think that it might be worth talking to some module owners about whether their particular module should have that presumption, or the opposite one of available-everywhere unless requested otherwise. https://w3c.github.io/webappsec/specs/powerfulfeatures/ is what we use for service workers. I assume you specifically mean https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure ? Ignoring for the moment the issues listed right there in the algorithm, I just did a quick read resulting in the following mails: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0010.html https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0011.html https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0012.html I didn't do a careful audit or anything; just the things that jumped out at me immediately on reading the algorithm and trying to understand what it's saying. For our own internal usage, of course, we'd need to decide what https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy step 5 should mean in our particular case. How we define that is important to being able to evaluate what our policy should be here. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
On Tuesday 2015-06-30 17:00 -0400, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Exceptions can be granted, but will need to be justified as part of the Intent to Implement [3] and Intent to Ship process. I think this needs to define what the granularity of a new feature is. Does it count new CSS properties that are closely related to existing ones? New values for existing CSS properties? Or by features are you talking only about doing things that the Web couldn't do before, rather than new built-in capabilities than make existing things easier or faster to do? Also, from a Web compatibility perspective, I don't think we can afford to do this for features that enough other browsers are shipping for all contexts. We implement some (though not too many) features because we're the last major browser to implement them; in those cases we're generally already dealing with a bunch of content that doesn't work in Firefox, especially on mobile, because of the lack of those features. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
On Wed, Jul 1, 2015 at 11:35 AM, L. David Baron dba...@mozilla.com wrote: On Tuesday 2015-06-30 17:00 -0400, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Exceptions can be granted, but will need to be justified as part of the Intent to Implement [3] and Intent to Ship process. I think this needs to define what the granularity of a new feature is. Does it count new CSS properties that are closely related to existing ones? New values for existing CSS properties? Or by features are you talking only about doing things that the Web couldn't do before, rather than new built-in capabilities than make existing things easier or faster to do? My $.02, our target should be the last category. I.e., anything you can presently do with a polyfill should be a strong candidate for not a new feature for these purposes. -Ekr Also, from a Web compatibility perspective, I don't think we can afford to do this for features that enough other browsers are shipping for all contexts. We implement some (though not too many) features because we're the last major browser to implement them; in those cases we're generally already dealing with a bunch of content that doesn't work in Firefox, especially on mobile, because of the lack of those features. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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: Secure contexts required for new web platform features
On Wed, Jul 1, 2015 at 8:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: we'd need to decide what https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy step 5 should mean in our particular case Colloquially: would you show a lock? Unfortunately, conveying the nuance involved in creating a stronger definition is non-trivial. And it rapidly descends into incomprehensibility. See for example: https://tools.ietf.org/html/rfc6125 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
On Tue, Jun 30, 2015 at 11:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/30/15 5:00 PM, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Might I ask who this we is (I don't recall general DOM module owner buy-in on this, but maybe I missed it?) Platform. There was no strong opposition to the Intent to deprecate: Insecure HTTP thread and in Whistler everyone attending the deprecating non-secure HTTP session agreed. Do you think this needs to be approached differently? what the definition of new web platform features is (e.g. does the webperf translateTime thing count? Yes, anything for which Platform creates Intent to Implement/Ship threads. What about adding the performance timing APIs we already ship for Window to workers?), The idea is that you indicate in the Intent to Implement/Ship thread whether you want an exception to the secure context restriction. The module owner based on input from dev.platform then decides whether an exception is warranted. and whether there's actually a stable definition of secure contexts that everyone agrees on? There's a definition Google and us use to implement service workers. That definition has been fairly stable though there are some small issues to be sorted out. Exceptions can be granted Who makes that call? Based on what criteria? Module owners, based on dev.platform input to the Intent to Implement/Ship threads. No criteria were established. Hopefully something that can be learned over time. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Secure contexts required for new web platform features
As a next step toward deprecating non-secure HTTP [1], we are making the following two changes to how we develop new web platform features, effective immediately: First, when we work on developing specifications for new web platform features, we will make sure that these specifications require secure contexts [2]. Second, when we implement new web platform features, they will be enabled only on secure contexts. Exceptions can be granted, but will need to be justified as part of the Intent to Implement [3] and Intent to Ship process. [1] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ [2] http://www.w3.org/TR/powerful-features/ [3] https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Secure contexts required for new web platform features
On 6/30/15 5:00 PM, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Might I ask who this we is (I don't recall general DOM module owner buy-in on this, but maybe I missed it?) what the definition of new web platform features is (e.g. does the webperf translateTime thing count? What about adding the performance timing APIs we already ship for Window to workers?), and whether there's actually a stable definition of secure contexts that everyone agrees on? Exceptions can be granted Who makes that call? Based on what criteria? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
