Re: Ambient Light Sensor API
On Tue, Apr 25, 2017 at 5:26 PM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > So the risk is not that high since if the image is not protected I can get > it and do evil things without requiring the Light Sensor API. Isn't it? > Generally, we take cross-origin information theft pretty seriously. -Ekr > On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla wrote: > >> >> >> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < >> sdelapue...@mozilla.com> wrote: >> >>> The article says: >>> >>> Embed an image from the attacked domain; generally this will be a >>> resource >>> > which varies for different authenticated users such as the logged-in >>> userโs >>> > avatar or a security code. >>> > >>> >>> And then refers all the steps to this image (binarizing, expand and >>> measure >>> per pixel) but, If I can embed that image, it is because I know the URL >>> for >>> it and the proper auth tokens if it is protected. In that case, why to >>> not >>> simply steal the image? >>> >> >> The simple version of this is that the image is cookie protected. >> >> -Ekr >> >> >>> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston >>> wrote: >>> >>> > Auth related images are the attack vector, that and history attacks on >>> > same domain. >>> > >>> > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente < >>> > sdelapue...@mozilla.com> wrote: >>> > >>> >> Sorry for my ignorance but, in the case of Stealing cross-origin >>> >> resources, >>> >> I don't get the point of the attack. If have the ability to embed the >>> >> image >>> >> in step 1, why to not simply send this to evil.com for further >>> >> processing? >>> >> How it is possible for evil.com to get access to protected resources? >>> >> >>> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari < >>> ehsan.akhg...@gmail.com> >>> >> wrote: >>> >> >>> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: >>> >> > >>> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla >>> wrote: >>> >> >> >>> >> >> Going back to Jonathan's (I think) question. Does anyone use this >>> at >>> >> all >>> >> >>> in >>> >> >>> the field? >>> >> >>> >>> >> >>> Chrome's usage metrics say <= 0.0001% of page loads: >>> >> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi >>> >> >> entLightSensorConstructor. >>> >> >> >>> >> > >>> >> > This is the new version of the spec which we don't ship. >>> >> > >>> >> > >>> >> > We are going to collect telemetry in >>> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. >>> >> >> ___ >>> >> >> 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 >>> >> >>> > >>> > >>> >>> >>> -- >>> >>> ___ >>> 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: Ambient Light Sensor API
So the risk is not that high since if the image is not protected I can get it and do evil things without requiring the Light Sensor API. Isn't it? On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla wrote: > > > On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < > sdelapue...@mozilla.com> wrote: > >> The article says: >> >> Embed an image from the attacked domain; generally this will be a resource >> > which varies for different authenticated users such as the logged-in >> userโs >> > avatar or a security code. >> > >> >> And then refers all the steps to this image (binarizing, expand and >> measure >> per pixel) but, If I can embed that image, it is because I know the URL >> for >> it and the proper auth tokens if it is protected. In that case, why to not >> simply steal the image? >> > > The simple version of this is that the image is cookie protected. > > -Ekr > > >> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston >> wrote: >> >> > Auth related images are the attack vector, that and history attacks on >> > same domain. >> > >> > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente < >> > sdelapue...@mozilla.com> wrote: >> > >> >> Sorry for my ignorance but, in the case of Stealing cross-origin >> >> resources, >> >> I don't get the point of the attack. If have the ability to embed the >> >> image >> >> in step 1, why to not simply send this to evil.com for further >> >> processing? >> >> How it is possible for evil.com to get access to protected resources? >> >> >> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari < >> ehsan.akhg...@gmail.com> >> >> wrote: >> >> >> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: >> >> > >> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla >> wrote: >> >> >> >> >> >> Going back to Jonathan's (I think) question. Does anyone use this at >> >> all >> >> >>> in >> >> >>> the field? >> >> >>> >> >> >>> Chrome's usage metrics say <= 0.0001% of page loads: >> >> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi >> >> >> entLightSensorConstructor. >> >> >> >> >> > >> >> > This is the new version of the spec which we don't ship. >> >> > >> >> > >> >> > We are going to collect telemetry in >> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. >> >> >> ___ >> >> >> 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 >> >> >> > >> > >> >> >> -- >> >> ___ >> 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: Ambient Light Sensor API
On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > The article says: > > Embed an image from the attacked domain; generally this will be a resource > > which varies for different authenticated users such as the logged-in > userโs > > avatar or a security code. > > > > And then refers all the steps to this image (binarizing, expand and measure > per pixel) but, If I can embed that image, it is because I know the URL for > it and the proper auth tokens if it is protected. In that case, why to not > simply steal the image? > The simple version of this is that the image is cookie protected. -Ekr > On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston > wrote: > > > Auth related images are the attack vector, that and history attacks on > > same domain. > > > > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente < > > sdelapue...@mozilla.com> wrote: > > > >> Sorry for my ignorance but, in the case of Stealing cross-origin > >> resources, > >> I don't get the point of the attack. If have the ability to embed the > >> image > >> in step 1, why to not simply send this to evil.com for further > >> processing? > >> How it is possible for evil.com to get access to protected resources? > >> > >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari > > >> wrote: > >> > >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: > >> > > >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > >> >> > >> >> Going back to Jonathan's (I think) question. Does anyone use this at > >> all > >> >>> in > >> >>> the field? > >> >>> > >> >>> Chrome's usage metrics say <= 0.0001% of page loads: > >> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi > >> >> entLightSensorConstructor. > >> >> > >> > > >> > This is the new version of the spec which we don't ship. > >> > > >> > > >> > We are going to collect telemetry in > >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. > >> >> ___ > >> >> 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 > >> > > > > > > > -- > > ___ > 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: Ambient Light Sensor API
The article says: Embed an image from the attacked domain; generally this will be a resource > which varies for different authenticated users such as the logged-in userโs > avatar or a security code. > And then refers all the steps to this image (binarizing, expand and measure per pixel) but, If I can embed that image, it is because I know the URL for it and the proper auth tokens if it is protected. In that case, why to not simply steal the image? On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston wrote: > Auth related images are the attack vector, that and history attacks on > same domain. > > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente < > sdelapue...@mozilla.com> wrote: > >> Sorry for my ignorance but, in the case of Stealing cross-origin >> resources, >> I don't get the point of the attack. If have the ability to embed the >> image >> in step 1, why to not simply send this to evil.com for further >> processing? >> How it is possible for evil.com to get access to protected resources? >> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari >> wrote: >> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote: >> > >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: >> >> >> >> Going back to Jonathan's (I think) question. Does anyone use this at >> all >> >>> in >> >>> the field? >> >>> >> >>> Chrome's usage metrics say <= 0.0001% of page loads: >> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi >> >> entLightSensorConstructor. >> >> >> > >> > This is the new version of the spec which we don't ship. >> > >> > >> > We are going to collect telemetry in >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. >> >> ___ >> >> 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 >> > > -- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ambient Light Sensor API
Sorry for my ignorance but, in the case of Stealing cross-origin resources, I don't get the point of the attack. If have the ability to embed the image in step 1, why to not simply send this to evil.com for further processing? How it is possible for evil.com to get access to protected resources? On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari wrote: > On 04/25/2017 10:25 AM, Andrew Overholt wrote: > >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: >> >> Going back to Jonathan's (I think) question. Does anyone use this at all >>> in >>> the field? >>> >>> Chrome's usage metrics say <= 0.0001% of page loads: >> https://www.chromestatus.com/metrics/feature/popularity#Ambi >> entLightSensorConstructor. >> > > This is the new version of the spec which we don't ship. > > > We are going to collect telemetry in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. >> ___ >> 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: A reminder about commit messages: they should be useful
On Tuesday, April 25, 2017 at 1:20:29 PM UTC-4, Boris Zbarsky wrote: > On 4/25/17 1:07 PM, Alexander Surkov wrote: > > I bet there's always room for improvements, and I hope this was a > > counterpoint for the example only, not for the bug organization approach. > > Sort of. > > It was a counterpoint to "just check the bug; all the info is there". > Often it's not there, or not there in usable form. > > If people included a summary of the discussion in the bug right about > when they commit, or had bugs that actually explained what's going on > clearly. I would be a lot more OK with the "check the bug" approach. > > > Overall it feels with me that long comments vs check-the-bug is rather > > different styles > > To be clear, I don't think commit messages need to be _long_. They need > to be _useful_. A commit message pointing to a particular bug comment > that explains all the ins and outs is no worse, from my point of view, > than a commit message that explains the ins and outs. > > The problem I started this thread to address is things like a commit > message that says "flip this bit" and references a bug entitled "flip > this bit", with no explanation of what the bit does or why it should be > flipped. I hope we can all agree that _that_ is not OK. And it's far > too common. > > -Boris Maybe we should have a style guide, explaining what makes a good commit message and what makes a good and descriptive bug, with number of (good and bad) examples. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI: Visual C++ 2017 build system support landing
I'm about to land some patches[1] that will allow configure to detect a Visual C++ 2017 installation. You should be able to launch a MozillaBuild `start-shell.bat` shell and build without having to have the Visual C++ environment configured. The only thing that will change from the current state of affairs is that if you have both VC2015 and VC2017 installed, and you're building from a start-shell shell (not start-shell-msvc2015) configure will now default to using VC2017 instead of VC2015. I've added a new configure option you can use to select the compiler version you want in this situation, so you can add: ac_add_options --with-visual-studio-version=2015 to your mozconfig to tell configure to continue to use VC2015 when it autodetects a compiler for you. Do note that VC2017 is not currently built in CI[2], so it's likely to get accidentally broken until we get that fixed. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1318143 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1318193 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A reminder about commit messages: they should be useful
On 04/25/2017 08:20 PM, Boris Zbarsky wrote: On 4/25/17 1:07 PM, Alexander Surkov wrote: I bet there's always room for improvements, and I hope this was a counterpoint for the example only, not for the bug organization approach. Sort of. It was a counterpoint to "just check the bug; all the info is there". Often it's not there, or not there in usable form. If people included a summary of the discussion in the bug right about when they commit, or had bugs that actually explained what's going on clearly. I would be a lot more OK with the "check the bug" approach. Overall it feels with me that long comments vs check-the-bug is rather different styles To be clear, I don't think commit messages need to be _long_. They need to be _useful_. Exactly. Recently I've seen some commit messages to be long but not useful, in the style "I did this and that", but not really explaining why. A commit message pointing to a particular bug comment that explains all the ins and outs is no worse, from my point of view, than a commit message that explains the ins and outs. A major issue comes from bugs where the work is split to several patches. That is why bugs really need to explain it all too. The problem I started this thread to address is things like a commit message that says "flip this bit" and references a bug entitled "flip this bit", with no explanation of what the bit does or why it should be flipped. I hope we can all agree that _that_ is not OK. And it's far too common. Yeah, definitely. The bug should be clear about what it is about to fix, and the commit message should also be clear what it is doing and why. In some cases bug title is clear enough to explain why something is broken or should be changed, but not usually. (I have perhaps a bit bad habit to file bugs with just descriptive title, especially in case of "Consider to do foo" bugs) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ambient Light Sensor API
On 04/25/2017 10:25 AM, Andrew Overholt wrote: On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: Going back to Jonathan's (I think) question. Does anyone use this at all in the field? Chrome's usage metrics say <= 0.0001% of page loads: https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor. This is the new version of the spec which we don't ship. We are going to collect telemetry in https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. ___ 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: Future of out-of-tree spell checkers?
On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen wrote: > What problem did you mean to address by code signing? The reason I suggested code signing is because loading libvoikko would provide an easy way for people to inject code into Firefox. For a while we've been trying to make it difficult for semi-legit-but-not-quite-malware parties to load crappy code into Firefox (I'm thinking of crappy antivirus software, adware, etc.). Removing binary XPCOM components and NPAPI support, and requiring add-on signing, are all facets of this. If we simply load and run code from any file named voikko.dll on the user's computer, then we've opened up another door. It's a less powerful door since we probably (I hope) wouldn't give them access to XPCOM. But they could still open windows that look like they came from Firefox and I imagine there's other bad stuff I haven't thought of. People often object to this argument by saying that, without libvoikko, these bad actors could just replace libxul or something. But I think in practice it would be harder for them to pull that off, both technically and socially. From a technical perspective, it's harder to replace core parts of Firefox while still leaving it in a working state, especially if the updater is still allowed to run. And socially, I think it makes their software look a lot more like malware if they replace parts of Firefox rather than simply install a new DLL that we then load. Overall, though, I agree with Ehsan that this discussion isn't very worthwhile unless we what the voikko people want to do. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A reminder about commit messages: they should be useful
On 4/25/17 1:07 PM, Alexander Surkov wrote: I bet there's always room for improvements, and I hope this was a counterpoint for the example only, not for the bug organization approach. Sort of. It was a counterpoint to "just check the bug; all the info is there". Often it's not there, or not there in usable form. If people included a summary of the discussion in the bug right about when they commit, or had bugs that actually explained what's going on clearly. I would be a lot more OK with the "check the bug" approach. Overall it feels with me that long comments vs check-the-bug is rather different styles To be clear, I don't think commit messages need to be _long_. They need to be _useful_. A commit message pointing to a particular bug comment that explains all the ins and outs is no worse, from my point of view, than a commit message that explains the ins and outs. The problem I started this thread to address is things like a commit message that says "flip this bit" and references a bug entitled "flip this bit", with no explanation of what the bit does or why it should be flipped. I hope we can all agree that _that_ is not OK. And it's far too common. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ambient Light Sensor API
CSS may implement a 3 state light level for most use cases of this metric, I would suggest that would be much better. According to the removal bug I raised, it looks like the spec has vastly changed anyway: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076#c7 I have a patch ready to measure all usages of the Generic Sensors from the light sensors to orientation: https://bugzilla.mozilla.org/show_bug.cgi?id=1359124 I would suggest we should check how often these are moved, but also move to remove them when it makes sense to over insecure context. If our implementations don't match what Google is pushing in it's origin trial it may make sense to remove them anyway assuming there won't be much breakage. Thanks Jonathan On Tue, Apr 25, 2017 at 2:35 PM, Eric Rescorla wrote: > Going back to Jonathan's (I think) question. Does anyone use this at all in > the field? > > -Ekr > > > On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote: > > > On 2017-04-25 00:04, Martin Thomson wrote: > > > I think that 60Hz is too high a rate for this. > > > > > > I suggest that we restrict this to top-level, foreground, and secure > > > contexts. Note that foreground is a necessary precondition for the > > > attack, so that restriction doesn't really help here. Critically, > > > rate limit access much more than the 60Hz recommended for the > > > accelerometer. 5Hz might be sufficient here, maybe even lower. > > > > Note that they already talk about 2Hz being the rate they think is > > realistic to do their attack, and that 5Hz is probably an upper bound of > > their attack, so reducing it from 60 to 5 doesn't actually change > anything > > and you would need to go even lower. You could for instance do something > > like only allowing it 1 time per minute, and require user approval for > > higher frequencies. > > > > The other suggestion they have in their paper is to reduce the number of > > values you return, say 4 different values. > > > > > > Kurt > > > > ___ > > 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: Ambient Light Sensor API
Those stats aren't the old version of the spec, Google is pushing this constructor version however the old version as mentioned in the issues is event driven. We perhaps remove safely for insecure based on previous comments though. On Tue, Apr 25, 2017 at 4:46 PM, Eric Rescorla wrote: > This suggests that maybe we could just turn it off > > On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt > wrote: > > > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > > > >> Going back to Jonathan's (I think) question. Does anyone use this at all > >> in > >> the field? > >> > > > > Chrome's usage metrics say <= 0.0001% of page loads: > > https://www.chromestatus.com/metrics/feature/popularity# > > AmbientLightSensorConstructor. We are going to collect telemetry in > > https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. > > > ___ > 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: A reminder about commit messages: they should be useful
On Tuesday, April 25, 2017 at 11:11:28 AM UTC-4, Boris Zbarsky wrote: > On 4/25/17 10:50 AM, Alexander Surkov wrote: > > I don't want to affirm that this approach suites every Mozilla module, but > > it seems be working well in relatively small modules like accessibility one. > > Just as a counterpoint... as non-regular contributor to the > accessibility module, I have a _very_ hard time making sense of > accessibility commits, precisely because the commit messages are not > often not very descriptive and the bugs are often hard to make sense of > for a non-expert. > > I don't have this problem in cases where I'm similarly out of my depth > but commit messages contain more information. I bet there's always room for improvements, and I hope this was a counterpoint for the example only, not for the bug organization approach. Overall it feels with me that long comments vs check-the-bug is rather different styles, with their own benefits and disadvantages, and different people prefer one over another one. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Publishing Working Group
The W3C is proposing a new charter for: Publishing Working Group https://www.w3.org/2017/04/publ-wg-charter/ https://lists.w3.org/Archives/Public/public-new-work/2017Apr/0002.html Mozilla has the opportunity to register support, comments, or objections through Sunday, May 14, 2017. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. This working group is the result of the recent merger of IDPF into W3C; see https://www.w3.org/blog/news/archives/6102 . The charter of the group involves some work on packaging and work on EPUB 4. There has also been a good bit of discussion of changes since the charter was proposed; see https://lists.w3.org/Archives/Public/public-new-work/2017Apr/thread.html#msg12 and perhaps particularly https://lists.w3.org/Archives/Public/public-new-work/2017Apr/0021.html -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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: TV Control Working Group
The W3C is proposing a revised charter for: TV Control Working Group https://www.w3.org/2017/03/tvcontrol.html https://lists.w3.org/Archives/Public/public-new-work/2017Mar/0010.html Changes from previous charter: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F03%2Ftvcontrol.html&doc2=https%3A%2F%2Fwww.w3.org%2F2017%2F03%2Ftvcontrol.html Mozilla has the opportunity to register support, comments, or objections through Friday, April 28, 2017 (this Friday, sorry!). Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. If my memory is correct, this is work that Mozilla was heavily involved in at the beginning but has not been involved in lately. It's not clear how much interest there is in the work -- both within the W3C and within the wider TV industry. -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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ambient Light Sensor API
This suggests that maybe we could just turn it off On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt wrote: > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > >> Going back to Jonathan's (I think) question. Does anyone use this at all >> in >> the field? >> > > Chrome's usage metrics say <= 0.0001% of page loads: > https://www.chromestatus.com/metrics/feature/popularity# > AmbientLightSensorConstructor. We are going to collect telemetry in > https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A reminder about commit messages: they should be useful
On 4/25/17 10:50 AM, Alexander Surkov wrote: I don't want to affirm that this approach suites every Mozilla module, but it seems be working well in relatively small modules like accessibility one. Just as a counterpoint... as non-regular contributor to the accessibility module, I have a _very_ hard time making sense of accessibility commits, precisely because the commit messages are not often not very descriptive and the bugs are often hard to make sense of for a non-expert. I don't have this problem in cases where I'm similarly out of my depth but commit messages contain more information. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A reminder about commit messages: they should be useful
On Tuesday, April 18, 2017 at 6:53:14 PM UTC-4, smaug wrote: > On 04/18/2017 04:24 PM, Ehsan Akhgari wrote: > > On 2017-04-18 12:30 AM, Mike Hommey wrote: > >>> I've yet to see that to happen. What is crucial is fast way to browse > >>> through the blame in time. So commit messages should be short and > >>> descriptive. Telling what and why. (I very often need to go back to CVS > >>> era > >>> code). I won't spend time reading several paragraphs of commit messages. > >>> Those are just too long. > >>> Basically first line should tell the essentials 'what' and maybe the most > >>> obvious 'why' and the next couple of lines explaining 'why' more > >>> precisely. > >>> Don't write stories which will make blame-browsing slower. > >> > >> What sort of blame-browsing makes more than the first line of the commit > >> message a burden? I'm curious, because that doesn't match my use of > >> blame. > > > > I can't say I have had this issue, and I also do a lot of code > > archaeology as well. I suppose to a large extent this does depend on > > what tools you use, perhaps. These days I use searchfox.org for a lot > > of blame browsing that I do, which displays only the first line in the > > default UI and only displays the full commit message when you look at > > the full commit. I find this a pretty good balance. > > > >> And I've done my share of archeology and for old enough stuff you often > >> end up with one of: > >> - a completely useless commit message *and* useless bug (if there's even > >> a bug number) > >> - a mostly useless commit message and some information in the bug. > >> You're lucky if it's all contained in a few sentences. > >> - a mostly useless commit message and tons of information in the bug, > >> that you have to spend quite some time parsing through. > >> > >> In *all* cases, you have to go switch between your blame and bugzilla. > >> It's a PITA. Now, when you have everything in VCS, you just work with > >> your blame. Obviously, CVS-era commits are not going to change, but do > >> you really want to keep things in the same state for commits done now, > >> when you (or someone else) goes through blame in a few years? > > > > Agreed. > > > > Also even for newer code you often end up in the third category. Maybe > > it's just me but I spend a lot of time reading old bugs, and I find it a > > huge time sink to read through tons of comments just to find where the > > actual discussion about why the fix was done in the way that it was done > > happened in the bug. Sometimes I have to really read 100+ comments. > > And the sad reality is that all too often I find very questionable > > things in patches happen in bugs without any discussion whatsoever which > > means that sometimes one can spend half an hour reading those 100+ > > comments very carefully to find out in the end that they have just > > wasted their time and the bug actually did not contain the interesting > > information in the first place. > > > > I think I would probably sympathize more with the side of the argument > > arguing for bugs as the source of the truth if this wasn't really true, > > but I think part of the reason why people don't bother writing good > > commit messages is that they assume that the reasons behind the > > approaches they take and the design decisions and the like are obvious, > > and while that may be true *now* and to them and the code reviewer, it > > will not be true to everyone and in the future, and because of that if > > you're not careful the important information is just not captured > > anywhere. I hope we can all agree that it's important that we capture > > this information for the maintainability of our code, even if we can't > > agree where the information needs to be captured. :-) > > > > The important part of documentation should be in code comments, not commit > messages. > We aren't too good commenting code. > > > Another thing, today I was looking at a bug which has several patches, and > realized one can't really understand the big picture by looking at commit > messages of some particular commit. There needs to be some centralized place > for that, and it is the bug. Going through each patches individually and > looking at the commit messages would be really painful way to see what and > why was changed. As a guy who stayed with Mozilla for a while, here's my two cents. I thumb up for Olli's descriptive short what and why commit messages in favor to long stories stretched over multiple patches. I'm also keen on going to the bug for details if a commit doesn't look quite clear with me. I realize that bugs might be of thousands of comments, which makes them hard to read, but that's probably a case of bugs organization: one meta and several small dependent bugs might help here. I don't want to affirm that this approach suites every Mozilla module, but it seems be working well in relatively small modules like accessibility one. ___
Re: Ambient Light Sensor API
On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > Going back to Jonathan's (I think) question. Does anyone use this at all in > the field? > Chrome's usage metrics say <= 0.0001% of page loads: https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor. We are going to collect telemetry in https://bugzilla.mozilla.org/show_bug.cgi?id=1359124. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ambient Light Sensor API
On 04/24/2017 06:04 PM, Martin Thomson wrote: I think that 60Hz is too high a rate for this. I suggest that we restrict this to top-level, foreground, and secure contexts. Note that foreground is a necessary precondition for the attack, so that restriction doesn't really help here. Critically, rate limit access much more than the 60Hz recommended for the accelerometer. 5Hz might be sufficient here, maybe even lower. How does restricting this to secure contexts help? If I understand correctly the attacks being discussed in the article referenced here are stealing cross origin data and user's history. These aren't things that we can expose to secure contexts any more than we can expose to insecure contexts. Since the amount of information that can be extracted is a function of the number of times the API is called and the accuracy of the reading, we should consider also reducing the accuracy of the reading. The attack reduced its information extraction to 1 bit per reading, but you can't assume that this is the actual limit. Fuzzing is much harder than it seems if your intent is to deal with an attack. I can walk through some strategies if someone is interested in doing this. That all assumes that you aren't willing to add a dialog for this, which seems like the right answer. That said, if the mitigation strategies - rate limiting in particular - can't be implemented in a reasonable time-frame, I would consider preffing this off (though the pref name suggests that there would be collateral). It seems hard to explain the risks of granting this permission to a site to a user correctly. :-/ A permission prompt that doesn't allow us do that isn't very useful. Also given that the API is an event handler, it doesn't really lend itself to a permission prompt anyway. But also given the event handler nature of the API, not dispatching the event makes it very unlikely to break pages, unless if the page's functionality explicitly depends on the ambient light, I think, which works in our favor if we decide in that direction. I think I'm leaning in that way personally rather than coming up with a complicated heuristic here and potentially getting it wrong. On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston wrote: As a follow up, it looks like the device motion events defined in the device sensors: http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp should also be restricting based on isSecureContext. The spec mentions "should take into consideration the following suggestions" : https://www.w3.org/TR/orientation-event/#security-and-privacy We don't do those measures from what I can see. Can we make the webIDL represent this requirement for requiring secure context instead? Thanks Jonathan On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston wrote: As mentioned a permission prompt isn't great. In it's current state it should probably be considered a "powerful feature" that we can remove just for secure context. Granted this doesn't fix the exploit mentioned here though. Freddy highlighted that the spec itself suggests the Generic Sensor API is the security model which requires: https://www.w3.org/TR/generic- sensor/#secure-context I can't see that as a restriction in our codebase though? This looks like a specification violation here. Thanks Jonathan On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun wrote: The Ambient Light spec defers its security and privacy considerations to the generic sensors specification, which states all interfaces defined by this specification or extension specifications must only be available within a secure context. Would we require telemetry before we restricted this to secure contexts? On 24.04.2017 15:24, Frederik Braun wrote: Hi, there is a relatively recent blog post [1] by Lukasz Olejnik and Artur Janc that explains how one can steal sensitive data using the Ambient Light Sensor API [2]. We ship API and its enabled by default [3,4] and it seems we have no telemetry for this feature. Unshipping for non-secure context and making it HTTPS-only wouldn't address the attack. The API as implemented is using the 'devicelight' event on window. I suppose one might also be able to implement a prompt for this, but that doesn't sound very appealing (prompt fatigue, etc., etc.). What do people think we should do about this? Cheers, Freddy [1] https://blog.lukaszolejnik.com/stealing-sensitive-browser- data-with-the-w3c-ambient-light-sensor-api/ [2] https://www.w3.org/TR/ambient-light/ [3] It is behind the dom.sensors.enabled (sic!) flag. [4] http://searchfox.org/mozilla-central/source/dom/system/nsDev iceSensors.cpp ___ 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/listi
Re: Ambient Light Sensor API
Going back to Jonathan's (I think) question. Does anyone use this at all in the field? -Ekr On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote: > On 2017-04-25 00:04, Martin Thomson wrote: > > I think that 60Hz is too high a rate for this. > > > > I suggest that we restrict this to top-level, foreground, and secure > > contexts. Note that foreground is a necessary precondition for the > > attack, so that restriction doesn't really help here. Critically, > > rate limit access much more than the 60Hz recommended for the > > accelerometer. 5Hz might be sufficient here, maybe even lower. > > Note that they already talk about 2Hz being the rate they think is > realistic to do their attack, and that 5Hz is probably an upper bound of > their attack, so reducing it from 60 to 5 doesn't actually change anything > and you would need to go even lower. You could for instance do something > like only allowing it 1 time per minute, and require user approval for > higher frequencies. > > The other suggestion they have in their paper is to reduce the number of > values you return, say 4 different values. > > > Kurt > > ___ > 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: Ambient Light Sensor API
On 2017-04-25 00:04, Martin Thomson wrote: > I think that 60Hz is too high a rate for this. > > I suggest that we restrict this to top-level, foreground, and secure > contexts. Note that foreground is a necessary precondition for the > attack, so that restriction doesn't really help here. Critically, > rate limit access much more than the 60Hz recommended for the > accelerometer. 5Hz might be sufficient here, maybe even lower. Note that they already talk about 2Hz being the rate they think is realistic to do their attack, and that 5Hz is probably an upper bound of their attack, so reducing it from 60 to 5 doesn't actually change anything and you would need to go even lower. You could for instance do something like only allowing it 1 time per minute, and require user approval for higher frequencies. The other suggestion they have in their paper is to reduce the number of values you return, say 4 different values. Kurt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Future of out-of-tree spell checkers?
On Wed, Apr 19, 2017 at 4:43 AM, Ehsan Akhgari wrote: > On 2017-04-18 2:38 AM, Henri Sivonen wrote: >> On Sat, Apr 15, 2017 at 8:06 PM, Ehsan Akhgari >> wrote: >>> On 2017-03-27 3:30 AM, Henri Sivonen wrote: 2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there was a crasher bug in the library. (I'd expect the distros to take care of pushing an update in the Linux case. It's the same situation with e.g. PulseAudio and Gtk anyway.) >>> >>> It is also untrusted and unsigned code and can cause security and >>> unstability issues. We have done a lot of work to remove all such code >>> from our parent process. I don't think it's useful to make an analogy >>> between this code and things like gtk. >> >> I get it that libvoikko and gtk may (I haven't checked) have a >> different code quality level and, therefore, involve different parent >> process crash or exploitability risk. However, on e.g. Ubuntu and >> Debian the trust and signedness status is indeed the same as for gtk: >> both gtk and libvoikko are distro-provided code that is signed for >> delivery but signatures aren't checked when executing the code (i.e. >> the trust model of the OS doesn't treat root-owned libraries under >> /usr as adversarial in general) and the distro is responsible for >> pushing updates in case of critical bugs. > > Sure, but why do you keep bringing up these two distros? What about > Windows, where presumably most of Finnish and Greenlandic speaking users > will be? :-) I made the gtk/pulse comparison in the Linux context only. >> It would help me understand the issues if you could expand on your >> trust and signing concerns. > > The security issues should be obvious. I don't trust the C++ code that > I write and by extension I don't trust the C++ code that anybody else > writes. I see. I thought about "trusted" in the usual sense. I.e. code is "trusted" if it has been given the necessary privileges to mess everything up. > The stability issues: If you go to > https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=52.0.2&days=7 > right now, you will see top crashers caused by untrusted binary code > that we don't control doing bad things (I spotted #11, > js::Proxy::construct based on a cursory look right now). We have years > of concrete hard evidence in terms of 100s of crash bug reports. What's > even worse about this particular case is that due to the smaller size of > the user base, the chances of issues like crashes raising to an extent > that they become visible under our radar is slim. So the concrete risk > would be the possibility of loading this code in the parent process > causing a startup crash that flies under the radar and costs us all > users in those locales. It's unclear to me if you are arguing that Mozilla shouldn't distribute libvoikko, because it might have a crasher bug that we might not detect despite having the ability to push updates, or if you are arguing that we shouldn't load libvoikko that's present on the user's system via non-Mozilla distribution mechanism, because it might have a crasher bug that we could neither detect nor push a fix for. Either way, I still don't see how code signing would address this concern. Running spell checking in a separate process would. What problem did you mean to address by code signing? On Sat, Mar 25, 2017 at 8:48 PM, Ehsan Akhgari wrote: > Another option would be talking to the maintainers of libvoikko and > seeing if they would be open to maintaining the Mozilla bindings, in > which case I think we should even consider doing something like what we > do to download the OpenH264 binary at runtime when we need to. We could > even build and sign it in the infrastructure ourselves if we imported it > into the tree, with task cluster this is possible today with a super > simple shell script (well, at least the building side of it!). If we are willing to do the engineering for that, that would be great! (Of course, just putting libvoikko into libxul would be simpler, but would cost an added 250 KB in libxul size for everyone who doesn't need libvoikko.) >>> >>> That's not an option. 250KB for essentially dead code for most of our >>> users is too much. >> >> Annoyingly, chances are that no one will be willing to say ahead of >> time how many kilobytes would be acceptable. :-/ > > Yup. :-( If you ask the Fennec, they'll rightly say 0 though. Fortunately, this is not a Fennec-relevant issue, since spell checking is part of the input method on Android. >> As for how many users this would benefit, there's a big difference >> between the immediate and the potential. The immediate is: very few >> relative to the entire Firefox user population. There exist >> dictionaries with clear licensing for Finnish, Northern Sami, Southern >> Sami and Lule Sami and a dictionary with unclear (at least to me) >> licensing for Greenlandic. The spell
