Re: Intent to restrict to secure contexts: navigator.geolocation

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 wrote: >&g

Re: Intent to restrict to secure contexts: navigator.geolocation

On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> 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

Re: Intent to restrict to secure contexts: navigator.geolocation

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

Intent to restrict to secure contexts: navigator.geolocation

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Intent to ship: Restrict geolocation.watchPosition to secure contexts

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.

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

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

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

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

Re: Proposed W3C Charter: Hardware Security Working Group

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

Re: Proposed W3C Charter: Web Authentication Working Group

http://www.w3.org/TR/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 <rbar...@mozilla.com> > wrote: > > Obviously, given the earlier FIDO thread here, I think

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 12:31 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes <rbar...@mozilla.com> > wrote: > >> Hey Daniel, >> >> Thanks for the heads-up. This is a useful thing to keep in mind as we &

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

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 <rbar...@mozilla.com> wrote: > > > On M

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

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, _mozilla }, > > Just for clarification and

Re: Intent to implement and ship: FIDO U2F API

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 -

Intent to implement and ship: FIDO U2F API

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

Re: Intent to implement and ship: FIDO U2F API

er than string values, is a pattern > that the web has generally moved away from. > > / Jonas > > On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes <rbar...@mozilla.com> > wrote: > > The FIDO Alliance has been developing standards for hardware-based > > authentication of us

Re: Intent to ship: RC4 disabled by default in Firefox 44

Hearing no objections, let's consider this the plan of record. Thanks, --Richard On Tue, Sep 1, 2015 at 12:56 PM, Richard Barnes <rbar...@mozilla.com> wrote: > For a while now, we have been progressively disabling the known-insecure > RC4 cipher [0]. The security team has bee

Re: Intent to ship: RC4 disabled by default in Firefox 44

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 <rbar...@mozilla.com> wrote: > Speaking of other browsers, the corresponding Chromium threa

Re: Intent to ship: RC4 disabled by default in Firefox 44

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 <rbar...@mozilla.com> wrote: > For a while now, we have been progressively

Re: On the future of keygen and application/x-x509-*-cert MIME handling

On Thu, Jul 30, 2015 at 6:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 30, 2015 at 12:28 PM, Teoli news.fakeaddress@localhost.invalid 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

Re: On the future of keygen and application/x-x509-*-cert MIME handling

On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario hka...@redhat.com 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

Re: Busy indicator API

On Sun, Jul 5, 2015 at 5:11 PM, Anne van Kesteren ann...@annevk.nl 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

Secure contexts required for new web platform features

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

State synchronization - use cases?

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

Re: State synchronization - use cases?

, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: If anyone has use cases in addition to the above, please let me know. Public suffix? Getting that updated more frequently would be good. Especially now sites like GitHub can use it to silo user data. -- https://annevankesteren.nl

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd esheph...@mozilla.com 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

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:30 AM, Martin Thomson m...@mozilla.com wrote: On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann chofm...@mozilla.com wrote: Is there a wiki page or some other comprehensive reference that defines the issues and arguments around this central question? Richard was -

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 9:50 PM, imfasterthanneutr...@gmail.com 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

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 10:13 AM, lauren4...@gmail.com 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,

Re: Intent to deprecate: Insecure HTTP

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 rbar...@mozilla.com wrote: There's pretty broad agreement that HTTPS

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 21, 2015 at 9:56 AM, Mike Hoye mh...@mozilla.com 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

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 9:13 PM, Karl Dubost kdub...@mozilla.com wrote: As Robert is saying: Le 16 avr. 2015 à 00:29, Robert Kaiser ka...@kairo.at 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.

Re: Intent to deprecate: Insecure HTTP

Hey Katelyn, Thanks for bringing up these considerations. On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd k...@luminance.org 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

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 16, 2015 at 8:16 AM, david.a.p.ll...@gmail.com 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

Re: Intent to deprecate: Insecure HTTP

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.,

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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.

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

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

Re: Intent to deprecate: Insecure HTTP

On Mon, Apr 13, 2015 at 3:00 PM, Frederik Braun fbr...@mozilla.com 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

Intent to deprecate: Insecure HTTP

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

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)

On Nov 12, 2014, at 4:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote: The whole line of argumentation that web browsers and servers should be taking advantage of opportunistic encryption is explicitly informed by what's

Re: USB security keys

On Oct 21, 2014, at 4:08 PM, Robert O'Callahan rob...@ocallahan.org 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

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

On Sep 28, 2014, at 6:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Sep 27, 2014 at 10:10 PM, Richard Barnes rbar...@mozilla.com wrote: Are you making an argument more subtle than everything should be HTTPS, so we should make HTTP less functional? I'm not sure where you see me

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

On Sep 27, 2014, at 3:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 11:06 PM, Richard Barnes rbar...@mozilla.com 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

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

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

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)

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

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)

On Sep 15, 2014, at 5:11 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg dan...@haxx.se 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

WebCrypto for http:// origins

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

Re: WebCrypto for http:// origins

On Sep 11, 2014, at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com wrote: Most notably, even over non-secure origins, application-layer encryption can provide resistance to passive adversaries. See https://twitter.com

Re: Intent to ship navigator.sendBeacon

On Apr 16, 2014, at 1:49 PM, Gavin Sharp ga...@gavinsharp.com wrote: On Wed, Apr 16, 2014 at 8:56 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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