Re: Intent to implement and ship: FIDO U2F API
On Wednesday, December 2, 2015 at 2:23:28 AM UTC+1, Richard Barnes wrote: > 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. We are proposing to implement the FIDO U2F API in Firefox in its > current form and then track the evolving W3C standard. > > Background: The FIDO Alliance has been developing a standard for > hardware-based user authentication known as "Universal Two-Factor" or U2F > [2]. This standard allows a website to verify that a user is in possession > of a specific device by having the device sign a challenge with a private > key that is held on the hardware device. The browser's role is mainly (1) > to route messages between the website and the token, and (2) to add the > origin of the website to the message signed by the token (so that the > signature is bound to the site). > > Several major websites now support U2F for authentication, including Google > [3], Dropbox [4], and Github [5]. Axel Nennker has filed a Bugzilla bug > for U2F support in Gecko [6]. The W3C has begun the process of forming a > "WebAuthentication" working group that will work on a standard for enhanced > authentication using FIDO as a starting point [7]. > > Proposed: To implement the high-level U2F API described in the FIDO JS API > specification, with support for the USB HID token interface. > > Please send comments on this proposal to the list no later than Monday, > December 14, 2015. > > - > > Personally, I have some reservations about implementing this, but I still > think it's worth doing, given the clear need for something to augment > passwords. > > It's unfortunate that the initial FIDO standards were developed in a closed > group, but there is good momentum building toward making FIDO more open. I > have some specific concerns about the U2F API itself, but they're > relatively minor. For example, the whole system is highly vertically > integrated, so if we want to change any part of it (e.g., to use a curve > other than P-256 for signatures), we'll need to build a whole new API. But > these are issues that can be addressed in the W3C process. > > We will continue to work on making standards for secure authentication more > open. In the meantime, U2F is what's here now, and there's demonstrated > developer interest, so it makes sense for us to work on implementing it. > > Thanks, > --Richard > > [1] https://fidoalliance.org/ > [2] https://fidoalliance.org/specifications/download/ > [3] https://support.google.com/accounts/answer/6103523?hl=en > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/ > [5] > https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 > [7] http://w3c.github.io/websec/web-authentication-charter Nearly two months since that post... Any news on this ? a) on Mozilla Foundation joining FIDO Alliance? b) on FIDO U2F implementation inside Firefox Core? Thanx. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner future and ownership
On Wednesday, July 29, 2015 at 2:30:54 PM UTC-4, Benjamin Smedberg wrote: > The Mozilla project no longer sees XULRunner as a priority project. It's > not core to advancing the open web or any of our current or planned > products. > I'm looking at creating a simple XUL app as a way of replacing Open Web Apps which just found their way onto the chopping block. My plan is to try to create a shim that will run firefox with the -a argument. Is this going to keep working, or is that going to break when XULRunner gets turned down? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unsafe CPOWs are about to be outlawed in browser code
The spaghetti was put in the machine last night - this work has now landed on mozilla-central. If you start seeing "unsafe CPOW usage forbidden" in the Browser Console for various things, please mark them blocking bug 1233497. Thanks all, -Mike On 20/01/2016 3:54 PM, Mike Conley wrote: > (cross-posted to both dev-platform and firefox-dev) > * > * > TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost > all browser code. Unsafe CPOWs inside add-on scopes should continue to > work properly. If you start seeing "unsafe CPOW usage forbidden” errors > being throw for a feature you’re working on in the Browser Console, it’s > because unsafe CPOWs have been outlawed and you should stop using them. > Talk to me if you run into problems. > > Details: > > “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process > is not currently blocked waiting for information from you. For example, > if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when > the content process is garbage collecting, the parent will be blocked > until the child decides that it has a moment to service the synchronous > message and return the information that the parent needs. Unsafe CPOWS > are generally pretty horrible for performance, especially because we > cannot know what state the other process is in. > > “safe” CPOWs are when the other process is in a known blocked state - > for example, the content process sends a synchronous message to the > parent asking for some information, and is blocked waiting for a > response. The parent then accesses CPOWs in the content process safely, > because the content process is in a known state. The only overhead here > is the IPC traffic. > > “unsafe” CPOWs are often used by add-ons to synchronously manipulate > content. A year or so back, a bunch of browser code also used unsafe > CPOWs in this way, but we’ve been slowly but surely weeding them out. > We’re at the state now where we believe we’ve eliminated most of the > in-browser unsafe CPOW uses[3]. > > Within the next day or so, I’m going to be landing bug 1233497[4] which > will cause unsafe CPOW usage in non-addon browser code to throw. In the > event that this breaks things horribly, there is a pref[5] that we can > flip to turn unsafe CPOWs back on while we fix things. > > Again, this work is occurring in bug 1233497[4]. If there are any major > concerns, please bring them up here before I throw the spaghetti into > the machine. > > For more details on unsafe CPOWs, please read [1] and/or [2]. > > [1]: > https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/ > > [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/ > [3]: Outside of tests, and a few other little things that there are > follow-ups for. > [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497 > [5]: dom.ipc.cpows.forbid-unsafe-from-browser > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MozReview interdiffs, was Re: Just Autoland It
On 01/26/2016 07:49 PM, Karl Tomlinson wrote: Boris Zbarsky writes: On 1/23/16 9:48 PM, Mike Hommey wrote: Note that if /other/ changes from other bugs have happened to the same files between the last reviewed iteration and the rebase before landing, the interdiff will show them without any kind of visual cues. Ah, that's unfortunate. I agree that this is a hard problem, though (interdiff across rebases). I guess that does mean that you can't really use the final attached thing for the "I want to see the interdiff" use case; need to push something to MozReview before rebasing to address that. Yes, from the reviewing efficiency perspective, it is best to push MozReview updates for re-review on the same base revision. i.e. separate from the rebase/landing process. That may be difficult to do in some cases, though it does seem useful to keep in mind. If you happen to be using obsolescence markers, is this fixable? As in, if you have a patch P based on upstream U: U -> P that you then amend U -> P' U -> [P] => P' # double arrow => shows successor relationship, [brackets] show obsolete revs and before re-uploading, rebase onto a new U' U -> [P'] U -> [P] => [P'] [P'] => P'' U -> U' -> P'' then the interdiff you want is between P and P', which you can get by looking at the re-uploaded patch (P'') and finding a precursor with a parent rev matching the parent rev (U) of the previously uploaded patch (P). Except you might have done it the other way, by rebasing first, in which case you would have U -> [P] => [P'] U -> U' -> [P'] [P'] => P'' U' -> P'' in which case you want the interdiff between P' and P''. I think there you need to categorize successors as due to rebases vs due to changes, and you can detect a rebase because the parent rev is different. So in general, you ought to be able to look through the precursor chain to find a non-rebase precursor, and use that as your interdiff? In this case, the precursor of P'' is P', and parent(P'')=U' is parent(P') is also U', so you use that diff. In the previous example, parent(P'')=U' is not parent(P'), so that's a rebase, so then you ignore that change and look at P' vs P. Their parents are the same, so you use them. And last, if you re-upload the same patch, just rebased, then it would get back to your original patch before finding a pair with the same parent, and so the interdiff is empty. I've *almost* managed to convince myself that I'm not completely crazy with the above algorithm; have I convinced anyone else? Or maybe it's just a well known fact that if you have precursor/successor relations, then interdiffs are "solved"? It's never going to be 100% pretty, because you may end up doing violence to a patch when resolving merge conflicts from rebasing. Perhaps MR should show all precursor diffs, but label the rebase ones as such? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Just Autoland It
Honza Bambas writes: > On 1/25/2016 20:23, Steve Fink wrote: >> For navigation, there's a list of changed files at the top >> (below the fixed summary pane) that jumps to per-file anchors. > > Not good enough for review process. > >> Are you saying you want tabs or something for this (like >> splinter uses)? I'd certainly like something less sluggish, but >> maybe that's just my browser again. > > Yes please. Having one file on the screen at a time is very > useful. The next/previous file/comment keyboard shortcuts may be useful in the meantime. https://www.reviewboard.org/docs/manual/2.5/users/reviews/reviewing-diffs/#keyboard-shortcuts ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
