Re: Proposed W3C Charter: Web of Things Working Group
Hi all, This is a great discussion and (inevitably) security is in fact one of the key focus areas for the proposed IOT platform/framework that we are working to create in the Connected devices team. Tantek raises some good points - We are painfully aware of those. This is going to take much more than just building our own piece of software and hoping for the best. We are listing those ideas and create a plan around them. I am proposing we get together in the Hawaii Work week to discuss some of the challenges here and what/how Mozilla can do about those. I and Nicole would try to find a slot in this (crazy) week. Please ping us if you would like to be part of this. -Sandip On Thu, Dec 1, 2016 at 9:41 AM, Benjamin Francis wrote: > Hi Tantek, > > On the very serious issues of security and privacy on the Internet of > Things, I agree with you. > > On your proposed solution to those problems of somehow trying to slow down > the worldwide deployment of IoT devices (currently forecast to reach tens > of billions by 2020) and prevent any efforts towards standardisation and > the defining of best practices, I couldn't disagree with you more. > > We have a whole department at Mozilla dedicated to exploring this space > and it is an organisational goal to attempt to influence standards in this > area in order to embody Mozilla's values into the design and architecture > of IoT. > > Let's try to make our feedback to the W3C a little more constructive, if > we can. > > Ben > > On 29 November 2016 at 19:38, Tantek Çelik wrote: > >> To add to this thread, I think there are still fundamental security >> issues, which have only gotten worse, that the charter does not >> address, nor has the incubation to date come even close to >> understanding, much less prototyping / stress-testing. >> >> >> 1. The rapid deployment of WoT/IoT devices poses an existential threat >> to the open internet (something we, Mozilla, are particularly focused >> on protecting more than other orgs are) due to their fundamentally >> worse security. >> >> Since the DDoS attack on krebsonsecurity which motivated our initial >> formal objection based on lack of security considerations in the >> charter and incubation, there was the subsequent DYN DDoS attack which >> took down major sites (Twitter, Github, Reddit, etc.), and that's only >> with the current deployment of insecure IoT devices, by rogue groups >> using open source malware. Basically it proved the security point of >> our formal objection. >> >> WoT/IoT devices are both known to already have worse security, and >> expected to in the future, both in initial design / development, and >> with the lack of incentive to do security software updates due to such >> devices being so low margin, often built by small companies that have >> low life expectancy themselves, then whitelabel bundled into larger >> devices, with no way of updating the embedded software, e.g. the IoT >> cameras used in the DDoS attacks. >> >> The proposed charter (nor anyone's incubation efforts) does/do not >> address these low cost, low margin, low life expectancy company, >> whitelabel embedding issues. All of which have been shown to be real >> problems. >> >> This threat is so bad, that it's not clear that any increased >> deployment of WoT/IoT is "good" for the open internet. >> >> That regardless of tech stack, it is in the interest of maintaining an >> open internet to do what we can to actually *slow down* the deployment >> of of anything WoT/IoT, up to and including opposing standardization >> efforts which seek to *accelerate* the deployment of such devices. >> This is not an "absolute" situation, where we might as well give up >> because it's going to happen anyway like somewhere other than W3C, but >> rather a set of race conditions, where slowing things down anywhere at >> all may still be incrementally helpful (make the internet as a whole >> less vulnerable - it's a spectrum). >> >> >> 2. Increased invasive surveillance. >> >> The above IoT security threat scenarios that we've experienced were >> from small groups or individuals using malware they didn't even write. >> There is an even worse potential threat from insecure WoT/IoT devices, >> and that is state-level actors using those very same existing and >> expected security flaws to turn WoT/IoT devices into the largest mass >> surveillance and data gathering effort in history. >> >> Every sensor on every such device a user puts in their home becomes a >> potential surveillance data gathering node. Note that most the >> above-noted insecure devices used in the attacks were IoT *cameras*. >> >> Nothing from the proposed WoT charter, nor experiments/incubations >> shows any semblance of any of the participants taking this threat >> scenario seriously, nor did any of them raise or document any concerns >> like what happened to Krebs. >> >> (The only person in the W3C context who did provide warnings of the >> kinds of attacks occuring that eventually
Re: Intent to implement: OpenType Variation Fonts
On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote: > DevTools bug: It's not yet clear to me whether specific DevTools work > will be needed, beyond the support we'll automatically get for a new CSS > property. I think DevTools may want to display a panel which lists all available variation axis supported by the font, and allow developers to adjust them. I think there is some discussion about adding this kind of detection to Font Loading API. Before that API gets stable I guess we can implement an internal thing listing that for DevTools and as an experiment for the future standard API. > (Because of the already-existing support for font variations in the > macOS font system, this will probably be the first platform backend to > be implemented in Gecko. There's a try build linked from > https://bugzilla.mozilla.org/show_bug.cgi?id=1321031#c5 for anyone who > cares to play around with it already.) Great work \o/ - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: OpenType Variation Fonts
On 06/12/2016 19:04, Xidorn Quan wrote: On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote: DevTools bug: It's not yet clear to me whether specific DevTools work will be needed, beyond the support we'll automatically get for a new CSS property. I think DevTools may want to display a panel which lists all available variation axis supported by the font, and allow developers to adjust them. Yes, perhaps something like that would be useful. Though we don't do anything along those lines for OpenType font features at present. If DevTools is to start exposing details of "font capabilities", both features and variations should be treated similarly. I think that makes it a broader topic, not directly linked to variations, which would be just one among various details that could be exposed via a DevTools "font inspector". JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS Grid
+cc: abillings re: fuzzing CSS Grid. On Monday, December 5, 2016, Benjamin Smedberg wrote: > Have the various grid properties be added to our fuzzers and we've been > fuzzing the implementation fairly comprehensively? > > --BDS > > On Tue, Nov 15, 2016 at 7:40 PM, Mats Palmgren > wrote: > > > As of Gecko 52, I intend to let CSS Grid ride the trains on all > platforms. > > https://drafts.csswg.org/css-grid/ > > This also includes all parts of the CSS Box Alignment spec that are > > relevant to Grid layout: > > https://drafts.csswg.org/css-align-3/ > > > > It has been developed behind the "layout.css.grid.enabled" preference, > > and has been enabled by default in Nightly and Aurora for some time now. > > > > Other UAs shipping this or intending to ship it are: > > Chrome - intends to ship: > > https://groups.google.com/a/chromium.org/forum/#!topic/blink > > -dev/hBx1ffTS9CQ > > Safari - is implementing it (independently): > > https://bugs.webkit.org/show_bug.cgi?id=60731 > > Edge - status unknown to me > > > > Note about the 'subgrid' feature: > > We will *not* support the subgrid feature of CSS Grid in this first > > release. This feature is marked as "at-risk" in the spec and thus > > not needed for spec compliance. (Chrome is likewise not going to > > support subgrid in their first release.) > > > > This feature was previously discussed in this "intent to implement" > thread: > > https://groups.google.com/forum/#!msg/mozilla.dev.platform/ > > jSmfRivZOrU/ZMPcwySUEW4J > > > > Bug to turn on by default: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1217086 > > > > CSS Grid meta bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid > > > > The Devtools team is implementing specific tools for Grid: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1181227 > > (some of which will ship in 52 I'm told) > > > > > > /Mats > > ___ > > 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: Intent to ship: CSS Grid
On 12/05/2016 08:00 PM, Boris Zbarsky wrote: What performance testing have we done on this implementation? Have we done edge-case stress-testing? Stress-testing with large but "real-life" layouts? Something else? Nope, I've done no /dedicated/ performance testing so far. Both I and dholbert (who did the reviews) have been mindful of potential performance issues throughout development though, fwiw. Now that the implementation of features for release is complete, I intend to do the kind of dedicated testing you're asking about. And I invite everyone else with an interest in Grid to do the same. There are two O(n^2) bugs that I'm aware of, but those only occur in edge cases (fragmentation) so we decided they weren't release blockers, since they won't affect viewing typical Grid layouts. They will certainly be addressed in v53 though. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS Grid
On 12/05/2016 09:53 PM, Benjamin Smedberg wrote: Have the various grid properties be added to our fuzzers and we've been fuzzing the implementation fairly comprehensively? Yes, I believe Grid is included in our normal fuzz testing. Grid has been enabled by default in Nightly and Aurora (including our testing profile) for about a year now. I've seen a few bug reports from fuzz testing in that time. There's also a fairly extensive reftest suite for Grid which I think is fed into the fuzz testing and with the usual DOM/CSS fuzzing on top of that I think fuzzing Grid layout is well covered. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
