Re: Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication
eb Authentication -- meaning not only > >> will Google need to change to the Web Authentication API, they will also > >> have to prompt users to go back through the enrollment ceremony. This > >> process is likely to take several years. > >> > >> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=webauthn > >> > >> Spec: https://www.w3.org/TR/webauthn/ > >> > >> Estimated target release: 60 > >> > >> Preference behind which this is implemented: > >> security.webauth.webauthn > >> > >> DevTools support: > >> N/A > >> > >> Support by other browser engines: > >> - Blink: In-progress > >> - Edge: In-progress > >> - Webkit: No public announcements > >> > >> Testing: > >> Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/; > >> https://webauthndemo.appspot.com/; Web Platform Tests in-progress > >> > >> > >> Cheers, > >> J.C. Jones and Tim Taubert > >> > >> [1] > >> https://groups.google.com/d/msg/mozilla.dev.platform/tsevyqf > >> BHLE/lccldWNNBwAJ > >> > >> [2] https://w3c.github.io/webauthn/#sctn-appid-extension and > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1406471 > >> > >> [3] > >> https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/ > >> fido-appid-and-facets-v1.2-ps-20170411.html > >> > >> [4] > >> https://groups.google.com/d/msg/mozilla.dev.platform/UW6WMmo > >> DzEU/8h7DFOfsBQAJ > >> and https://bugzilla.mozilla.org/show_bug.cgi?id=1244959 > >> > >> [5] > >> https://chromium.googlesource.com/chromium/src.git/+/master/ > >> chrome/browser/extensions/api/cryptotoken_private/cryptotoke > >> n_private_api.cc#30 > >> > >> [6] > >> https://chromium.googlesource.com/chromium/src.git/+/master/ > >> chrome/browser/extensions/api/cryptotoken_private/cryptotoke > >> n_private_api.cc#161 > >> ___ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)
+1 (as a Moz fan and privacy expert) On Tue, Mar 20, 2018 at 2:35 AM, Kris Maglione wrote: > On Mon, Mar 19, 2018 at 07:27:39PM -0700, Nicholas Alexander wrote: >> >> Hi all, >> >> On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote: >> >>> It's fine to embed this experiment in the product, and blog about it, but >>> it's definitely not fine to have it enabled by default and send every DNS >>> request to a third-party. >>> >>> I can understand that the intent must be good, and for better privacy, >>> but >>> the approach of doing so is not acceptable. Users would think Firefox is >>> going to just send data to arbitrary third-party without agreement from >>> them. >>> >>> As you can see from the replies, almost all people outside the network >>> team has expressed concerns about this, which should be considered a >>> signal >>> already that how other technical users may feel about this experiment, >>> and >>> how technical news would create a title for this. >>> >> >> Let me add my voice as a person outside the network team who can >> understand >> the concerns and _still thinks we should be doing this_. > > > I'll second this. > > I think it's reasonable to be concerned about the public reaction to this, > but I also think it's worth doing. The end result of this will almost > certainly be improved privacy and security for users who have this enabled > by default, and we can't get to that point without doing a study like this. > > I think it's worth the risk of a backlash. But I also think we should do > what we can to minimize that backlash. > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's Annual Dinner, Tech Prom, is March 29, 2018. Don't miss the tech event of the year! Reserve a table today.: https://cdt.org/annual-dinner/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Smart Card and WebCrypto (Re: On the future of and application/x-x509-*-cert MIME handling)
On Sun, Aug 30, 2015 at 1:50 AM, Anne van Kesteren wrote: > On Sun, Aug 30, 2015 at 7:33 AM, Tim Guan-tin Chien > wrote: >> It's also worthy to point out many nation-state deploys Smart Card >> identifications (despite the privacy concern), allow it's citizens (or >> subjects) to authenticate with government services online. > > It seems a potential future for that which works within the web's > security model is FIDO, see > > https://fidoalliance.org/ > https://support.google.com/accounts/topic/6103521 > > I don't think we're currently working on this though. (from the inveterate lurker...) I've said this to a number of FF folks but it would be great to get FIDO U2F support in FF; the U2F-enabled yubikeys/harware tokens etc. are a great, usable 2-factor technology, but it's hard to recommend people use them when they only work in Chrome. :/ best, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fido U2F, two-factor authentication support
+1 I would love love love to have U2F in Firefox. (Also, Dropbox supports it too, just as a data point: http://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/ ) On Thu, Nov 5, 2015 at 5:18 PM, Jeroen Hoek wrote: > In December 2014 the first public release of the Fido alliance's > Universal 2nd Factor (U2F) specification was published. The idea behind > this open specification is to provide a secure two-factor authentication > method with affordable hardware keys and a friendly UX. > > If I buy a hardware key that implements Fido U2F today, I can use it to > log on to Google's GMail and Github. It is possible to use the same > hardware key with any web service offering Fido U2F support, by design. > The specification allows for three methods of communication: USB, NFC, > and Bluetooth Low Energy (BLE). > > For Fido U2F to work, a browser implementing this technology is required. > > > There is an issue about Fido U2F support in Firefox: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 > > Unfortunately, this issue appears to receive no priority from Mozilla. > Reading the comments in this issue, it appears that despite the > attractiveness of the Fido U2F specification, developers see support in > Firefox as a deal-breaker. Personally, I feel that a security technology > such as this needs at least one free software browser to support it to > provide a viable alternative. > > Judging from the bounty placed on this Firefox issue (currently > exceeding 1000 USD), there appears to be a fairly strong community > desire to see this feature implemented. Commenters on the issue are, > however, worried about the (perceived lack of) priority afforded to this > issue. > > Developers participating in the issue recommended we post questions > about the prioritizing of this issue to the mozilla.dev.platform mailing > list. My apologies if this is not the place to discuss this issue. > > -- > > Is Fido U2F a technology that Mozilla can endorse and support? > > Could this technology be considered for inclusion in Firefox? > > -- > > Some background on this technology for those who are unfamiliar with it: > > The full Fido U2F specifications are available for download here: > > https://fidoalliance.org/specifications/overview/ > https://fidoalliance.org/specifications/download/ > > Specifically, the U2F overview may be interesting if you want a more > in-depth architectural overiew: > > https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html > > > Google announced support for Fido U2F a year ago, in October 2014, and > Chrome currently implements the Fido U2F standard: > > https://googleonlinesecurity.blogspot.nl/2014/10/strengthening-2-step-verification-with.html > > > Microsoft is backing this standard as well: > > https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/ > > > Yubico is one of the driving forces behind the Fido specifications from > the manufacturers side. They produce USB and NFC hardware tokens that > can be used with open security standards such as OATH-HOTP and > OATH-TOTP. Their recent line-up includes Fido U2F support as well: > > https://www.yubico.com/products/yubikey-hardware/ > > Yubico on Fido U2F: > > https://www.yubico.com/applications/fido/ > > Yubico is not the only manufacturer — other Fido-certified keys can be > found on Amazon — but they do appear to have a leading edge. > > > I am personally interested in Fido U2F from a professional standpoint. > The possibility to provide affordable two-factor authentication either > through USB, NFC, or BLE is appealing, and my employer is considering > opting for this standard to secure the health care software services we > provide — cross-browser support is, however, a requirement. > > I am not affiliated with the Fido alliance or its backers. > > -- > Kind regards, > > Jeroen Hoek > > Lable > ✉ jeroen.h...@lable.nl > GPG: 44D4 1D39 535A 1F9A 9509 92C5 A7A8 B913 D40D D022 > > http://lable.nl — KvK № 55984037 — BTW № NL8519.32.411.B.01 > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox Hello new data collection
On Tue, Apr 5, 2016 at 12:05 PM, Chris Hofmann wrote: > Thie passage in https://www.mozilla.org/en-US/privacy/firefox-hello/ also > would lead me to believe that the contents of my communication with another > user (including shared URLs) are encrypted (and would be private). > > We've just invested heavily in making this point and trying to make that > association that encryption mean strong privacy and vice-versa. > https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/ As an outside lurker on dev-platform but a big fan of Mozilla's data stewardship folks, this is the core of the issue for me. WebRTC conversations should be assumed to be highly private and any exfiltration on the client without explicit opt-in is seems very dangerous. I'm not saying it should never be done but it should be very very important and done very very carefully. I don't get the sense that this data is that crucial to innovative Hello features. You could opt-in folks to the study just-in-time using tab sharing. I know that clobbers the UX but if it's that important I think you need to take that hit given the sensitivity of real-time comms. -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies
Firefox 49 >>> >>> Preference behind which this will be implemented: >>> network.cookie.lifetime.httpSessionOnly >>> >>> Do other browser engines implement this? No >>> >>> [1] >>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ >>> [2] http://www.alexa.com/topsites/category/Top/News >>> ___ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web of Things Working Group
+1 on keeping w3c charter discussions here (or at least letting those of us organizational friends of Moz know where we go for that part of our Moz fix) On Thu, Oct 13, 2016 at 6:11 AM, Anne van Kesteren wrote: > On Thu, Oct 13, 2016 at 1:18 PM, Benjamin Francis > wrote: >> dev-platform is now only really about the back end of Firefox which isn't >> very relevant here. WoT mainly concerns the server side of the web stack. > > I don't really agree with this. 1) We can't really consider Firefox > frontend and backend as isolated entities. What happens in platform > affects the UX and vice versa. This is more and more true as we get > closer to the metal. 2) The browser could play a very interesting role > in the UX side of discovering new devices and getting them set up > (rather than letting that run through proprietary app stores). 3) > Discussion of W3C groups and their publications has always taken place > here. > > > -- > https://annevankesteren.nl/ > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: navigator.getBattery (Battery Status API)
Speaking on behalf of the privacy community (writ large and vaguely) thank you very much for this! best, Joe On Mon, Oct 31, 2016 at 4:24 AM, Chris Peterson wrote: > As proposed earlier on the dev-platform list [1], I made the Battery > Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The battery > code and tests remain, available to Gecko code and Firefox add-ons. > > There should be little risk of web compat regressions. The battery API was > never implemented by IE, Edge, or Safari, so web content should already be > feature-detecting the API. Also, I know of no non-trivial websites using > the API for anything other than fingerprinting users in the four years > since Firefox introduced the API in 2012 (Firefox 10 [3]). Chrome added > support in 2014. > > We always have the option to make the API available to web content again > if a website or app demonstrates an interesting use case using Chrome's > battery API. However, I feel the supposed use cases for the battery API > would be better served by something like a lifecycle event API that > includes low battery/memory warnings. That would expose less identifying > information and allow the user and UA to customize the lifecycle settings. > > > [1] https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoU > Y-1k/9ybyzQIYCAAJ > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580 > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Late to the thread, but I'll use this reply to say we're very supportive of the proposal at CDT. On Mon, Apr 13, 2015 at 4:48 PM, wrote: > I have given this a lot of thought lately, and to me the only way forward is > to do exactly what is suggested here: phase out and eventually drop plain > HTTP support. There are numerous reasons for doing this: > > - Plain HTTP allows someone to snoop on your users. > > - Plain HTTP allows someone to misrepresent your content to the users. > > - Plain HTTP is a great vector for phishing, as well as injecting malicious > code that comes from your domain. > > - Plain HTTP provides no guarantees of identity to the user. Arguably, the > current HTTPS implementation doesn't do much to fix this, but more on this > below. > > - Lastly, arguing that HTTP is cheaper than HTTPS is going to be much harder > once there are more providers giving away free certs (looking at StartSSL and > Let's Encrypt). > > My vision would be that HTTP should be marked with the same warning (except > for wording of course) as an HTTPS site secured by a self-signed cert. In > terms of security, they are more or less equivalent, so there is no reason to > treat them differently. This should be the goal. > > There are problems with transitioning to giving a huge scary warning for > HTTP. They include: > > - A large number of sites that don't support HTTPS. To fix this, I think the > best method is to show the "http://"; part of the URL in red, and publicly > announce that over the next X months Firefox is moving to the model of giving > a big scary warning a la self-signed cert warning if HTTPS is not enabled. > > - A large number of corporate intranets that run plain HTTP. Perhaps a > build-time configuration could be enabled that would enable system > administrators to ignore the warning for certain subdomains or the RFC 1918 > addresses as well as localhost. Note that carrier grade NAT in IPv4 might > make the latter a bad choice by default. > > - Ad supported sites report a drop in ad revenue when switching to HTTPS. I > don't know what the problem or solution here is, but I am certain this is a > big hurdle for some sites. > > - Lack of free wildcard certificates. Ideally, Let's Encrypt should provide > these. > > - Legacy devices that cannot be upgraded to support HTTPS or only come with > self-signed certificates. This is a problem that can be addressed by letting > the user bypass the scary warning (just like with self-signed certs). > > Finally, some people conflate the idea of a global transition from plain HTTP > to HTTPS as a move by CA's to make more money. They might argue that first, > we need to get rid of CA's or provide an alternative path for obtaining > certificates. I disagree. Switching from plain HTTP to HTTPS is step one. > Step two might include adding more avenues for establishing trust and > authentication. There is no reason to try to add additional methods of > authenticating the servers while still allowing them to use no encryption at > all. Let's kill off plain HTTP first, then worry about how to fix the CA > system. Let's Encrypt will of course make this a lot easier by providing free > certs. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
If you're addicted to cleartrext, the future is going to be hard for you... On Tue, Apr 14, 2015 at 2:26 PM, wrote: > 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 > plaintext: http://arc.pasp.de/ The owners of websites like this have a right > to serve their pages in formats that do not make hypocrites of themselves. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
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 security. This is a false choice... you cannot have free speech without safe spaces. Many, many have written about this, e.g., https://cdt.org/files/2015/02/CDT-comments-on-the-use-of-encryption-and-anonymity-in-digital-communcations.pdf -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
+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 think Richard provided several > citations where this was believed to be correct, to the detriment of > us all (great cannon being a prime example). > >> and sites that serve >> legacy purposes and/or audiences, and cannot be updated to https in the >> first place. > > 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. Just as you have to feed it electricity and packets, you have to > maintain software too. > > The content issue is a serious one, but there are several answers that > could fit (HSTS, upgrade-insecure, and maybe opportunistic security). > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
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 and protecting her confidentiality (as best as is possible) > while doing the asking.Those are properties transport security gives you. > Sadly, both of those fundamental properties of transport are routinely > broken to the user's detriment, when http:// is used. Yes, I'll add something Patrick knows very well, but just to hammer it home: HTTPS as transport protection isn't just about confidentiality but integrity of the transport. So, even if those of you out there are saying "The web doesn't have much private stuff! jeez!" the web sure has a lot of stuff that is highly dynamic with javascript and other active content. That stuff needs be protected in transit lest the Great Cannon or any number of user-hostile crap on the net start owning your UAs, even if you don't think the content need be private. best, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update: Intent to Ship Adjust SDK in Fennec
On Wed, May 20, 2015 at 1:07 PM, Winston Bowden wrote: > > Adjust hangs onto the following data permanently: > > * Attribution source (allowing us to measure which channel produced >the best ROI) > * Storage of hashed MAC address and/or device ID hashes together with >app token nit: s/hashes/hashed/ here, no? That is Adjust will store a single hash performed as hash(hash(MAC/DeviceID) + App token) Correct? (Presumably this is to identify reinstalls or something.) best and thanks, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Web Authentication
+1 and thank you for all the hard work on the spec and landing so much in FF, JCJ!!! On Fri, Feb 8, 2019 at 4:09 PM J.C. Jones wrote: > Out of all multi-factor authentication solutions I know of, Web > Authentication is our best technical response to the scourge of phishing. > Tying public-key cryptography into web logins, it dramatically raises the > bar for phishing: From a simple confusable website and replay attack, to an > HTTPS network man-in-the-middle. In practice, Web Authentication forces > adversaries to move to attack account recovery methods, which often have > stronger controls than a standard login. > > The specification is large > <https://www.w3.org/TR/2019/PR-webauthn-20190117/>, with many backward > compatibility pieces that Firefox is likely to never need to implement. The > compatibility pieces are useful for providing the installed base of > existing FIDO or TCG devices a path forward. The core website functions > aren't so complex; Duo's explainer is very good, at > https://webauthn.guide/ > . There's also forward-extensibility, leading toward a password-less future > built on digital signatures rather than disclosing shared secrets. > > Web Authentication is now supported by Edge, Firefox, and Chrome. Safari > support is experimental. > > Websites have been slower to pick it up. Major sites I now of: For the > United States, https://login.gov/ uses it -- so as an example applying for > the Global Entry traveler program will exercise a Web Authentication > security key, if you choose. Dropbox > < > https://blogs.dropbox.com/tech/2018/05/introducing-webauthn-support-for-secure-dropbox-sign-in/ > > > has also supported Web Authentication since Firefox 60 shipped. > > Most other major properties have indicated they'll support Web > Authentication sooner or later. Try it out at at https://webauthn.io/, > https://webauthndemo.appspot.com/, https://demo.yubico.com/webauthn/, or > even the lowly https://webauthn.bin.coffee/. > > I encourage Mozilla to support advancement of Web Authentication to a > Recommendation, and its end-goal of a phishing-free future. (Or at least, a > much-reduced prevalence. Really, I just wanted to write and imagine > 'phishing-free.' Can you blame me?) > > Cheers, > J.C. > [n.b., I'm an editor on this spec...] > > > > On Thu, Jan 31, 2019 at 5:58 PM L. David Baron wrote: > > > A W3C Proposed Recommendation is available for the membership of > > W3C (including Mozilla) to vote on, before it proceeds to the final > > stage of being a W3C Recomendation: > > > > Web Authentication > > https://www.w3.org/TR/webauthn/ > > Deadline for responses: Thursday, February 14, 2019 > > > > If there are comments you think Mozilla should send as part of the > > review, please say so in this thread. Ideally, such comments should > > link to github issues filed against the specification. (I'd note, > > however, that there have been previous opportunities to make > > comments, so it's somewhat bad form to bring up fundamental issues > > for the first time at this stage.) > > > > Given that we implement this specification, one of the editors works > > for us, and have been supporting this work for a while, I'm assuming > > we should support this advancement as well... > > > > -David > > > > -- > > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > > Before I built a wall I'd ask to know > > What I was walling in or walling out, > > And to whom I was like to give offense. > > - Robert Frost, Mending Wall (1914) > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Don't miss out! CDT's Tech Prom is April 10, 2019, at The Anthem. Please join us: https://cdt.org/annual-dinner/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
Thanks for being flexible here in the face of adversity, big fan of running trains even if it seems icky in the short term. On Wed, Mar 27, 2019 at 1:00 PM JC Jones wrote: > On Tuesday, March 26, 2019 at 12:50:21 PM UTC-7, Alex Gaynor wrote: > > Simply flipping the pref, and not including register support seems a bit > > unfortunate, as it'll leave some websites in a works-sometimes state. > While > > some larger sites have UIs and help articles explaining that Firefox > works > > for login but not reigstering a key, many will not. If it's possible to > > include register support in what rides the train, that seems preferable. > > I'm sorry to be unclear. I'm intending to include the register support as > well. > > I have filed Bug 1539541 [0] to do this work: > > Enable the security.webauth.u2f by default, to ride the trains > > Remove the aOp == U2FOperation::Sign check from EvaluateAppID in > WebAuthnUtil.cpp, permitting the Google override to work for Register as > well as Sign. > > Further discussion is still welcome, either here or on the bug. > > > [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1539541 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Don't miss out! CDT's Tech Prom is April 10, 2019, at The Anthem. Please join us: https://cdt.org/annual-dinner/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Media Working Group
(Mozilla fan boy here, not an employee) Just to chime in that a number of us involved in the last great W3C EME/DRM fight are going to chime in that we'd like to see protections for security researchers that do privacy and security work on browsers, specs, etc. The idea that didn't go very far last time was a "litigation non-aggression covenant" that would forbid any W3C member contributing to the spec to threaten or file suit against security researchers working in this area. As you can see, last time this didn't end well and resulted in the EFF exiting W3C (IIRC): https://lists.w3.org/Archives/Public/public-html-media/2017Jun/0015.html It seems important to have these conversations, but I must admit the apetite to actually hammer out such a thing will not be big (imagine trying to revise or propose a patent agreement, no one likes that). best, Joe On Mon, Apr 8, 2019 at 4:22 PM L. David Baron wrote: > The W3C is proposing a new charter for: > > Media Working Group > https://www.w3.org/2019/04/media-charter-draft.html > https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0003.html > > Mozilla has the opportunity to send comments or objections through > Friday, May 3. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. > > Given that we implement a number of the specifications the group > will maintain, and are likely to implement others, we should almost > certainly express *some* opinion on this charter, even it is just > support. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
