Hi All,
Summary: We want to expose a Web API to Gaia to collect metrics for FxOS.
This API would leverage the existing Gecko toolkit/components/telemetry
capabilities to provide histograms to Telemetry Servers for analysis by
data owners.
Bug: 1160634
Link to standard: No formal specifications t
When plans like this aren't rolled out across all browsers together, users
inevitably come across a broken site and say "Firefox works with this site, but
Safari gives a warning. Safari must be broken". Better security is punished.
Having this determined by a browser release is also bad. "My
On 2015-05-01 3:40 PM, 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. These computers have a burgeoning "retro"
fanbase trying to push them to do new and intere
On Fri, May 1, 2015 at 11:30 AM, Martin Thomson wrote:
> On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann
> wrote:
> > Is there a wiki page or some other comprehensive reference that defines
> the
> > issues and arguments around this central question?
>
> Richard was - I think - in the process of
On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd
wrote:
> Martin Thomson wrote:
>
>> There are two aspects to this: the software, and the content.
>>
>> If software cannot be updated, that a problem in its own right. The
>> idea that you could release your server onto the Internet to fend for
>> i
Martin Thomson wrote:
There are two aspects to this: the software, and the content.
If software cannot be updated, that a problem in its own right. The
idea that you could release your server onto the Internet to fend for
itself for 20 years was a dream of the 90s that has taken a while to
die.
On Fri, May 1, 2015 at 10:13 AM, wrote:
> Here we go again. Listen up, guys. There are vast numbers of legacy sites
> without the technical or financial means to convert to https:,
Of course I agree that we should not be brushing aside the little guys.
But from where I sit, I'm seeing lots of e
Whoopie... I can jump through hoops and make TLS fast. Why should I have to?
The user should be the decision maker. If they want to visit an unsecured HTTP
site of cat videos... let them. IF a hacker wants to edit those cat videos
while in transit... LET THEM. Why strong-arm everyone into usi
On Thu, Apr 30, 2015 at 9:50 PM, wrote:
> > 1.Setting a date after which all new features will be available only to
> secure websites
>
> I propose the date to be one year after Let's Encrypt is launched, which
> is about mid-2016.
>
I was hoping for something a little sooner, given that we're t
On 2015-05-01 2:06 PM, Eric Shepherd wrote:
There are a lot of things that don't need encryption, and sites that
serve legacy purposes and/or audiences, and cannot be updated to https
in the first place.
Encryption is not about protecting data. Encryption is about protecting
people.
- mho
Honestly, this is a terrible idea. The whole point of a browser is providing
user access - this would take power away from users by deciding for them what
is permissible. It also fails to account for the bulk of web traffic which does
not require encryption (and is the reason HTTP exists in the
On Fri, May 1, 2015 at 2:37 PM, Patrick McManus wrote:
> It is afterall likely stored in cleartext on each computer. This is an
> important distinction no matter the nature of the content because Firefox,
> as the User's Agent, has a strong interest in the user seeing the content
> she asked for
On Fri, May 1, 2015 at 2:07 PM, wrote:
> Why encrypt (and slow down) EVERYTHING
I think this is largely outdated thinking. You can do TLS fast, and with
low overhead. Even on the biggest and most latency sensitive sites in the
world. https://istlsfastyet.com
> when most web content isn't wort
On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann wrote:
> Is there a wiki page or some other comprehensive reference that defines the
> issues and arguments around this central question?
Richard was - I think - in the process of assembling an FAQ that
covered this and other issues. This is defini
+freaking1
On Fri, May 1, 2015 at 2:16 PM, Martin Thomson wrote:
> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd wrote:
>> There are a lot of things that don't need encryption,
>
> This assertion is made quite often in this context. It's been shown to
> be false in every example I've seen. I t
On Fri, May 1, 2015 at 11:16 AM, Martin Thomson wrote:
> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd
> wrote:
> > There are a lot of things that don't need encryption,
>
> This assertion is made quite often in this context. It's been shown to
> be false in every example I've seen. I think Ri
On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd wrote:
> There are a lot of things that don't need encryption,
This assertion is made quite often in this context. It's been shown to
be false in every example I've seen. I think Richard provided several
citations where this was believed to be corre
Why encrypt (and slow down) EVERYTHING, when most web content isn't worth
encrypting? I just don't see the point. This is the dumbest thing I've heard
in a long while.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.
lauren4...@gmail.com wrote:
There are vast numbers of legacy sites without the technical or financial means
to convert to https:, nor are many serving material that fundamentally needs to
be encrypted.
While the tone of the rest of this message was a little harsh, I agree
with this. There are
You must have missed my original email:
>I understand that there are proposed solutions to these problems but
>they don't exist today and won't be ubiquitous for a while.
Let's let these solutions prove themselves out first.
There are no free wildcard cert vendors and, at least in my experience,
On 2015-05-01 1:13 PM, lauren4...@gmail.com wrote:
Here we go again. Listen up, guys.
That's not going to be a winning approach here.
- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 t
On 01/05/15 18:39, Boris Zbarsky wrote:
On 5/1/15 12:41 PM, Jet Villegas wrote:
I think the plan was to improve security and dogfood rust. If we're also
signing up to increase spec compliance as part of the rewrite, that
should
be called out as an explicit goal--with a plan for dealing with
non-
On 5/1/15 12:41 PM, Jet Villegas wrote:
I think the plan was to improve security and dogfood rust. If we're also
signing up to increase spec compliance as part of the rewrite, that should
be called out as an explicit goal--with a plan for dealing with
non-compliant sites.
And outright spec bugs
On Friday, May 1, 2015 at 7:03:32 PM UTC+2, Adam Roach wrote:
> On 5/1/15 05:03, Matthew Phillips wrote:
> > All mandatory https will do is discourage people from participating in
> > speech unless they can afford the very high costs (both in dollars and
> > in time) that you are now suggesting be
Here we go again. Listen up, guys. There are vast numbers of legacy sites
without the technical or financial means to convert to https:, nor are many
serving material that fundamentally needs to be encrypted. While I've long been
a proponent of opportunistic crypto -- particularly by leveraging
On 5/1/15 05:03, Matthew Phillips wrote:
All mandatory https will do is discourage people from participating in
speech unless they can afford the very high costs (both in dollars and
in time) that you are now suggesting be required.
Let's be clear about the costs and effort involved.
There are
It is always hard to advertise every change, but there are enough changes to
post a brief summary.
What has changed:
1) :bgrins has added a new talos test 'damp' - devtools at maximum performance!
This was done in https://bugzilla.mozilla.org/show_bug.cgi?id=1150215
2) Talos doesn't run on OSX
I think the plan was to improve security and dogfood rust. If we're also
signing up to increase spec compliance as part of the rewrite, that should
be called out as an explicit goal--with a plan for dealing with
non-compliant sites.
--Jet
On Fri, May 1, 2015 at 2:33 AM, James Graham wrote:
> On
On 5/1/15 02:54, 王小康 wrote:
P.S.:And finally, accept Cacert or a easy to use CA.
CAs can only be included at their own request. As it stands, CACert has
withdrawn its request to be included in Firefox until they have
completed an audit with satisfactory results. If you want CACert to be
incl
On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
There is no such agreement, and even if there was, that doesn't mean you get to
force people to agree.
> In order to encourage web developers to move f
Trevor> One might wish to mark Foo::IsAFoo override so the compiler
Trevor> checks it shadows Base::IsAFoo but both are still non virtual.
Yes, I agree, one might. But that doesn't really have any bearing on
the present.
Right now, override is defined as only making sense on virtual
functions.
On Fri, May 01, 2015 at 05:05:09AM -0700, finnbry...@gmail.com wrote:
> On Friday, May 1, 2015 at 12:03:35 PM UTC+1, Aryeh Gregor wrote:
> > On Thu, Apr 30, 2015 at 6:49 PM, Trevor Saunders wrote:
> > > I don't think it would actually be backward incompatible the only
> > > changes would be turning
On 2015-05-01 8:03 AM, Matthew Phillips wrote:
Of course you know this is not true. There have been many petabytes of
free speech floating around on the internet for the last 2 decades,
despite not having mandatory https.
There are some philosophical discussions to be had here around "freedom
fr
Of course you know this is not true. There have been many petabytes of
free speech floating around on the internet for the last 2 decades,
despite not having mandatory https.
All mandatory https will do is discourage people from participating in
speech unless they can afford the very high costs (
On Friday, May 1, 2015 at 12:03:35 PM UTC+1, Aryeh Gregor wrote:
> On Thu, Apr 30, 2015 at 6:49 PM, Trevor Saunders wrote:
> > I don't think it would actually be backward incompatible the only
> > changes would be turning invalid programs into valid ones.
>
> Given that "void foo() override;" curr
On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips wrote:
> I understand that there are proposed solutions to these problems but they
> don't exist today and won't be ubiquitous for a while. That *has* to come
> first. Nothing is more important than the free speech the web allows. Not
> even s
On Thu, Apr 30, 2015 at 6:49 PM, Trevor Saunders wrote:
> I don't think it would actually be backward incompatible the only
> changes would be turning invalid programs into valid ones.
Given that "void foo() override;" currently makes foo() a virtual
function, allowing override on non-virtual fun
restriction might be:
unless website is severing from local network,
1. you can't use a password input(treat it equal to normal text input).
2. you can't set cookie.
3. javascript is disabled.
A header is provided to prevent a content from https being load to a http page.
(maybe work like same-ori
On 30/04/15 23:42, Jet Villegas wrote:
I wonder why we'd allow *any* parsing differences here? Couldn't you just
assert and fail hard while you're testing against our tests and in Nightly?
I imagine the differences you don't catch this way will be so subtle that
crowd-sourcing is unlikely to catc
40 matches
Mail list logo
