I'm planing to drop nsIDOMWindowUtils.sendKeyEvent() because:
* it's not aware of UI Events' (a.k.a DOM Level 3 Events) KeyboardEvent
* nsITextInputProcessor already has new API to synthesize KeyboardEvent
via widget
* I'm now working on rewriting all mochitests in bug 1134539
On Tue, Apr 14, 2015 at 1:48 AM, david.a.p.ll...@gmail.com wrote:
- DANE for everyone
TLS through DNS is happening anytime soon, if ever:
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://sockpuppet.org/stuff/dnssec-qa.html
On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss y...@yoav.ws wrote:
Limiting new features does absolutely nothing in that aspect.
Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
Workers as a reason to start deploying HTTPS:
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://sockpuppet.org/stuff/dnssec-qa.html
https://www.imperialviolet.org/2015/01/17/notdane.html
Yawn - those were all terrible articles. To summarise their points: NSA is
bad, some DNS servers are out of date, DNSSEC may be still
The goal of this thread is to determine whether there is support in the
Mozilla community for a plan of this general form. Developing a precise
plan will require coordination with the broader web community (other
browsers, web sites, etc.), and will probably happen in the W3C.
From the
On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss y...@yoav.ws wrote:
Limiting new features does absolutely nothing in that aspect.
Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
Workers as a reason to
On Tue, Apr 14, 2015 at 10:07 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss y...@yoav.ws wrote:
You're inflicting developer pain without any real justification. A sort
of
collective punishment, if you will.
Why is that you think there is no
On Tue, Apr 14, 2015 at 10:43 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss y...@yoav.ws wrote:
Deprecating HTTP is totally justified. Enabling some features on HTTP but
not others is not, unless there's a real technical reason why these new
On Tue, Apr 14, 2015 at 9:29 AM, david.a.p.ll...@gmail.com wrote:
The trouble is: Just because something isn't perfect, doesn't make it a bad
idea.
I think it's a pretty great idea and it's one people immediately think
of. However, as those articles explain in detail, it's also a far from
Another note:
Nobody, to within experimental error, uses IP addresses to access public
websites.
But plenty of people use them for test servers, temporary servers, and embedded
devices. (My home router is http://192.168.1.254/, do they need to get a
certificate for 192.168.1.254? Or do home
On Tuesday, April 14, 2015 at 8:44:25 PM UTC+12, Anne van Kesteren wrote:
I don't follow. If HTTP is no longer a first-class citizen, why do we
need to treat it as such?
When it takes *more* effort to disable certain features on HTTP, than to let
them work.
Secondly the proposal to restrain unrelated new features like CSS attributes
to HTTPS sites only is simply a form of strong-arming. Favoring HTTPS is fine
but authoritarianism is not. Please consider that everyone is capable of
making their own decisions.
One might note that this has
realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
and is the focus of this thread.
http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/
Sure it works :)
___
dev-platform mailing list
On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss y...@yoav.ws wrote:
You're inflicting developer pain without any real justification. A sort of
collective punishment, if you will.
Why is that you think there is no justification in deprecating HTTP?
(And anecdotally, I find it easier to convince
On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss y...@yoav.ws wrote:
Deprecating HTTP is totally justified. Enabling some features on HTTP but
not others is not, unless there's a real technical reason why these new
features shouldn't be enabled.
I don't follow. If HTTP is no longer a first-class
Op maandag 13 april 2015 16:57:58 UTC+2 schreef Richard Barnes:
There's pretty broad agreement that HTTPS is the way forward for the web.
In recent months, there have been statements from IETF [1], IAB [2], W3C
[3], and even the US Government [4] calling for universal use of
encryption, which
On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost kdub...@mozilla.com wrote:
1. You do not need to register a domain name to have a Web site (IP address)
Name one site you visit regularly that doesn't have a domain name. And
even then, you can get certificates for public IP addresses.
2. You do
On Tue, Apr 14, 2015 at 9:51 AM, lorenzo.kel...@gmail.com wrote:
1) Caching proxies: resources obtained over HTTPS cannot be cached by a proxy
that doesn't use MITM certificates. If all users must move to HTTPS there
will be no way to re-use content downloaded for one user to accelerate
On Tuesday, April 14, 2015 at 8:44:25 PM UTC+12, Anne van Kesteren wrote:
I don't follow. If HTTP is no longer a first-class citizen, why do we
need to treat it as such?
When it would take more effort to disable a feature on HTTP than to let it
work, and yet the feature is disabled anyway,
On 4/14/15 3:28 AM, Anne van Kesteren wrote:
On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost kdub...@mozilla.com wrote:
1. You do not need to register a domain name to have a Web site (IP address)
Name one site you visit regularly that doesn't have a domain name.
My router's configuration UI.
Something entirely off-topic: I'd like to inform people that your replies to
popular threads like this unsigned, with only a notion of identity in an
obscure email address, makes me - and I'm sure others too - skip your message
or worse; not take it seriously.
Not everyone has the luxury
On 14 Apr 2015, at 11:42, intellectu...@gmail.com wrote:
Something entirely off-topic: I’d like to inform people that your replies to
popular threads like this unsigned, with only a notion of identity in an
obscure email address, makes me - and I’m sure others too - skip your message
or
On Mon, Apr 13, 2015 at 5:57 PM, Richard Barnes rbar...@mozilla.com wrote:
There's pretty broad agreement that HTTPS is the way forward for the web.
In recent months, there have been statements from IETF [1], IAB [2], W3C
[3], and even the US Government [4] calling for universal use of
On 2015-04-10 9:43 PM, Gregory Szorc wrote:
On Fri, Apr 10, 2015 at 11:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
I would like to propose that we should ban the usage of refcounted
objects
inside lambdas in Gecko. Here is the reason:
On Tue, Apr 14, 2015 at 8:32 AM, Eric Shepherd esheph...@mozilla.com
wrote:
Joshua Cranmer [image: ] wrote:
If you actually go to read the details of the proposal rather than
relying only on the headline, you'd find that there is an intent to
actually let you continue to use http for, e.g.,
bugzilla has a set of fields, hardware and operating system, that
i'll collectively call platform in this post. their default values
are detected from the reporter's user-agent string when a bug is created.
unfortunately on bmo, the platform fields have two distinctly different
meanings: the
Are the platform fields actually useful? Most bugs apply to all platforms
and in the cases that don't it is normally clear from the bug conversation
that it is platform specific. It seems like we rarely go an update the
platform fields to match the actual state of the bug. And then there is the
On 4/14/15 10:53, justin.kru...@gmail.com wrote:
Dynamic DNS might be difficult to run on HTTPS as the IP address needs to
change when say your cable modem IP updates. HTTPS only would make running
personal sites more difficult for individuals, and would make the internet
slightly less
Having that field be wrong is worse than not having it, no doubt about that,
but if we had a way of making sure that field actually contains correct
information, it would be extremely useful to the graphics team.
I don’t have the numbers, but it certainly feels like a large majority of the
On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Specifically, on point #2, I think we should start by, by default,
forgetting all cookies that don't have the secure flag set at the
end of the Firefox session. Persistent cookies have two main use
cases:
* On
Richard Barnes wrote:
As the owner of a Mac SE/30 with an 100MB Ethernet card, I
sympathize. However, consider it part of the challenge! :) There
are definitely TLS stacks that work on some pretty small devices.
That's a lot faster machine than the ones I play with. My fastest retro
machine
On Tue, Apr 14, 2015 at 8:40 AM, Dave Townsend dtowns...@mozilla.com
wrote:
Are the platform fields actually useful? Most bugs apply to all platforms
and in the cases that don't it is normally clear from the bug conversation
that it is platform specific. It seems like we rarely go an update
Hi Mozilla friends. Glad to see this proposal! As Richard mentions, we over on
Chromium are working on a similar plan, albeit limited to powerful features.
I just wanted to mention that regarding subresource integrity
(https://w3c.github.io/webappsec/specs/subresourceintegrity/), the general
On 4/14/15 10:06 AM, Ehsan Akhgari wrote:
On 2015-04-13 1:36 PM, Jan-Ivar Bruaroey wrote:
The above is a raw pointer bug, not a lambda bug.
Yes, I'm aware. Please see bug 1114683.
Thanks, I was not aware of this larger effort. This somewhat addresses
my concern that we seem overly focused
We believe that security includes confidentiality, which that would approach
would lack.
Hey Joel,
SSL already leaks which domain name you are visiting anyway, so the most
confidentiality this can bring you is hiding the specific URL involved in a
cache miss. That's a fairly narrow upgrade
HTTPS has its moments, but the majority of the web does not need it. I
certainly wouldn't appreciate the encryption overhead just for visiting David's
lolcats website. As one of the most important organizations related to free
software, it's sad to see Mozilla developers join the war on
On 2015-04-14 12:41 PM, Jan-Ivar Bruaroey wrote:
2. lambda capture use safer copy construction by default (hence the
standout [] above for reviewers).
There is nothing safe about copying raw pointers to refcounted objects.
There's nothing safe about copying raw pointers to heap
On Mon, Apr 13, 2015 at 11:26 PM, ipart...@gmail.com wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less
secure than HTTP is
On Mon, Apr 13, 2015 at 10:10 PM, Karl Dubost kdub...@mozilla.com wrote:
Le 14 avr. 2015 à 10:43, imfasterthanneutr...@gmail.com a écrit :
I don't think the current CA system is broken.
The current CA system creates issues for certain categories of population.
It is broken in some ways.
There are already multiple sources of free publicly-trusted certificates,
with more on the way.
https://www.startssl.com/
https://buy.wosign.com/free/
https://blog.cloudflare.com/introducing-universal-ssl/
https://letsencrypt.org/
I think that you should avoid making this an exercise in
On 2015-04-14 9:07 AM, Paul Adenot wrote:
Additionally, if someone has an idea on what to link to/what to say in
the actual deprecation notice, I'm all ears, the current message is more
or less a placeholder.
Perhaps we can document this in more detail on MDN and link to the docs
page?
On Tue, Apr 14, 2015 at 9:57 AM, hugoosvaldobarr...@gmail.com wrote:
I'm curious as to what would happen with things that cannot have TLS
certificates: routers and similar web-configurable-only devices (like small
PBX-like devices, etc).
They don't have a proper domain, and may grab an IP
Dynamic DNS might be difficult to run on HTTPS as the IP address needs to
change when say your cable modem IP updates. HTTPS only would make running
personal sites more difficult for individuals, and would make the internet
slightly less democratic.
On Monday, April 13, 2015 at 7:57:58 AM
On Mon, Apr 13, 2015 at 7:13 PM, Karl Dubost kdub...@mozilla.com wrote:
Richard,
Le 13 avr. 2015 à 23:57, Richard Barnes rbar...@mozilla.com a écrit :
There's pretty broad agreement that HTTPS is the way forward for the web.
Yes, but that doesn't make deprecation of HTTP a consensus.
In
On 4/14/15 11:53 AM, justin.kru...@gmail.com wrote:
Dynamic DNS might be difficult to run on HTTPS as the IP address needs to
change when say your cable modem IP updates.
Justin, I'm not sure I follow the problem here. If I understand
correctly, you're talking about a domain name, say
On 4/14/2015 11:40 AM, Dave Townsend wrote:
Are the platform fields actually useful? Most bugs apply to all platforms
and in the cases that don't it is normally clear from the bug conversation
that it is platform specific. It seems like we rarely go an update the
platform fields to match the
On Tue, Apr 14, 2015 at 3:55 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss y...@yoav.ws wrote:
Limiting new features does absolutely nothing in that aspect.
Hyperbole much? CTO
On 4/14/15 3:47 PM, commodorej...@gmail.com wrote:
On Tuesday, April 14, 2015 at 2:51:32 PM UTC-7, Cameron Kaiser wrote:
Candidly, and not because I still run such a site, I've always found
Gopher to be a better fit for resource-constrained computing. The
Commodore 128 sitting next to me does
Henri,
great points, about…
Le 14 avr. 2015 à 19:29, Henri Sivonen hsivo...@hsivonen.fi a écrit :
Currently, the UI designation for http is neutral while the UI
designation for mixed content is undesirable. I think we should make
the UI designation of plain http undesirable once x% the sites
TSF (Text Services Framework) is new API for IME on Windows. And also it
supports not only CJK-IME, e.g., speech input system, handwriting system.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms629032%28v=vs.85%29.aspx
This will be enabled only on Vista or later since TSF on WinXP
On 4/14/15 5:39 PM, Randell Jesup wrote:
I wonder if we could move to requiring already_AddRefed for
DispatchToMainThread (and Dispatch?), and thus block all attempts to do
DispatchToMainThread(new FooRunnable), etc. :-)
Yes! +1.
I like the .forget() semantics, but just to have options,
+1 to Milan's suggestion. These fields are used somewhat consistently on
stability and graphics bugs, which release management pays attention to. If
we are going to continue with the fields, I like the idea of Not
specified as that makes it clear that no value was set whereas All is
currently used
Lawrence Mandel wrote:
+1 to Milan's suggestion. These fields are used somewhat consistently
on stability and graphics bugs, which release management pays
attention to. If we are going to continue with the fields, I like the
idea of Not specified as that makes it clear that no value was set
On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham g...@mozilla.org wrote:
Yep. That's the system working. CA does something they shouldn't, we
find out, CA is no longer trusted (perhaps for a time).
Or do you have an alternative system design where no-one ever makes a
mistake and all the
On 2015-04-13 1:36 PM, Jan-Ivar Bruaroey wrote:
On 4/10/15 2:09 PM, Seth Fowler wrote:
On Apr 10, 2015, at 8:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
I would like to propose that we should ban the usage of refcounted
objects
inside lambdas in Gecko. Here is the reason:
Consider
On Mon, Apr 13, 2015 at 5:11 PM, bryan.beic...@gmail.com wrote:
One limiting factor is that Firefox doesn't treat form data the same on
HTTPS sites.
Examples:
http://stackoverflow.com/questions/14420624/how-to-keep-changed-form-content-when-leaving-and-going-back-to-https-page-wor
On Mon, Apr 13, 2015 at 7:03 PM, Martin Thomson m...@mozilla.com wrote:
On Mon, Apr 13, 2015 at 3:53 PM, Eugene imfasterthanneutr...@gmail.com
wrote:
In addition to APIs, I'd like to propose prohibiting caching any
resources loaded over insecure HTTP, regardless of Cache-Control header, in
On Tue, Apr 14, 2015 at 7:01 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham g...@mozilla.org wrote:
Yep. That's the system working. CA does something they shouldn't, we
find out, CA is no longer trusted (perhaps for a time).
Or do you have an
On Mon, Apr 13, 2015 at 9:43 PM, imfasterthanneutr...@gmail.com wrote:
On Monday, April 13, 2015 at 8:57:41 PM UTC-4, northrupt...@gmail.com
wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less
On 4/14/15 3:29 AM, Henri Sivonen wrote:
Specifically, on point #2, I think we should start by, by default,
forgetting all cookies that don't have the secure flag set at the
end of the Firefox session. Persistent cookies have two main use
cases:
* On login-requiring sites, not requiring the
(was: Re: Proposal to ban the usage of refcounted objects inside C++
lambdas in Gecko)
tl;dr: We should make DispatchToMainThread take already_AddRefed and
move away from raw ptrs for Dispatches in general.
So:
What I want to avoid is this pattern for runnables that hold
thread-restricted
On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup rjesup.n...@jesup.org wrote:
(was: Re: Proposal to ban the usage of refcounted objects inside C++
lambdas in Gecko)
tl;dr: We should make DispatchToMainThread take already_AddRefed and
move away from raw ptrs for Dispatches in general.
Agreed.
+1.
On Tue, Apr 14, 2015 at 2:42 PM, Kyle Huey m...@kylehuey.com wrote:
On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup rjesup.n...@jesup.org
wrote:
(was: Re: Proposal to ban the usage of refcounted objects inside C++
lambdas in Gecko)
tl;dr: We should make DispatchToMainThread take
On 4/14/15 16:32, northrupthebandg...@gmail.com wrote:
*By logical measure*, the [connection] that is encrypted but unauthenticated is
more secure than the one that is neither encrypted nor authenticated, and the
fact that virtually every HTTPS-supporting browser assumes the precise opposite
Hello,
On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
In order to encourage web developers to move from HTTP to HTTPS, I would
like to propose establishing a deprecation plan for HTTP without security.
snip
Thanks,
--Richard
While I fully understand what's at stake
On 4/14/15 15:35, emmanueldeloge...@gmail.com wrote:
Will Mozilla start to offer certificates to every single domain name owner ?
Yes [1].
https://letsencrypt.org/
[1] I'll note that Mozilla is only one of several organizations involved
in making this effort happen.
--
Adam Roach
On 4/14/15 10:38 AM, Eric Shepherd wrote:
Richard Barnes wrote:
As the owner of a Mac SE/30 with an 100MB Ethernet card, I
sympathize. However, consider it part of the challenge! :) There
are definitely TLS stacks that work on some pretty small devices.
That's a lot faster machine than the
On Tuesday, April 14, 2015 at 5:39:24 AM UTC-7, Gervase Markham wrote:
On 14/04/15 01:57, northrupt...@gmail.com wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do
with HTTPS+selfsigned now); the fact
On Tue, Apr 14, 2015 at 5:59 PM, northrupthebandg...@gmail.com wrote:
On Tuesday, April 14, 2015 at 5:39:24 AM UTC-7, Gervase Markham wrote:
On 14/04/15 01:57, northrupt...@gmail.com wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with
On Tuesday, April 14, 2015 at 2:51:32 PM UTC-7, Cameron Kaiser wrote:
Candidly, and not because I still run such a site, I've always found
Gopher to be a better fit for resource-constrained computing. The
Commodore 128 sitting next to me does very well for that because the
protocol and menu
On 4/14/2015 4:59 PM, northrupthebandg...@gmail.com wrote:
The article assumes that when folks connect to something via SSH and something changes - causing MITM-attack warnings and a refusal to
connect - folks default to just removing the existing entry in
~/.ssh/known_hosts without
On 4/14/15 8:40 AM, Dave Townsend wrote:
I've gotten used to just
ignoring these fields and reading the bugs instead. I wouldn't feel any
loss if they were just removed from display entirely.
+1. The fields are broadly unreliable, and we should just remove them. I
think I've seen the
On Tuesday, April 14, 2015 at 3:05:09 AM UTC-5, Anne van Kesteren wrote:
This definitely needs more research
but shouldn't preclude rolling out HTTPS on public resources.
The proposal as presented is not limited to public resources. The W3C
Privileged Context draft which it references exempts
On 14/04/15 08:47, david.a.p.ll...@gmail.com wrote:
realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
and is the focus of this thread.
http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/
Sure it works :)
Yep. That's the
Joshua Cranmer wrote:
If you actually go to read the details of the proposal rather than
relying only on the headline, you'd find that there is an intent to
actually let you continue to use http for, e.g., localhost. The exact
boundary between secure HTTP and insecure HTTP is being actively
On 14/04/15 01:57, northrupthebandg...@gmail.com wrote:
* Less scary warnings about self-signed certificates (i.e. treat
HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do
with HTTPS+selfsigned now); the fact that self-signed HTTPS is
treated as less secure than HTTP is - to
Continuing on the path to a less broken panning model on the Web Audio
API, this is a followup to [0]
The Web Audio API has a number of API that allow setting the velocity of
a listener and a panner, along with the speed of sound, and a
doppler factor, to be able to automatically pitch up or down
Yep. That's the system working. CA does something they shouldn't, we
find out, CA is no longer trusted (perhaps for a time).
Or do you have an alternative system design where no-one ever makes a
mistake and all the actors are trustworthy?
Gerv
Yes - as I said previously. Do the existing
+1
On Tue, Apr 14, 2015 at 3:59 PM, Justin Dolske dol...@mozilla.com wrote:
On 4/14/15 8:40 AM, Dave Townsend wrote:
I've gotten used to just
ignoring these fields and reading the bugs instead. I wouldn't feel any
loss if they were just removed from display entirely.
+1. The fields are
80 matches
Mail list logo
