Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

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 
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")

[Adam Roach]

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 
 
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 deprecate: Insecure HTTP

[Cameron Kaiser]

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")

[Ehsan Akhgari]

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 
, 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 
, 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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Ehsan Akhgari]

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 
 
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")

[Ehsan Akhgari]

On 2015-05-06 6:48 PM, Tantek Çelik wrote:

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson  wrote:

On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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 implement and ship: document.execCommand("cut"/"copy")

[Ehsan Akhgari]

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")

[Tantek Çelik]

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson  wrote:
> On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Martin Thomson]

On Wed, May 6, 2015 at 11:55 AM, Adam Roach  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: Web Speech API Installation Build Flags

[Nicholas Alexander]

On Tue, May 5, 2015 at 10:36 PM,  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: Using rust in Gecko. rust-url compatibility

[Jonas Sicking]

On Tue, May 5, 2015 at 7:10 PM, Valentin Gosu  wrote:
> On 6 May 2015 at 04:58, Doug Turner  wrote:
>> > On May 5, 2015, at 12:55 PM, Jonas Sicking  wrote:
>> >
>> > On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu 
>> > 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")

[Neil Deakin]

On 2015-05-06 2:38 PM, Adam Roach wrote:


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.


It isn't possible, no. Only the type of data is known to the clipboard. 
The data itself is opaque and, in most cases, not actually determined 
until it is pasted. You could handle some specific trivial cases, but i 
don't think this is an avenue worth exploring.


___
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")

[Adam Roach]

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")

[Gervase Markham]

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")

[Mike Taylor]

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] 

[2] 



--
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")

[Adam Roach]

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")

[Jonas Sicking]

On Wed, May 6, 2015 at 10:08 AM, Anne van Kesteren  wrote:
> On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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.

But the argument here is "if websites had access to write to the
clipboard, they will do horrible things X, Y and Z". However that
argument is fairly easily disproven by looking at websites that exist
today.

Also keep in mind that for any well behaving websites, limiting the
ability to write to the clipboard is an annoyance for users. The
reason this feature is getting added is because *users* are annoyed
that they have to use keyboard shortcuts to copy data. I would argue
that users visit far more well behaving websites, than once that don't
care about user experience.

Like Ehsan, I don't see what advantages limiting this to https brings?

/ 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")

[Jonas Sicking]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  wrote:
>
>> On May 6, 2015, at 7:30 AM, Tantek Çelik  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 
> , 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")

[Gervase Markham]

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")

[dgraham]

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: , 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")

[Justin Dolske]

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")

[Tom Schuster]

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  wrote:

> On Wed, May 6, 2015 at 6:40 PM, Adam Roach  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")

[James Graham]

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
 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 implement and ship: document.execCommand("cut"/"copy")

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:40 PM, Adam Roach  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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Ehsan Akhgari]

On 2015-05-06 1:08 PM, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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")

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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")

[James Graham]

On 06/05/15 18:08, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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: Announcing Operation Instrument

[Jordan Santell]

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")

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari  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: Announcing Operation Instrument

[David Rajchenbach-Teller]

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")

[Ehsan Akhgari]

On 2015-05-06 3:00 AM, Tantek Çelik wrote:

On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari  wrote:

On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik  wrote:


On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari 
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 benefit from this 
effort.  Even worse, they may start t

Re: Using rust in Gecko. rust-url compatibility

[Simon Sapin]

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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Mike Taylor]

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] 

--
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")

[Tantek Çelik]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson  wrote:
> On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Anne van Kesteren]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson  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")

[Martin Thomson]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner  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: No more binary components in extensions

[Doug Turner]

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  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")

[Doug Turner]

> On May 6, 2015, at 7:30 AM, Tantek Çelik  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 , 
privacy.trackingprotection.enabled).

Doug
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rust in Gecko. rust-url compatibility

[Boris Zbarsky]

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

[Andrew Halberstadt]

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- 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")

[Tantek Çelik]

On Wed, May 6, 2015 at 10:51 AM, Gervase Markham  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

[Gijs Kruitbosch]

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- 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

[Andrew Halberstadt]

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- 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: PSA: Minor changes to mochitest harness and mach command arguments

[Gijs Kruitbosch]

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 deprecate: Insecure HTTP

[Anne van Kesteren]

On Wed, May 6, 2015 at 2:04 PM, Matthew Phillips
 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

Re: Intent to deprecate: Insecure HTTP

[Matthew Phillips]

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

PSA: Minor changes to mochitest harness and mach command arguments

[Andrew Halberstadt]

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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Gervase Markham]

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

Re: Is there an e10s plan for multiple content processes?

[bowen]

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: Using rust in Gecko. rust-url compatibility

[David Rajchenbach-Teller]

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: Web Speech API Installation Build Flags

[kdavis]

On Wednesday, May 6, 2015 at 9:40:47 AM UTC+2, Xidorn Quan wrote:
> On Wed, May 6, 2015 at 7:24 PM,  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,  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

[Xidorn Quan]

On Wed, May 6, 2015 at 7:24 PM,  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,  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web Speech API Installation Build Flags

[kdavis]

On Wednesday, May 6, 2015 at 8:00:44 AM UTC+2, Xidorn Quan wrote:
> On Wed, May 6, 2015 at 5:36 PM,  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: Intent to implement and ship: document.execCommand("cut"/"copy")

[Tantek Çelik]

On Wed, May 6, 2015 at 4:17 AM, Ehsan Akhgari  wrote:
> On Tue, May 5, 2015 at 7:34 PM, Tantek Çelik  wrote:
>>
>> On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari 
>> 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