[webkit-dev] Implementing Universal Second Factor (U2F)

Michael Catanzaro mcatanzaro at igalia.com
Wed Feb 22 07:17:40 PST 2017

On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote:
> The (USB) protocol itself works by sending USB HID reports (packets)
> to the key and getting USB HID reports back. There is a reference
> implementation by one of the members of the specification group -
> libu2f-host (by Yubico); however, it is licensed under GPL and
> LGPLv2.1.


According to the documentation:

"The library and command-ine tool is licensed under the LGPLv2+
license. Some other files are licensed under the GPLv3+ license."

Sounds like a perfectly acceptable dependency for WebKit. The only
trick is that if you need to import the source code under
Source/ThirdParty (hopefully not), then you'd need to remove all the
GPLv3+ files from the repository.

> - What to do about other platforms - no implementation, use libu2f-
> host for them, or use libu2f-host everywhere

Ideally we would use the same code on all platforms unless there is a
strong reason not to do so, to reduce the amount of platform-specific
bugs. I'm not sure if there exists such a situation here, so using
libu2f-host on all platforms seems to make the most sense. Possible
examples of strong reasons to diverge:

 * If removing the GPLv3+ files would be somehow problematic. GTK+ port
doesn't care so long as none of the GPL files are used by the library
itself. Apple is much stricter; I guess they might not allow the files
to be imported into internal build systems. That could create a
maintenance headache.
 * If the extra dependencies are problematic for some platform. You'd
be hard-pressed to find a Linux system without libusb, and hidapi and
libu2f-host both look unproblematic. But adding your implementation
directly to WebKit might be easier for Mac ports.

> - UI for key access permission - malicious sites could (eventually)
> lock up a key, as well as possibly identifying a user; the
> specification suggests displaying an info bar for user to allow
> access - but, I’m not familiar with the process of designing/adding
> browser chromes

Sounds like WebKit should request a policy decision from the client on
whether to allow a website to use the U2F API? Then making that
decision in a secure manner is the responsibility of the client to
figure out. In Epiphany we display info bars the first time a
particular security origin requests a permission, and remember the
user's choice in the future.

> - What process should communicate with the token - the protocol is
> robust and designed for many simultaneous accesses and appropriate
> isolation of them, so this can (should?) be per-page; IOKit needs a
> CFRunLoop to schedule the report receive callback on: should this be
> on the main runloop or on another thread just for U2F?

I don't know which process, but you should use the main runloop. Let's
avoid creating a new always-running thread for a feature that will
rarely be used.

> - Presumably, this should be gated behind a macro; does a suitable
> one exist, or add a new one?

You'll have to add a new one, ENABLE_U2F. It's better not to gate
features when possible, but in this case one will be required due to
the new dependencies as we want to allow distributions that do not have
the new dependencies to continue to build without them (with reduced
feature set) for the next few years.


More information about the webkit-dev mailing list