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 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, here'
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 (a
Henri,
great points, about…
Le 14 avr. 2015 à 19:29, Henri Sivonen 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 that
> users encoun
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 ve
+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 u
+1
On Tue, Apr 14, 2015 at 3:59 PM, Justin Dolske 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 broadly
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 whiteboar
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 m
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 actua
On Tue, Apr 14, 2015 at 5:59 PM, 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 HTTP now, and treat H
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
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
i
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 o
+1.
On Tue, Apr 14, 2015 at 2:42 PM, Kyle Huey wrote:
> On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup
> 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 aw
On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup 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.
- Kyle
__
(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 pointe
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 u
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 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
Pri
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.
>
>
>
> Thanks,
> --Richard
While I fully understand what's at sta
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 plaintex
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 object
The next MemShrink meeting is brought to you by delayed Desktop Reader
parsing:
https://bugzilla.mozilla.org/show_bug.cgi?id=1142183
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure
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 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
> 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
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
On Tue, Apr 14, 2015 at 8: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
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
bugs
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 ac
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 "foo.b
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 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 democr
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 UTC-
> 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 exerci
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
pro
On Mon, Apr 13, 2015 at 7:13 PM, Karl Dubost wrote:
> Richard,
>
> Le 13 avr. 2015 à 23:57, Richard Barnes 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 order to encourage web devel
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
On Tue, Apr 14, 2015 at 9:57 AM, 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 via radvd (or dhcp on
> IP
On Tue, Apr 14, 2015 at 8:32 AM, Eric Shepherd
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., localhost. Th
On Tue, Apr 14, 2015 at 3:55 AM, Yoav Weiss wrote:
> On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren
> wrote:
>
> > On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss wrote:
> > > Limiting new features does absolutely nothing in that aspect.
> >
> > Hyperbole much? CTO of the New York Times cited H
On Mon, Apr 13, 2015 at 10:10 PM, Karl Dubost 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.
>
> > The domai
On Mon, Apr 13, 2015 at 11:26 PM, 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 put this
On Mon, Apr 13, 2015 at 9:43 PM, 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
> HTTPS+selfsigned now); th
On Tue, Apr 14, 2015 at 7:01 AM, Aryeh Gregor wrote:
> On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham 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
On Mon, Apr 13, 2015 at 7:03 PM, Martin Thomson wrote:
> On Mon, Apr 13, 2015 at 3:53 PM, Eugene
> wrote:
> > In addition to APIs, I'd like to propose prohibiting caching any
> resources loaded over insecure HTTP, regardless of Cache-Control header, in
> Phase 2.N.
>
> This has some negative con
On Mon, Apr 13, 2015 at 5:11 PM, 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
>
>
> http://stackoverflo
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
wrote:
I would like to propose that we should ban the usage of refcounted
objects
inside lambdas in Gecko. Here is the reason:
Consider the following code:
nsINo
On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham 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 actors are trustw
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 via radvd (or dhcp on
IPv4), so there's no certificate to be had.
They'd
On 2015-04-10 9:43 PM, Gregory Szorc wrote:
On Fri, Apr 10, 2015 at 11:46 AM, Ehsan Akhgari 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:
Consider the following cod
On 2015-04-13 1:55 PM, Trevor Saunders wrote:
On Mon, Apr 13, 2015 at 01:28:05PM -0400, Ehsan Akhgari wrote:
On 2015-04-13 5:26 AM, Nicolas B. Pierron wrote:
On 04/10/2015 07:47 PM, Ehsan Akhgari wrote:
On 2015-04-10 1:41 PM, Nicolas B. Pierron wrote:
Also, what is the alternative? Acquiring
On 2015-04-10 9:43 PM, Gregory Szorc wrote:
On Fri, Apr 10, 2015 at 11:46 AM, Ehsan Akhgari 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:
Consider the following cod
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
> 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 ex
On 14/04/15 08:51, 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 another user. Thi
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 exempt
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 t
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 -
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 active
> 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 lux
On 4/14/15 3:28 AM, Anne van Kesteren wrote:
On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost 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. Here "regularly" is
On Mon, Apr 13, 2015 at 5:57 PM, Richard Barnes 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
> encryption, which in th
> 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 w
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, whi
On Tue, Apr 14, 2015 at 10:43 AM, Anne van Kesteren
wrote:
> On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss 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 ena
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.
___
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, th
On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss 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 citizen, wh
On Tue, Apr 14, 2015 at 10:07 AM, Anne van Kesteren
wrote:
> On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss 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 deprecat
On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss 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 developers
On Tue, Apr 14, 2015 at 9:51 AM, 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
> another user. This is a
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 ro
On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren wrote:
> On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss 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:
> 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 th
> 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
dev-
> 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 a
On Tue, Apr 14, 2015 at 9:29 AM, 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
realistic idea. Meanwhile,
> 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 sti
On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost 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 not need to register
82 matches
Mail list logo
