Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On Wed, Nov 19, 2014 at 4:50 PM, Patrick McManus mcma...@ducksong.com wrote: On Wed, Nov 19, 2014 at 1:45 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: Does Akamai's logo appearing on the Let's Encrypt announcements change Akamai's need for OE? (Seems *really* weird if not.) let's encrypt is awesome - more https is awesome. Indeed. Huge thanks to everyone who is making Let's Encrypt happen. regulatory compliance, What's this about? CA-risk, I.e. Let's Encrypt going away somehow? non-access to webpki. Does this mean intranets? A hosting or CDN provider doesn't control all of those things - especially the legacy and mixed content. Yes, OE definitely allows CDNs and hosting providers to make things better without getting their customers to take action. But the customers feeling they don't need to take action is the problem I'm worried about. There are basically 2 arguments against OE here: 1] you don't need OE because everyone can run https and 2] OE somehow undermines https I don't buy them because [1] remains a substantial body of data and [2] is unsubstantiated speculation and borders on untested FUD. Of course [2] is speculation. The notion that OE wouldn't harm the adoption of https is speculation, too. Both are fundamentally about guessing how the future would go in different circumstances without a way, in the future, to check how things had gone differently with the other option. However, it seems reasonable and believable that shortening the perceived distance between what you get with http URLs and what you get with https URLs makes some set of admins feel less urgency to move from http URLs to https URLs, so I think it's rather an exaggeration to call it FUD. It would be remarkably counterintuitive if OE didn't take away some of the momentum of https (at least if OE was adopted broadly by browsers). -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
Well, for one thing, it's not self-documenting. For the other, unless I'm missing something, we won't notice if an assertion is fixed and replaced with another one. And yes, catching when an assertion is fixed would clearly be useful, too. Cheers, David On 20/11/14 18:14, L. David Baron wrote: It's not all that fragile, since most tests don't have known assertions, so in that vast majority of tests, we have test coverage of regressions of assertion counts. This covers reftests, crashtests, and all mochitests except for mochitest-browser-chrome (bug 847275 covers doing it there). (We should probably make an attempt to go through the tests that have assertion count ranges including 0, since nothing catches when those assertions are fixed, and we're missing the test coverage there.) -David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: landing soon: core APIs for VR
On 19/11/14 17:15, Vladimir Vukicevic wrote: - Figure out how to ship/package/download/etc. the Oculus runtime pieces. The last discussions on these were that you were planning to approach Oculus to enquire about getting them under an open source license. How did that go? If that's not going to happen, what is your current proposal for how we deal with that? I'm sure the APIs you are adding are device-agnostic; but what's the plan for extending device support? Do we just tell other device manufacturers what our interface is and get them to write their own glue? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Array.prototype.includes available in Nightly *only* String.prototype.contains renamed to includes
Greetings! TC39 has decided to solve the web-compat issues with Array.prototype.contains that forced us to back out the feature on October 1st by renaming the method to includes. This has now landed on Nightly. However, it is Nightly-only for now, so don't use it in production code that's intended to make the merge to Developer's Edition. In further news and for similar reasons, String.prototype.contains will be renamed to includes as well. This is somewhat unfortunate as we've been shipping String.prototype.contains since Firefox 18. To work around that, it'll probably be necessary to keep contains as an alias for a while, ideally with a warning logged to the console. The rename is tracked in bug 1102219. thank you, till ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On Fri, Nov 21, 2014 at 3:53 PM, Patrick McManus mcma...@ducksong.com wrote: nosslsearch.google.com is an example of the weight of regulatory compliance in action. Google talks loudly about all https (and has the leading track record), yet there it is. And google isn't special in that regard. Why would they be allowed to use OE? I.e. Let's Encrypt going away somehow? More generally being dependent on a CA is an additional third party operational risk when comparing http:// vs https://.. you're already dependent on your DNS provider and an ISP and now your fate is also linked to the CA that signed your cert too. e.g. at the most basic level not revoking it on you - but also not doing something dumb unrelated to you that gets the signing cert your CA used tossed out of UAs (again). That risks seems tiny compared to the risk of having an end user man-in-the-middled. non-access to webpki. Does this mean intranets? mostly.. but more generally things that don't bind well to the global dns that the webpki relies on.. so potentially peer to peer and mesh interactions too.. But that would no longer be about HTTP. At least as far as the things we've been talking about exposing in browsers are concerned. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
On 11/21/14 8:49 AM, L. David Baron wrote: On Friday 2014-11-21 12:51 +0100, David Rajchenbach-Teller wrote: Well, for one thing, it's not self-documenting. We should comment them better (i.e., have a bug on each one, and point to the bug in a comment on the expectAssertions line). I wasn't able to do that when initially landing the assertion checking because, at the time, there were too many to keep up with the tree. At this point I could probably go back through the data I used for that to annotate the remaining ones. A self-documenting expectAssertions API might take an array of bug numbers (for expected assertions) as a function argument instead of an expected assertion count. For extra credit, expectAssertions could use the Bugzilla API to validate the bug numbers are relevant assertions and not RESOLVED FIXED. :) chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS display:contents
Awesome! I've looked forward to this for a long time! / Jonas On Thu, Nov 20, 2014 at 11:01 AM, Mats Palmgren m...@mozilla.com wrote: Summary: Styling an element with display:contents will inhibit generating a box for the element, but its children and pseudo-elements still generate boxes as normal. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=907396 Link to standard: CSS Display Module Level 3 http://dev.w3.org/csswg/css-display/#valdef-display-outside-contents Platform coverage: all Gecko based products Estimated or target release: Landed, disabled by default, in Firefox 36. Turning on the pref by default: TBD https://bugzilla.mozilla.org/show_bug.cgi?id=1102374 Preference behind which this will be implemented: layout.css.display-contents.enabled ___ 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: Intent to implement: CSS display:contents
The spec looks a bit weird though. It says that display: content; maps to display-outside: content; display-inside: block. Does that mean that you can't use display: content; to allow an element to for example wrap two table-rows? Or to wrap some inline text? / Jonas On Fri, Nov 21, 2014 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: Awesome! I've looked forward to this for a long time! / Jonas On Thu, Nov 20, 2014 at 11:01 AM, Mats Palmgren m...@mozilla.com wrote: Summary: Styling an element with display:contents will inhibit generating a box for the element, but its children and pseudo-elements still generate boxes as normal. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=907396 Link to standard: CSS Display Module Level 3 http://dev.w3.org/csswg/css-display/#valdef-display-outside-contents Platform coverage: all Gecko based products Estimated or target release: Landed, disabled by default, in Firefox 36. Turning on the pref by default: TBD https://bugzilla.mozilla.org/show_bug.cgi?id=1102374 Preference behind which this will be implemented: layout.css.display-contents.enabled ___ 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: Array.prototype.includes available in Nightly *only* String.prototype.contains renamed to includes
Has TC39 discussed how to handle the fact that there are a couple of classes in the DOM, like DOMStringList, which we'd like to replace with normal JS Arrays. But these DOM classes have a .contains function which so far has meant that such a switch was not possible due to the arrays not having a .contains. I had hoped that once Arrays got a .contains function that we could make this switch. Does TC39 recommend that we stick with returning DOM objects here and not switch to Arrays? Or that we do something else? / Jonas On Fri, Nov 21, 2014 at 5:10 AM, Till Schneidereit t...@tillschneidereit.net wrote: Greetings! TC39 has decided to solve the web-compat issues with Array.prototype.contains that forced us to back out the feature on October 1st by renaming the method to includes. This has now landed on Nightly. However, it is Nightly-only for now, so don't use it in production code that's intended to make the merge to Developer's Edition. In further news and for similar reasons, String.prototype.contains will be renamed to includes as well. This is somewhat unfortunate as we've been shipping String.prototype.contains since Firefox 18. To work around that, it'll probably be necessary to keep contains as an alias for a while, ideally with a warning logged to the console. The rename is tracked in bug 1102219. thank you, till ___ 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: Intent to implement: CSS display:contents
On Friday 2014-11-21 14:51 -0800, Jonas Sicking wrote: The spec looks a bit weird though. It says that display: content; maps to display-outside: content; display-inside: block. The display-inside value shouldn't actually matter; it gets ignored. It just has to be something. (Perhaps it should be 'auto', though, since that's the initial value.) -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: http-schemed URLs and HTTP/2 over unauthenticated TLS
On 2014-11-21, at 08:19, Justin Dolske dol...@mozilla.com wrote: Is that a direct or indirect cause? AFAIK nothing directly requires Google to offer this, but the alternative would be organizations and networks who do want/need to see traffic simply blocking Google services. And so Google has made the voluntary choice to support nosslsearch (presumably for a mix of reasons like revenue impact and perception of service availability). Why would the precise form of the motivating force be relevant? The point is that there are pressures on content other than the ones that we might like to think push them toward https://. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
