h as
> https-everywhere or user education on this topic. We are, after all, simply
> coming into alignment with the rest of the web ecosystem here.
>
+1
--Richard
>
> /a
>
>
> On 10/22/16 12:05, Ehsan Akhgari wrote:
>
>> On 2016-10-22 10:16 AM, Boris Zbarsky wrot
On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari
wrote:
> On 2016-10-21 3:49 PM, Richard Barnes wrote:
> > The geolocation API allows web pages to request the user's geolocation,
> > drawing from things like GPS on mobile, and doing WiFi / IP based
> > geolocation on d
On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson
wrote:
> On 10/21/2016 3:11 PM, Tantek Çelik wrote:
>
>> > Does this mean that we'd be breaking one in 5 geolocation requests as a
>>> > result of this? That seems super high. :(
>>>
>> Agreed. For example, my understanding is that this will break
The geolocation API allows web pages to request the user's geolocation,
drawing from things like GPS on mobile, and doing WiFi / IP based
geolocation on desktop.
Due to the privacy risks associated with this functionality, I would like
to propose that we restrict this functionality to secure conte
Keeping it in Nightly / Developer Edition seems like about the right
compromise to me. I guess there's some marginal security in turning off
this capability in release browsers (though I have difficulty precisely
articulating the threat model where it makes sense). But if we're going to
disable i
This is clearly a powerful feature, so it's a natural candidate for
restriction. Chromium is restricting all of navigator.geolocation as of 50:
https://codereview.chromium.org/1530403002/
Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
non-secure contexts.
http://mzl.l
On Fri, Apr 15, 2016 at 5:45 PM, Matthew N. wrote:
> On 2016-04-15 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>>
>> E.g. since one of the issues raised is that *every* time a user
>> enters/submits a password over HTTP (not secure),
On Thursday, March 10, 2016 at 11:27:34 PM UTC-5, Martin Thomson wrote:
> On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker wrote:
> > no password generation help by the UA
>
> I agree with MattN here, not doing this eliminates much of the
> advantage of having a password manager. Or do you have a p
Another good reason for blocking this for now is that it lets Javascript
circumvent the 5usec granularity of performance.now() and do things like
stealing private keys.
https://www.w3.org/TR/hr-time/#privacy-security
http://iss.oy.ne.ro/SpyInTheSandbox.pdf
https://bugzilla.mozilla.org/show_bug.cgi
Mozilla should oppose the formation of this working group. The charter
fails to specify concrete deliverables, and many of the potential
deliverables listed have been opposed several times by browser vendors,
e.g., because hardware assets exposed to JS can be used as super-cookies.
If anything is
R/credential-management-1/
>
> Seems like there's potential for integration between the two?
>
> / Jonas
>
> On Thu, Jan 7, 2016 at 10:14 AM, Richard Barnes
> wrote:
> > Obviously, given the earlier FIDO thread here, I think this is good work
> to
> > suppo
In any case, the pin check doesn't matter. The certificate verification
will have failed well before the pin checks are done.
On Mon, Jan 4, 2016 at 4:14 PM, David Keeler wrote:
> > { "aus5.mozilla.org", true, true, true, 7, &kPinset_mozilla },
>
> Just for clarification and future reference, t
ch the server.
So we can't get any measurements unless we revert the SHA-1 intolerance.
Given this, I'm sort of inclined to do that, collect some data, then maybe
re-enable it in 45 or 46. What do others think?
--Richard
On Mon, Jan 4, 2016 at 1:43 PM, Richard Barnes wrote:
>
>
&
On Mon, Jan 4, 2016 at 12:31 PM, Bobby Holley wrote:
> On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes
> wrote:
>
>> Hey Daniel,
>>
>> Thanks for the heads-up. This is a useful thing to keep in mind as we
>> work
>> through the SHA-1 deprecation.
&g
Hey Daniel,
Thanks for the heads-up. This is a useful thing to keep in mind as we work
through the SHA-1 deprecation.
To be honest, this seems like a net positive to me, since it gives users a
clear incentive to uninstall this sort of software.
--Richard
On Mon, Jan 4, 2016 at 3:19 AM, Daniel
On Wed, Dec 2, 2015 at 12:25 AM, wrote:
> On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> > Oh well. Bummer.
> >
> > / Jonas
>
> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
alues, is a pattern
> that the web has generally moved away from.
>
> / Jonas
>
> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes
> wrote:
> > The FIDO Alliance has been developing standards for hardware-based
> > authentication of users by websites [1]. Their work is g
The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1]. Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point
On Mon, Sep 21, 2015 at 6:58 PM, Jonathan Watt wrote:
> On 21/09/2015 19:57, Eric Rescorla wrote:
>
>> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking wrote:
>>
>> Note that this, similarly to clipboard integration, is already exposed
>>> to the web through flash. So the main goal of this featur
Hearing no objections, let's consider this the plan of record.
Thanks,
--Richard
On Tue, Sep 1, 2015 at 12:56 PM, Richard Barnes wrote:
> For a while now, we have been progressively disabling the known-insecure
> RC4 cipher [0]. The security team has been discussing with other th
And from Microsoft:
http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/
On Tue, Sep 1, 2015 at 1:03 PM, Richard Barnes wrote:
> Speaking of other browsers, the corresponding Chromium thread is here:
>
>
Speaking of other browsers, the corresponding Chromium thread is here:
https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ
On Tue, Sep 1, 2015 at 12:56 PM, Richard Barnes wrote:
> For a while now, we have been progressively disabling the known-insec
For a while now, we have been progressively disabling the known-insecure
RC4 cipher [0]. The security team has been discussing with other the
browser vendors when to turn off RC4 entirely, and there seems to be
agreement to take that action in late January / early February 2016,
following the rele
On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario wrote:
> On Wednesday 29 July 2015 16:35:41 David Keeler wrote:
> > [cc'd to dev-security for visibility. This discussion is intended to
> > happen on dev-platform; please reply to that list.]
> >
> > Ryan Sleevi recently announced the pre-intention t
On Thu, Jul 30, 2015 at 6:33 AM, Anne van Kesteren wrote:
> On Thu, Jul 30, 2015 at 12:28 PM, Teoli
> wrote:
> > Do you think it is already worth to flag it as deprecated in the MDN
> > documentation as Google plans to remove it too?
>
> Yeah, seems worth a note at least given that Microsoft doe
On Sun, Jul 5, 2015 at 5:11 PM, Anne van Kesteren wrote:
> A while back there have been some requests from developers (seconded
> by those working on GitHub) to have an API to indicate whether a site
> is busy with one thing or another (e.g. networking).
>
> They'd like to use this to avoid havin
As a next step toward deprecating non-secure HTTP [1], we are making the
following two changes to how we develop new web platform features,
effective immediately:
First, when we work on developing specifications for new web platform
features, we will make sure that these specifications require sec
ority, because
it already exists.
Sent from my iPhone. Please excuse brevity.
> On Jun 26, 2015, at 10:56, Dave Townsend wrote:
>
> The blocklist service also downloads about once a day
>
> On Fri, Jun 26, 2015 at 10:49 AM, Anne van Kesteren
> wrote:
>
>> On Fri, J
Hey dev.platform folks,
Some of us in the security engineering group have been chatting with cloud
services about making an improved way to maintain state in the browser.
Our use cases are things like:
- Revoked certificates (OneCRL)
- HSTS / HPKP preloads
We're trying to get an idea of how big
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
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
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
use a
lot of advanced web features, so may not be impacted by this deprecation
plan for a long time (if ever).
5. We can take these interim steps *and* work toward deprecation.
On Mon, Apr 13, 2015 at 7:57 AM, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way
On Thursday, April 23, 2015 at 11:47:14 PM UTC-4, voracity wrote:
> Just out of curiosity, is there an equivalent of:
>
> python -m SimpleHTTPServer
>
> in the TLS world currently, or is any progress being made towards that?
openssl req -new -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem
o
On Tue, Apr 21, 2015 at 9:56 AM, Mike Hoye wrote:
> On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote:
>
>> I know, not that well explained and over simplified. But the concept is
>> hopefully clear, but in case it's not...
>>
> For what it's worth, a lot of really smart people have been thinking
On Thu, Apr 16, 2015 at 8:16 AM, wrote:
> > > I think that you should avoid making this an exercise in marketing
> Mozilla's "Let's Encrypt" initiative.
> >
> > Perhaps that's why Richard took the time to make a comprehensive list of
> > all known sources of free certs, rather than just mentionin
Hey Katelyn,
Thanks for bringing up these considerations.
On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd wrote:
> I expressed my opinion on this subject at length on the Chrome lists
> when they made a similar proposal. I'll summarize it here, though,
> since I feel the same way about FF depreca
On Wed, Apr 15, 2015 at 9:13 PM, Karl Dubost wrote:
> As Robert is saying:
>
> Le 16 avr. 2015 à 00:29, Robert Kaiser a écrit :
> > I think we need to think very hard about what reasons people have to
> still not use TLS and how we can help them to do so.
>
> Definitely.
> The resistance in this
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 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.
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 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 Mon, Apr 13, 2015 at 3:00 PM, Frederik Braun wrote:
> On 13.04.2015 20:52, david.a.p.ll...@gmail.com wrote:
> >
> >> 2) Protected by subresource integrity from a secure host
> >>
> >> This would allow website operators to securely serve static assets from
> non-HTTPS servers without MITM risk,
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 the case of the web means HTTPS.
In order to encourage web develo
> On Nov 12, 2014, at 4:35 AM, Anne van Kesteren wrote:
>
> On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach wrote:
>> The whole line of argumentation that web browsers and servers should be
>> taking advantage of opportunistic encryption is explicitly informed by
>> what's actually "happening elsew
> On Oct 21, 2014, at 4:08 PM, Robert O'Callahan wrote:
>
> http://googleonlinesecurity.blogspot.co.nz/2014/10/strengthening-2-step-verification-with.html
> We should support this.
Maybe I'm just jaded, but given that we're currently in the process of phasing
out custom APIs for one specialize
On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari wrote:
> On 2014-09-30, 4:29 AM, Henri Sivonen wrote:
>>> More immediately we should make it impossible to make persistent
>>> grants for these features on unauthenticated origins.
>>
>> This I agree with when it comes to privacy-sensitive API: Grantin
On Sep 28, 2014, at 6:26 AM, Anne van Kesteren wrote:
> On Sat, Sep 27, 2014 at 10:10 PM, Richard Barnes wrote:
>> Are you making an argument more subtle than "everything should be HTTPS, so
>> we should make HTTP less functional"?
>
> I'm not sure wher
On Sep 27, 2014, at 3:02 AM, Anne van Kesteren wrote:
> On Fri, Sep 26, 2014 at 11:06 PM, Richard Barnes wrote:
>> It is not our job to break the HTTP-schemed web to force everyone to HTTPS.
>
> It is for features where it matters for end users.
>
>
>> Users an
Speaking as someone who (1) chaired the IETF working group on geolocation and
privacy for several years, and (2) now manages PKI and crypto for Mozilla --
this is nonsense as stated. It is not our job to break the HTTP-schemed web to
force everyone to HTTPS.
Users and web sites have been using
Pretty sure that what he's referring to is called DANE. It lets a domain
holder assert a certificate or key pair, using DNSSEC to bind it to the domain
instead of PKIX (or in addition to PKIX).
https://tools.ietf.org/html/rfc6698
On Sep 21, 2014, at 8:01 AM, Anne van Kesteren wrote:
> On S
On Sep 15, 2014, at 5:11 AM, Henri Sivonen wrote:
> On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg wrote:
>> On Mon, 15 Sep 2014, Henri Sivonen wrote:
>>> What the Chrome folks suggest for HTTP/2 would give rise to a situation
>>> where your alternatives are still one one hand unencrypted an
On Sep 11, 2014, at 9:08 AM, Anne van Kesteren wrote:
> On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes wrote:
>> Most notably, even over non-secure origins, application-layer encryption can
>> provide resistance to passive adversaries.
>
> See https://twitt
Hey all,
Sorry for being late to the party here. I now subscribe to dev.platform :)
On the issue of whether WebCrypto should be restricted to secure origins: In
discussions I've had with folks around Mozilla, we have not seen sufficient
security risks to motivate cutting off the potential bene
On Apr 16, 2014, at 1:49 PM, Gavin Sharp wrote:
> On Wed, Apr 16, 2014 at 8:56 AM, Ehsan Akhgari
> wrote:
>>> Are beacons primarily meant as tracking devices, or is it also meant as
>>> a way to persist unsaved page state when the user navigates?
>
>> Beacons do not enable any new ways of tra
On Apr 16, 2014, at 10:52 AM, Benjamin Smedberg wrote:
> On 4/16/2014 9:30 AM, Richard Barnes wrote:
>>
>> Allows pages to send a "beacon" HTTP request. Beacons are allowed a limited
>> subset of HTTP (only a few content types), and the JS cannot receive
Primary eng emails
rbar...@mozilla.com, eh...@mozilla.com
Spec
http://www.w3.org/TR/beacon/
*Summary*
Allows pages to send a "beacon" HTTP request. Beacons are allowed a
limited subset of HTTP (only a few content types), and the JS cannot
receive the content of the response. However, beac
64 matches
Mail list logo
