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 viab
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 depreca
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
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 E
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
sett
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 h
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
li
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 defini
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 a
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,
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
>
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
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]
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
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.
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 wh
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 malici
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 aut
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
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
bro
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.
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,
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_ (
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 yello
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 ea
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.
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
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.
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/6e929ef81c0807a969f906444973
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
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.m
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 wro
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
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 n
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 exc
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 preciou
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
"engag
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
> 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 yo
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
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. W
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
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 ru
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-br
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.
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 yo
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 remai
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) --clo
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),
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 ot
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 t
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 Spe
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
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] i
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
55 matches
Mail list logo