Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote: On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Hmm, what would that prevent against though? A web page could just use the normal DOM APIs to destroy the user data (e.g., something like the contents of a blog post the user is writing in a blogging web app). Is this what you had in mind? Sorry I wasn't clear. *Both* cut and copy have the impact of *clearing* the previous clipboard data (on typical platforms). Thus if the user had say, cut a bunch of text from another application (like a text editor), and then switched to a browser window, gotten distracted and clicked something, it is *possible* the page could select text, do a cut/copy, and blow away that bunch of text from the other application. Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rust in Gecko. rust-url compatibility
Not sure that's part of the benchmarks, but creating a file:// or chrome:// URI currently causes main thread I/O (bug 890712, iirc). That's certainly a big cause of slowdown. Cheers, David On 06/05/15 04:07, Boris Zbarsky wrote: On 5/5/15 9:58 PM, Doug Turner wrote: Performance. Note that performance has been a recurring problem in our current URI code. It's a bit (10%) slower than Chrome's, but about 2x slower than Safari's, and shows up a good bit in profiles. Some of this may be due to XPCOM strings, of course, and the fact that there's a lot of back-and-forth between UTF-16 and UTF-8 involved, but some is just the way the URI parsers work. So yeah, if we can get better performance that would be nice. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Is there an e10s plan for multiple content processes?
On Wednesday, 6 May 2015 02:26:17 UTC+1, Mike Hommey wrote: Nuwa, aiui, can somewhat help here, but the possibly best option is actually to just not have a separate executable and fork() the main process (I didn't say this was going to be easy) Not having a separate executable has some other advantages for the Windows Chromium sandbox as well. Both Chrome and the Flash Player Plugin use the same executable for the sandboxed processes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 08:00, Tantek Çelik wrote: Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Given that most text-editing applications have undo (if you used cut originally), this strikes me as a low-level web page annoyance on a par with auto-playing irritating music. Although perhaps a little less discoverable as to the cause. I doubt this will be an issue in practice - as the page doesn't get to see the data its deleting, doing so would be pure vandalism, not worthy of an attacker who was trying to actually accomplish something. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
xulrunner-stub for launching app via firefox
Hi, I would like to build an XUL desktop app which can be launched with firefox -app option if firefox is installed. Else I would like to bundle a private copy of xulrunner. The problem is that windows shows the firefox icon instead of the application specific icon for my app on the taskbar if it is launched with firefox -app switch. I did get the app icon to show by copying xulrunner-stub to the same directory as firefox.exe and start the app with xulrunner-stub. But this is not a good solution as it requires that I mess with the Firefox installation directory during the app installation. Is there any easy solution to this? It would be good to have a -xuldir switch for xulrunner-stub to specify the directory of the xul runtime instead of assuming it to be in the same directory. I thought of modifying the source of xulrunner-stub but it does not build with MinGW and I just downloaded and installed 11 GB of MSVC++ community edition to try the same! Also I read about problems with running xulrunner apps on Mac with the same directory structure. Will the app work without modification if launched with firefox -app option or does it still require a different directory structure. Thanks in advance for any help. Regards, Suresh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Web Speech API Installation Build Flags
On Wednesday, May 6, 2015 at 8:00:44 AM UTC+2, Xidorn Quan wrote: On Wed, May 6, 2015 at 5:36 PM, kdavis wrote: We would like some feedback on build flags for the Web Speech API installation. More specifically, we are planning to land an initial version of the Web Speech API[1] into Geko. However, due to a number of factors, model size being one of them, we plan to introduce various build flags which install/do not install parts of the Web Speech API for various build targets. Our current plan for B2G is as follows: 1. Introduce a flag to control installation of the Web Speech API 2. Introduce a flag to control installation of Pocketsphinx[2], the STT/TTS engine. 3. Introduce a script to allow installation of models, allowing developers to test the Web Speech API (They can test once they've made a build with the previous two flags on) Our question is related to desktop and Fennec. Our current plan is to: 1. Introduce a flag to control installation of the Web Speech API + Pocketsphinx + English model[3] The question is: Is this a good plan for desktop and Fennec? Should there be more/less fine grade control for installation there? I think for desktop and fennec, some of the systems already provide APIs for TTS and STT. At least, Android has both of them [1][2], Mac also does [3]. Windows should have, but I'm not sure what form do they provide. I think for those systems, it's probably better to use their API, so that we provide the same experience as their native apps, and allow us not to include the engine ourselves. [1] https://developer.android.com/reference/android/speech/SpeechRecognizer.html [2] https://developer.android.com/reference/android/speech/tts/TextToSpeech.html [3] https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Speech/Speech.html - Xidorn I think the Web Speech API[1] serves a difference audience. It is a JavaScript API that web applications can access. In addition the web Speech API will be the same across various OS's, allowing web applications to do STT/TTS in a OS independent manner from web applications. So, the introduction of the Web Speech API does not stop people from writing native code, which they can always do. It does, however, greatly ease and standardize cross platform STT/TTS. [1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Web Speech API Installation Build Flags
On Wednesday, May 6, 2015 at 9:40:47 AM UTC+2, Xidorn Quan wrote: On Wed, May 6, 2015 at 7:24 PM, kdavis wrote: On Wednesday, May 6, 2015 at 8:00:44 AM UTC+2, Xidorn Quan wrote: On Wed, May 6, 2015 at 5:36 PM, kdavis wrote: We would like some feedback on build flags for the Web Speech API installation. More specifically, we are planning to land an initial version of the Web Speech API[1] into Geko. However, due to a number of factors, model size being one of them, we plan to introduce various build flags which install/do not install parts of the Web Speech API for various build targets. Our current plan for B2G is as follows: 1. Introduce a flag to control installation of the Web Speech API 2. Introduce a flag to control installation of Pocketsphinx[2], the STT/TTS engine. 3. Introduce a script to allow installation of models, allowing developers to test the Web Speech API (They can test once they've made a build with the previous two flags on) Our question is related to desktop and Fennec. Our current plan is to: 1. Introduce a flag to control installation of the Web Speech API + Pocketsphinx + English model[3] The question is: Is this a good plan for desktop and Fennec? Should there be more/less fine grade control for installation there? I think for desktop and fennec, some of the systems already provide APIs for TTS and STT. At least, Android has both of them [1][2], Mac also does [3]. Windows should have, but I'm not sure what form do they provide. I think for those systems, it's probably better to use their API, so that we provide the same experience as their native apps, and allow us not to include the engine ourselves. I think the Web Speech API[1] serves a difference audience. It is a JavaScript API that web applications can access. In addition the web Speech API will be the same across various OS's, allowing web applications to do STT/TTS in a OS independent manner from web applications. So, the introduction of the Web Speech API does not stop people from writing native code, which they can always do. It does, however, greatly ease and standardize cross platform STT/TTS. I meant, we do not need to include the speech engines in Firefox. We just need adaptors to use those system APIs, instead of Pocketsphinx, to provide the speech service for web applications. That way, we can provide the feature as powerful as what the systems have already provided. e.g. OS X currently supports TTS for tens of languages, and STT for around ten languages. - Xidorn I don't think your approach is excluded. In fact it is encouraged. The Web Speech API can support more than one backend at a time and in future we will add other backends, likely including the native backends you mentioned. However, as a first step we want to use only Pocketsphinx. (This simplifies the initial task of implementation as we can concentrate on a single backend.) Later we will add other STT/TTS backends which will likely include the various native backends you mentioned. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Web Speech API Installation Build Flags
On Wed, May 6, 2015 at 5:36 PM, kda...@mozilla.com wrote: We would like some feedback on build flags for the Web Speech API installation. More specifically, we are planning to land an initial version of the Web Speech API[1] into Geko. However, due to a number of factors, model size being one of them, we plan to introduce various build flags which install/do not install parts of the Web Speech API for various build targets. Our current plan for B2G is as follows: 1. Introduce a flag to control installation of the Web Speech API 2. Introduce a flag to control installation of Pocketsphinx[2], the STT/TTS engine. 3. Introduce a script to allow installation of models, allowing developers to test the Web Speech API (They can test once they've made a build with the previous two flags on) Our question is related to desktop and Fennec. Our current plan is to: 1. Introduce a flag to control installation of the Web Speech API + Pocketsphinx + English model[3] The question is: Is this a good plan for desktop and Fennec? Should there be more/less fine grade control for installation there? I think for desktop and fennec, some of the systems already provide APIs for TTS and STT. At least, Android has both of them [1][2], Mac also does [3]. Windows should have, but I'm not sure what form do they provide. I think for those systems, it's probably better to use their API, so that we provide the same experience as their native apps, and allow us not to include the engine ourselves. [1] https://developer.android.com/reference/android/speech/SpeechRecognizer.html [2] https://developer.android.com/reference/android/speech/tts/TextToSpeech.html [3] https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Speech/Speech.html - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
It's absolutely true for hosting yourself today. The only thing even slightly difficult is setting up dynamic dns. On Mon, May 4, 2015, at 06:01 AM, Gervase Markham wrote: On 01/05/15 19:02, Matthew Phillips wrote: You must have missed my original email: It's paramount that the web remain a frictionless place where creating a website is dead simple. That is not true today of people who want to run their own hosting. So people who want frictionless use blogspot.com, or one of the thousands of equivalent sites in many different jurisdictions, to say what they want to say. In an HTTPS future, such sites would simply provide HTTPS for their users. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wed, May 6, 2015 at 2:04 PM, Matthew Phillips matt...@matthewphillips.info wrote: It's absolutely true for hosting yourself today. The only thing even slightly difficult is setting up dynamic dns. And in a future where certificates are issued without cost over a protocol there's no reason setting up a secure server yourself will be difficult. HTTP will not disappear overnight and we'll have plenty of times to get all the moving pieces in order to make this great and overall a better web for end users. (Who will have less impossible trust decisions to endure.) -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Minor changes to mochitest harness and mach command arguments
As part of a cleanup of the mochitest harness and the mochitest mach command, the following arguments have changed in the harness (behaviour should be unchanged when running from mach): 1) --autorun is now the default so this option has been removed. Use --no-autorun to turn it off. 2) --close-when-done is now the default, so this option has been removed. Use --keep-open to turn it off. 3) --console-level now defaults to INFO, so no need to specify it manually. In addition, the mach command now uses the same set of arguments as the mochitest harness. All arguments are now defined in mochitest_options.py: https://hg.mozilla.org/mozilla-central/file/tip/testing/mochitest/mochitest_options.py S ome arguments have a suppress: True value. This means that they will be hidden from --help, as they are things that an average developer shouldn't need to worry about (i.e the defaults should be good for most cases). However it is still possible to pass in these arguments for more advanced use cases or from automation if necessary. There are future planned changes to the mochitest mach commands. All of the various mochitest commands will be rolled into a single point of entry. E.g instead of: ./mach mochitest-browser You'd run: ./mach mochitest -f browser This is all part of an effort to simplify the process of running tests, and to unify both the local and automation entry points to the harness. If you have any questions or concerns, please let me know. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Minor changes to mochitest harness and mach command arguments
On 06/05/2015 14:33, Andrew Halberstadt wrote: 2) --close-when-done is now the default, so this option has been removed. Use --keep-open to turn it off. It was a pain to get this right for people's expectations when I messed with this - mochitest-browser and mochitest-plain behave differently. Has that difference been preserved when running from mach? You'd run: ../mach mochitest -f browser What does -f mean here and why would I want to change from mochitest-browser to the longer mochitest -f browser ? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 10:51 AM, Gervase Markham g...@mozilla.org wrote: On 06/05/15 08:00, Tantek Çelik wrote: Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Given that most text-editing applications have undo (if you used cut originally), ^^^ desktop assumption. Most (nearly all?) text editing applications and/or applications with editable text fields on *mobile* DO NOT have undo. this strikes me as a low-level web page annoyance on a par with auto-playing irritating music. ^^^ disagreed - no data loss with auto-playing irritating music, just potential embarrassment / emotional annoyance. Although perhaps a little less discoverable as to the cause. Very. Also the silent nature of this vulnerability means user might not notice until long after damage is done. I doubt this will be an issue in practice Perhaps. I might conclude similarly, yet I thought this was worth raising as possible justification for enabling only in secure connections. Also this is a good concrete test-case of our blog post and indication of direction re: features and secured connections. - as the page doesn't get to see the data its deleting, doing so would be pure vandalism, not worthy of an attacker who was trying to actually accomplish something. Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Minor changes to mochitest harness and mach command arguments
On 06/05/2015 15:14, Andrew Halberstadt wrote: Yeah, you shouldn't notice any difference when running from mach. The only change is that the harness is handling defaults instead of the mach command, and that they now both have the same command line. I think what you are thinking of is when you run a single test. In that case --keep-open is set for plain, but not browser. I'm not really sure why that's the case, but the behaviour was preserved. Great! What does -f mean here and why would I want to change from mochitest-browser to the longer mochitest -f browser ? -f is --flavor. When running a single flavor there's not really any benefit to using one vs the other. It just seems redundant to have N commands when 1 is enough, but if there is widespread opposition to removing mochitest-flavor it's not a huge deal to keep them. Do I need to pass flavor? What would happen if I do: ./mach mochitest path/to/dir/with/only/mochitest-browser/things -- would that just work ? I mean, I thought that the original plan was for everybody to just use: ./mach test path/to/test except it doesn't support half as many options as the actual test suites (--start-at, --end-at, --jsdebugger, to name a few), so (for me personally...) it's near enough useless in practice. I'm all for simplifying the (mach) commands to run, as long as it doesn't come with the cost of losing hard-won debugging options. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Minor changes to mochitest harness and mach command arguments
On 06/05/15 09:59 AM, Gijs Kruitbosch wrote: On 06/05/2015 14:33, Andrew Halberstadt wrote: 2) --close-when-done is now the default, so this option has been removed. Use --keep-open to turn it off. It was a pain to get this right for people's expectations when I messed with this - mochitest-browser and mochitest-plain behave differently. Has that difference been preserved when running from mach? Yeah, you shouldn't notice any difference when running from mach. The only change is that the harness is handling defaults instead of the mach command, and that they now both have the same command line. I think what you are thinking of is when you run a single test. In that case --keep-open is set for plain, but not browser. I'm not really sure why that's the case, but the behaviour was preserved. What does -f mean here and why would I want to change from mochitest-browser to the longer mochitest -f browser ? -f is --flavor. When running a single flavor there's not really any benefit to using one vs the other. It just seems redundant to have N commands when 1 is enough, but if there is widespread opposition to removing mochitest-flavor it's not a huge deal to keep them. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. Though I can understand why there might be some resistance, we don't find out much if we don't ask. I'm going to propose that we at least raise the question with other browsers about restricting this feature to secure contexts. The answer might help inform us on whether pursuing the deprecation plan as outlined is feasible. Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. It would be a shame if the deprecation plan was spoiled simply because features that were considered too useful got exemptions. In this case, I'd say timing would be a valid reason for an exemption. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. I think this is the strongest argument for doing this. Though I can understand why there might be some resistance, we don't find out much if we don't ask. Precisely. The upside: we try out aspects of our proposed policy with very little risk. The possible downside: we get negative feedback from developers, and end up delaying the broader support (whether http or other fewer restrictions) by one release. Given how long people have already waited for this, is this potential delay really that harmful? Especially in exchange for the upside. I'm going to propose that we at least raise the question with other browsers about restricting this feature to secure contexts. This is a reasonable next step. The answer might help inform us on whether pursuing the deprecation plan as outlined is feasible. Exactly, we get to start trying out parts of the plan at relatively low risk. Like a drill of sorts. Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. Based on the arguments presented in this thread, I have been convinced of this too (tangible but small). Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Web Speech API Installation Build Flags
On Tue, May 5, 2015 at 10:36 PM, kda...@mozilla.com wrote: We would like some feedback on build flags for the Web Speech API installation. More specifically, we are planning to land an initial version of the Web Speech API[1] into Geko. However, due to a number of factors, model size being one of them, we plan to introduce various build flags which install/do not install parts of the Web Speech API for various build targets. Our current plan for B2G is as follows: 1. Introduce a flag to control installation of the Web Speech API 2. Introduce a flag to control installation of Pocketsphinx[2], the STT/TTS engine. 3. Introduce a script to allow installation of models, allowing developers to test the Web Speech API (They can test once they've made a build with the previous two flags on) Our question is related to desktop and Fennec. Our current plan is to: 1. Introduce a flag to control installation of the Web Speech API + Pocketsphinx + English model[3] For Fennec, that's about right -- a build flag should control building and shipping all (or parts) of this, and a Gecko pref controls enabling the feature (exposing it to web content). There are numerous examples, and see [1] and [2] for Fennec specific notes. Fennec is extremely concerned about its APK size and is very unlikely to ship the large model files that the Web Speech API relied on many moons ago when I looked at it. I encourage you to f? me and mfinkle on Fennec build patches, and to pursue Fennec-specific discussion on mobile-firefox-dev. Nick [1] http://www.ncalexander.net/blog/2014/07/09/how-to-land-a-fennec-feature-behind-a-build-flag/ [2] http://www.ncalexander.net/blog/2015/02/13/how-to-update-and-test-fennec-feature-build-flags/ The question is: Is this a good plan for desktop and Fennec? Should there be more/less fine grade control for installation there? [1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html [2] http://cmusphinx.sourceforge.net/ [3] Initially we will work only with English and introduce a mechanism to install other models later. ___ 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 and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote: Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Note that we're changing that: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. I like this idea. Although I wonder if users will understand what is happening. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rust in Gecko. rust-url compatibility
On Tue, May 5, 2015 at 7:10 PM, Valentin Gosu valentin.g...@gmail.com wrote: On 6 May 2015 at 04:58, Doug Turner do...@mozilla.com wrote: On May 5, 2015, at 12:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com wrote: As some of you may know, Rust is approaching its 1.0 release in a couple of weeks. One of the major goals for Rust is using a rust library in Gecko. The specific one I'm working at the moment is adding rust-url as a safer alternative to nsStandardURL. Will this affect our ability to make nsStandardURL thread-safe? Unfortunatelly this project does not make nsStandardURL thread safe. Sorry, I think you misunderstand my question. I definitely don't suggest that you should do *anything* to improve the threadsafetyness of nsStandardURL as part of using Rust to implement it. I.e. I'm not asking you to add threadsafe addref/release, improve any addon APIs, remove the nsIURI mutators, or do any of the other things that are needed to make it possible to use nsStandardURL off the main thread. What I'm asking is that when *someone else* has fixed the various issues that currently prevent us from using nsStandardURL off the main thread, will the fact that nsStandardURL is implemented in Rust make it troublesome for us to use nsStandardURL from multiple threads? Or can the Rust code be called from multiple threads simultaneously without causing race issues? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 13:32, Jonas Sicking wrote: Like Ehsan, I don't see what advantages limiting this to https brings? In some ways, that depends on what we decide to define new features to mean, and the release date of this feature relative to the date we settle on in the announced security plan [1] of Setting a date after which all new features will be available only to secure websites. If we use the example definition of new features to mean features that cannot be polyfilled, then this would qualify. Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. [1] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 3:00 AM, Tantek Çelik wrote: On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik tan...@cs.stanford.edu wrote: On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 6:31 PM, Daniel Holbert wrote: On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. First, this is awesome and can't wait to try it out. Second, cut is potentially destructive to user data, have you considered enabling this only for secure connections? Either way it would be good to know the reasoning behind your decision. Hmm, what would that prevent against though? A web page could just use the normal DOM APIs to destroy the user data (e.g., something like the contents of a blog post the user is writing in a blogging web app). Is this what you had in mind? Sorry I wasn't clear. *Both* cut and copy have the impact of *clearing* the previous clipboard data (on typical platforms). Thus if the user had say, cut a bunch of text from another application (like a text editor), and then switched to a browser window, gotten distracted and clicked something, it is *possible* the page could select text, do a cut/copy, and blow away that bunch of text from the other application. Result: loss of user data that user had put into the clipboard previously. This isn't possible with current DOM APIs and is a new vulnerability introduced by cut/copy. Thanks for the clarification! I have actually already considered this, and I don't think this is a problem that we need to deal with, at least until we have some evidence that it is an actual problem in the wild. Two points to note here: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. Let's look at some of the suggestions in this thread: * Directly promoting the user is a horrible user experience, and given that it is practically impossible to describe what we're asking for them (many users may not even know what a clipboard is, since it has never been exposed in a user-facing way in any OS that I've seen at least), and also because it could be an annoying and pointless question to ask: Would you like website X to be able to copy text so that you can paste it elsewhere? Why would I not want to allow that? Where is the Whatever Button?. :-) * Having a permissions for this is a similarly horrible user experience for similar reasons to prompting, except that we show the permission UI at different times than the prompt UI. Also, if the permission is granted by default, this does very little to protect any of our users anyway. * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. * It may be argued that this attack has not been possible through Web APIs so far, so we should now do something about it now that the implementation is moving from Flash to the browser engine. I think that's a very theoretical view of the world, and is quite insufficient if we believe that this is a real issue worth addressing. Also, a variation of this attack has been possible through the clipboard events on the Web without Flash for a while now. For example, if you press your mouse cursor in a text area and without selecting anything, press Cmd+C, you would typically expect for the contents of the clipboard to remain unchanged. It is possible for a web app to put arbitrary data on the clipboard in that case (and again, with this feature, we have seen no evidence of abuse in the wild so far.) * At least on desktop where Flash is widely available, the real value of this API is giving people a good incentive to move away from using Flash. If the Web alternative is an API that doesn't work in some cases (be it because the user said no to a prompt, disabled a permission, or if the web page is served from a non-secure origin), people will keep using Flash for this, and that eliminates most of the
Re: Announcing Operation Instrument
Markers are only emitted when the docshell is in a recording state Console markers: https://github.com/mozilla/gecko-dev/blob/6e929ef81c0807a969f9064449736f6b92966e12/dom/base/Console.cpp#L1109 TimelineActor enabling recording: https://github.com/mozilla/gecko-dev/blob/6e929ef81c0807a969f9064449736f6b92966e12/toolkit/devtools/server/actors/timeline.js#L265 On Wed, May 6, 2015 at 10:04 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: Is this supposed to be on at all times? If so, we need to connect this somehow with slow add-on detection. Cheers, David ___ dev-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 1:08 PM, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. Sure, but this argument doesn't really work in the present tense where Flash has actually not gone away, and is _the_ standard way for copying text to the clipboard. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:36, Tom Schuster wrote: I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. Which is why we wouldn't overwrite the clipboard until the permission was granted :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 13:13, Gervase Markham wrote: On 06/05/15 18:36, Tom Schuster wrote: I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. Which is why we wouldn't overwrite the clipboard until the permission was granted :-) Well, that makes it scantly better than a doorhanger, which is what Martin was objecting to (and I agree with him). The model that we really want here is this thing happened, click here to undo it rather than this think is about to happen, but won't unless you take additional action. I think this position is pretty strongly bolstered by Dave Graham's message about GitHub behavior: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. Basically, requiring the extra step of requiring the user to click on an okay, do it button is high enough friction that the function loses its value. In any case, we should have a better technical exploration of the assertion that restoring a clipboard isn't possible in all cases before we take it as given. A cursory examination of the OS X clipboard API leads me to believe that this would be trivially possible (I believe we can just store the array of pasteboardItems from the NSGeneralPBoard off somewhere so that they can be moved back if necessary). I'd be a little surprised if this weren't also true for Linux and Windows. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hey David, On 5/6/15 13:09, dgra...@github.com wrote: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet. Thanks for mentioning this--I suspect other sites would also fall back to Flash if our UX is similarly annoying. Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated. You can use the document.queryCommandSupported()[1] or document.queryCommandEnabled()[2] APIs to check for support. [1] https://developer.mozilla.org/en-US/docs/Web/API/Document/queryCommandSupported [2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 19:38, Adam Roach wrote: action. I think this position is pretty strongly bolstered by Dave Graham's message about GitHub behavior: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. Is that popup one time only per site, or every time? Basically, requiring the extra step of requiring the user to click on an okay, do it button is high enough friction that the function loses its value. Yeah, I can see that. OK. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote: Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Hi Tantek, This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? If news/media websites are likely to use the clipboard as an ad space, why aren't we seeing that happening now? Remember that this is already possible using flash. But to my knowledge this is not a big problem on the web today. Even on websites that already take the performance hit of initiating the flash plugin. Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config about:config, privacy.trackingprotection.enabled). I definitely think it'd be cool if we had tracking-protection like mechanisms to auto-block various APIs on websites that are bad actors. For example it'd be cool to completely disable the ability to open popups, even from user actions, on websites that use other user interactions as an opportunity to create popups. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. We also need to make a browser that people want to use. This means not regressing the UX compared to what came before, or being markedly worse than other browsers. Adding prompt/permissions UI in this case seems like it is just going to be yet another papercut that will annoy more people than will be pleased because we prevent some rogue website having an unwanted interaction with the clipboard. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rust in Gecko. rust-url compatibility
On 01/05/15 00:42, Jet Villegas wrote: I wonder why we'd allow *any* parsing differences here? If we're also signing up to increase spec compliance as part of the rewrite, that should be called out as an explicit goal rust-url (https://github.com/servo/rust-url/) was originally written per the URL standard (https://url.spec.whatwg.org/) for Servo and the rest of the Rust ecosystem (replacing a something that was at the time part of the Rust standard library). The idea to use it in Gecko only came up recently. Where rust-url diverges from Gecko’s currently behavior, I’d rather consider case by case which should be changed (including possibly changing the spec) rather than systematically align with what Gecko happens to be doing. On 01/05/15 19:58, Gregory Szorc wrote: Shipping *any* Rust component as part of Gecko is already going to be a long and arduous task. I think it makes sense for the first Rust component in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat scope to include behavior changes that could jeopardize the deliverable. All true. It would be really unfortunate if we did all this Rust preparation work only to have the feature utilizing it backed out because of behavior differences. I expect Rust support in the build system to land separately from any code that uses it: https://bugzilla.mozilla.org/show_bug.cgi?id=oxidation But this is a very high-level observation. I know others spent a lot of time figuring out what to Rust-ify first and URL parsing was eventually chosen. If you say it is the least risky part of Gecko to swap out, I trust that assessment. URL parsing will not necessarily be the first Rust component to land. There is also work going on on MP4 parsing (https://bugzilla.mozilla.org/show_bug.cgi?id=1161350), and we’ve discussed BMP decoding as a low-risk component. On 05/05/15 21:55, Jonas Sicking wrote: Will this affect our ability to make nsStandardURL thread-safe? I don’t know of any thread safety issue in rust-url. It’s only doing string manipulation. On 06/05/15 04:07, Boris Zbarsky wrote: Note that performance has been a recurring problem in our current URI code. It's a bit (10%) slower than Chrome's, but about 2x slower than Safari's, and shows up a good bit in profiles. I haven’t looked into rust-url’s performance at all. This means two things: it’s probably not great right now, but it can probably be improved. For example, the Url struct currently contains a vector of strings for the path and a some more strings for other URL components. Each (non-empty) string is a memory allocation. It would probably be more efficient to have a single string with some indices delimiting the components. Some of this may be due to XPCOM strings, of course, and the fact that there's a lot of back-and-forth between UTF-16 and UTF-8 involved, but some is just the way the URI parsers work. rust-url uses the String type from the Rust standard library, which is based on UTF-8. If conversions to/from UTF-16 turn out to take significant time I could imagine making the parsing code generic over the string representation. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing Operation Instrument
Is this supposed to be on at all times? If so, we need to connect this somehow with slow add-on detection. Cheers, David signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:49, Martin Thomson wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turnerdo...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this toabout:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way: https://www.dropbox.com/s/c0sbknrlz4pbybk/Screenshot%202015-05-06%2011.33.42.png?dl=0 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:02 AM, Ehsan Akhgari wrote: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. Well... Did Flash offer sites a way to to this without user interaction? I don't know for sure, but I assumed it had to be invoked by a user action... I remember a couple of popular URL shortener sites using Flash for this, and they always required a conspicuously-extra click on a copy to clipboard button. (Entering full-screen had the same requirement too, IIRC.) I think the web sites do have an incentive to not annoy users claim is dubious too. Some sites certainly do, but we still see widespread annoyance/abuse of features like popups, onbeforeunload traps, playing unexpected audio in background tabs. And some legit sites (eg wendys.com / t-mobile.com) kind of abuse geolocation by prompting for it on every page upon page load. This isn't such a severe problem that we have to completely solve it right away, but I'd hate to see us painted into a corner where we have no options for mitigating abuse or giving our users control. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. One off-the-cuff thought would be to place some reasonable restrictions on the usage (tab must be in foreground, maybe in response to a user interaction), and perhaps provide some (fairly subtle) UI indication of when it's invoked. That at least gives the user a chance to see a clearer cause/effect. Or, along the vein of retroactively revoking permissions -- just keeping a usage log somewhere. That at least enables motivated/SUMO users to be able to discover what site is causing the problem, and then either revoke it off or stop going there. Seems like kind of an interesting idea that would scale to other seldomly-abused permissions... Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 10:49, Martin Thomson wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
This is great news! At GitHub, we have support in place for this feature in Chrome already. If you use a Canary build to visit the site, the copy buttons use the native JS `execCommand('copy')` API rather than Flash. Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet. Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated. It's exciting to see native copy-to-clipboard coming to Firefox. We'll follow along in Bugzilla and enable it on github.com when it's ready! David On Tuesday, May 5, 2015 at 3:52:45 PM UTC-6, Ehsan Akhgari wrote: Summary: We currently disallow programmatic copying and cutting from JS for Web content, which has relied on web sites to rely on Flash in order to copy content to the clipboard. We are planning to relax this restriction to allow this when execCommand is called in response to a user event. This restriction mimics what we do for other APIs, such as FullScreen. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012662 Link to standard: This is unfortunately not specified very precisely. There is a rough spec here: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands and the handling of clipboard events is specified here: https://w3c.github.io/clipboard-apis/. Sadly, the editing spec is not actively edited. We will strive for cross browser interoperability, of course. Platform coverage: All platforms. Target release: Firefox 40. Preference behind which this will be implemented: This won't be hidden behind a preference, as the code changes required are not big, and can be easily reverted. DevTools bug: N/A Do other browser engines implement this: IE 10 and Chrome 43 both implement this. Opera has adopted this from Blink as of version 29. Security Privacy Concerns: We have discussed this rather extensively before: http://bit.ly/1zynBg7, and have decided that restricting these functions to only work in response to user events is enough to prevent abuse here. Note that we are not going to enable the paste command which would give applications access to the contents of the clipboard. Web designer / developer use-cases: This feature has been rather popular among web sites. Sites such as Github currently use Flash in order to allow people to copy text to the clipboard by clicking a button in their UI. Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hi Tantek, On 5/6/15 10:59, Tantek Çelik wrote: Since we have no legacy to deal with, we can start conservative, and wait for web developer feedback, and iterate accordingly. We're behind IE10 and Chrome 43 in implementing this feature [1], so at some level there will be existing content we need to deal with. Interoperability with how they behave would be a win. Ideally, whatever we do to protect our users can make it back to Hallvord to spec and other implementers to match, otherwise Flash-for-clipboard-access won't be going anywhere. [1] http://updates.html5rocks.com/2015/04/cut-and-copy-commands -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
I think the ribbon would be really useful if it allowed the user to restore the previous clipboard content. However this is probably not possible for all data that can be stored in clipboards, i.e. files. On Wed, May 6, 2015 at 7:33 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote: Going fullscreen also gives the user UI at the time of activation, allowing them to manipulate permissions in an obvious way. Note that we're changing that: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 Perhaps an analogous yellow ribbon informing the user that the site has copied data onto their clipboard, with buttons to allow them to prevent it from happening in the future, would be a good balance (in particular if denying permission restored the clipboard to its previous state) -- it informs the user and provides clear recourse without *requiring* additional action. I like this idea. Although I wonder if users will understand what is happening. -- 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
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 06/05/15 18:22, James Graham wrote: On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily get a certificate and perform the same annoying operation), and a potential network attacker MITMing your connection can inject a tiny Flash object and script it. It will be a few more lines of code for the attacker to write, and they would get a pretty solid attack for the majority of desktop users, at least. Flash will go away (to the extent it hasn't already on mobile), this feature won't. We should offer better security than what came before. We also need to make a browser that people want to use. This means not regressing the UX compared to what came before, or being markedly worse than other browsers. Adding prompt/permissions UI in this case seems like it is just going to be yet another papercut that will annoy more people than will be pleased because we prevent some rogue website having an unwanted interaction with the clipboard. Oh, sorry, this is about https. On desktop sites will just use flash rather than https. On mobile they are at least as likely to not support clipboard operations in Firefox as switch to https. Again, users will just get the impression that Firefox is a slightly worse browser, for relatively little gain. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Gervase Markham wrote: For this edge case, I would say the solution is to use a proxy, run on one of your other (faster) computers. As noted elsewhere, that's what jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again. That's a reasonable solution for one-offs, but not really viable if you have a bunch of hobbyists who don't necessarily have the technical background to deal with that. Even I don't know how to set up a proxy like that. I'm sure it wouldn't take me long to learn, but I certainly can't expect all the people who use programs I write to know how to do it. I get, of course, that this is the way of progress. Just... would have been nice to have more notice, since we're going to have to try to find someone to build, produce, and market a simple, plug-and-play mechanism to handle encryption and decryption of data in order to keep these hobby machines online over the long term. Will make for a fun project for someone, but will take time. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 6:48 PM, Tantek Çelik wrote: On Thu, May 7, 2015 at 12:08 AM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote: Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. This is perhaps a little early to be applying that rule, since we haven't really gotten far with the discussion with other browser vendors yet (though we've had some preliminary discussions). I think that this is a great example of a feature that we could use to test out the process for applying the policy. I think this is the strongest argument for doing this. FWIW I don't really understand why this question turned into us looking for projects as a test bed for the HTTP deprecation plans. I still don't think you've demonstrated why this is a problem in practice, and why restricting this API to TLS and leaving the possibility to leverage Flash to *literally* achieve the same result on HTTP is an improvement. Though I can understand why there might be some resistance, we don't find out much if we don't ask. Precisely. The upside: we try out aspects of our proposed policy with very little risk. The possible downside: we get negative feedback from developers, and end up delaying the broader support (whether http or other fewer restrictions) by one release. Given how long people have already waited for this, is this potential delay really that harmful? Especially in exchange for the upside. What is it that you're actually proposing? I double read this thread right now and I can't find a mention of a delay period. And what problem are we solving again? Like Anne, I think that the benefit is tangible to HTTPS-only, even it is small. Based on the arguments presented in this thread, I have been convinced of this too (tangible but small). What is the argument that convinced you? Protecting against someone MITMing the connection of users who do not have Flash enabled to get them to click somewhere on the page to copy something to the clipboard? (I'm genuinely trying to understand what we're getting out of this.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 5/4/15 3:03 AM, Gervase Markham wrote: On 01/05/15 20:40, Eric Shepherd wrote: In my case, the situation is that I have classic computers running 1-10 megahertz processors, for which encrypting and decrypting SSL is not a plausible option. For this edge case, I would say the solution is to use a proxy, run on one of your other (faster) computers. As noted elsewhere, that's what jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again. That sort of defeats the purpose of the exercise, but since we've already been tarred as not right in the head ... So, Gopher then. Cameron Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 1:40 PM, Justin Dolske wrote: On 5/6/15 10:02 AM, Ehsan Akhgari wrote: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do this. Web sites do have an incentive to not annoy users, and we have seen how they have largely stopped doing annoying things such as blocking the context menu in the past. Well... Did Flash offer sites a way to to this without user interaction? No, and as I said in the first email of this thread, neither are we. I think the web sites do have an incentive to not annoy users claim is dubious too. Some sites certainly do, but we still see widespread annoyance/abuse of features like popups, onbeforeunload traps, playing unexpected audio in background tabs. And some legit sites (eg wendys.com / t-mobile.com) kind of abuse geolocation by prompting for it on every page upon page load. I never said that there are no websites that do annoying things. I did say that they have an incentive to not annoy the user, because they typically want the user to spend as much time on their website as possible. Perhaps this is anecdotal, but I don't see examples of the above abuses on the majority of websites that I visit. Also, in this case I can safely make a stringer claim, because there has been years of experience with an equivalent API. This isn't such a severe problem that we have to completely solve it right away, but I'd hate to see us painted into a corner where we have no options for mitigating abuse or giving our users control. As I said in the email that you're replying to, this will actually not paint us into a corner. We can always revisit this decision. Websites will need to have fallbacks for older browsers for a while, and I don't know if Safari plans to implement this yet. 2. Even if we decided that this is a serious issue that we need to solve, there is no good solution here. One off-the-cuff thought would be to place some reasonable restrictions on the usage (tab must be in foreground, maybe in response to a user interaction), and perhaps provide some (fairly subtle) UI indication of when it's invoked. That at least gives the user a chance to see a clearer cause/effect. Please read the original email of the thread again. Perhaps I was not clear enough. This API is going to be restricted to code that runs in response to a user event (which means by definition it is restricted to the foreground tab as well). I don't think we shoiuld show a UI indication because a) such an indication does not exist in any other app and b) it is not clear to me what the user is supposed to do with such an indication. Or, along the vein of retroactively revoking permissions -- just keeping a usage log somewhere. That at least enables motivated/SUMO users to be able to discover what site is causing the problem, and then either revoke it off or stop going there. Seems like kind of an interesting idea that would scale to other seldomly-abused permissions... Before we even begin to think about measures such as this, I would like to see some evidence that this is a problem _in practice_. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 5/6/15 20:32, Ehsan Akhgari wrote: If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. I admit that I didn't real the entire HTTP deprecation plan thread because of the length and the tone of some of the participants, so perhaps I missed this, but reading https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ seems to suggest that there is going to be a date and criteria for what new features mean, but I see no mention of what that date is, or what the definition of new features is. That's why there were two predicates qualifying the statement. My point is that the answer to Jonas' question may -- and I'll emphasize may -- turn on an overarching strategic security policy, rather than the security properties of the feature itself. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 2:55 PM, Adam Roach wrote: On 5/6/15 13:32, Jonas Sicking wrote: Like Ehsan, I don't see what advantages limiting this to https brings? In some ways, that depends on what we decide to define new features to mean, and the release date of this feature relative to the date we settle on in the announced security plan [1] of Setting a date after which all new features will be available only to secure websites. If we use the example definition of new features to mean features that cannot be polyfilled, then this would qualify. Keep in mind the thesis of that plan isn't that we restrict security-sensitive features to https -- it's that /all new stuff/ is restricted to https. If this falls under the definition of a new feature, and if it's going to be released after the embargo date, then the security properties of clipboard manipulation don't really enter into the evaluation. I admit that I didn't real the entire HTTP deprecation plan thread because of the length and the tone of some of the participants, so perhaps I missed this, but reading https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ seems to suggest that there is going to be a date and criteria for what new features mean, but I see no mention of what that date is, or what the definition of new features is. So before we come up with a plan for that, I think the security properties of clipboard manipulation are exactly what we need to take into consideration here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On 2015-05-06 2:51 PM, Mike Taylor wrote: Hey David, On 5/6/15 13:09, dgra...@github.com wrote: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet. Thanks for mentioning this--I suspect other sites would also fall back to Flash if our UX is similarly annoying. Thanks David, this is really helpful. I also agree that showing UI for this feature decreases the usability to a degree that the Flash alternative may be preferred. Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated. You can use the document.queryCommandSupported()[1] or document.queryCommandEnabled()[2] APIs to check for support. So technically queryCommandSupported is the right way to feature detect this. Note that currently our implementation of queryCommandSupported is buggy and it returns true for all of the command names that we know of, including cut, copy and paste. Over in https://bugzilla.mozilla.org/show_bug.cgi?id=1161721, we'll fix our implementation so that we return true for cut and copy and false for paste. So in Firefox, you'd be able to feature detect like this: function isSupported() { return document.queryCommandSupported(copy) !document.queryCommandSupported(paste); } Chrome's implementation of this function is affected by https://code.google.com/p/chromium/issues/detail?id=476508, but it seems like it is getting fixed. I have not tested IE's implementation of queryCommandSuported yet. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rust in Gecko. rust-url compatibility
On 5/6/15 4:28 AM, David Rajchenbach-Teller wrote: Not sure that's part of the benchmarks, but creating a file:// or chrome:// URI currently causes main thread I/O (bug 890712, iirc). My measurements were on http:// URIs. And yes, others are even slower because of the protocol handler details (e.g. newURI(about:blank) is much slower than newURI(http://foo;) because of the way we handle security stuff for about: URIs). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Minor changes to mochitest harness and mach command arguments
On 06/05/15 10:24 AM, Gijs Kruitbosch wrote: Do I need to pass flavor? What would happen if I do: ./mach mochitest path/to/dir/with/only/mochitest-browser/things -- would that just work ? Yep that should just work. Fyi, |mach mochitest| already exists, so you can do this now if you want. Without --flavor it will detect all flavors in the subdir you specify (or topsrcdir if none specified) and run each flavor one after the other. The -f is only needed if more than one flavor of test exists in the directory and you want to restrict the run to a single flavor. I mean, I thought that the original plan was for everybody to just use: ./mach test path/to/test except it doesn't support half as many options as the actual test suites (--start-at, --end-at, --jsdebugger, to name a few), so (for me personally...) it's near enough useless in practice. That's still the plan, but I don't think we'll ever be able to completely remove the suite specific mach commands because as you mentioned the command lines for the harnesses are just too different. In this case however, we can remove the mochitest-flavor specific commands without losing any arguments. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On May 6, 2015, at 7:30 AM, Tantek Çelik tan...@cs.stanford.edu wrote: Not pure vandalism. The user data loss is a side-effect of other incentives. E.g. trivial attacker incentive: all those share-button-happy news/media sites are likely to auto-copy URL + title of an article you're reading when you do any user interaction with the article, in the hopes that maybe you might paste the URL into an IM or email etc. and send them some more traffic (given how much they annoyingly sacrifice performance and page load/scroll speed with all their like/+1/share/addthis etc. buttons, I see no reason to expect any different behavior with this feature). Hi Tantek, This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config about:config, privacy.trackingprotection.enabled). Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: No more binary components in extensions
One thing I should point out is that binary components in B2G are NOT user installable. Instead, binaries components are used by companies building FirefoxOS devices. For example, Qualcomm has some special implementation for Geolocation and the radio interface layer (RIL). When a company wants to build a FirefoxOS device on Qualcomm hardware, Qualcomm hands them a bunch of binaries. These binaries obviously aren’t compiled into LIBXUL and thus we need XPCOM to continue looking for and loading binary components. I hope this helps. On May 5, 2015, at 9:19 AM, Benjamin Smedberg benja...@smedbergs.us wrote: B2G has asked that binary component support be restored for distribution/bundles only, and that is being done in bug 1161212. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote: A doorhanger seems like overkill here. Making this conditional on an engagement gesture seems about right. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. The worry was about your clipboard getting spammed, but I agree. HTTPS does make sense so at least the network cannot get to your clipboard. Ask forgiveness, not permission seems about the right balance here. If we can find a way to revoke permission for a site that abuses the privilege, that's better. (Adding this to about:permissions with a default on state seems about right, which leads me to think that we need the same for the fullscreen thing.) This I like a lot too, provided about:permissions moves into about:preferences and gets a redesign... One can dream. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
On Wed, May 6, 2015 at 5:49 PM, Martin Thomson m...@mozilla.com wrote: On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote: This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, Thanks Doug. I think your first two suggestions are an excellent start. Since we have no legacy to deal with, we can start conservative, and wait for web developer feedback, and iterate accordingly. Thus, straw proposal, let's use your first two: * mitigate by requiring https * only allowing the top level document access these clipboard apis And then if developers complain about either of these restrictions in practice, then hopefully they'll come with specific use-cases for us to consider. and doorhangering the API. Thoughts? A doorhanger seems like overkill here. Agreed. Making this conditional on an engagement gesture seems about right. Agreed on that too. I don't believe that we should be worry about surfing - and interacting with - strange sites while there is something precious on the clipboard. Having lost clipboard data personally - I think this is an actual issue. Ask forgiveness, not permission seems about the right balance here. I'd phrase it in a more user-centric manner, that is, a user interface should be forgiving of user mistakes, rather than asking permission. Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform