From my testing of several hardware U2F implementations, the test-of-user-presence (touching the button) unlocks the device for an amount of time. During this time multiple authentication/registration will succeed without further user interaction. Even without this behavior though, hardware tokens don't indicate which site your authenticating with. Malware could just make an authentication request right as some user action triggers a legitimate authentication request.
I've only tested on Sierra, so I'm not terribly surprised that this doesn't work. Would you mind opening an issue so I can help debug? https://github.com/github/SoftU2F/issues/new
My understanding is that the FF softtoken was intended to be temporary while they worked on their HID support. That might not be the case any longer though.
I think the greatest practical threat to TOTP is phishing. U2F, regardless of where keys are stored, binds a keypair to an origin. Only authentication requests from `github.com` can use the `github.com` keys. For my money, any U2F implementation is a win over any TOTP.
There is a known bug where leading whitespace can cause the key to not be parsed. Also, check that you're only trying to upload a single key, and not your entire keyring.
It shouldn't be necessary to push a new signed commit for old ones to start showing the "verified" badge. We do cache some of our templates though, so it may take a while for some pages to be updated.
This isn't a concern with our implementation because a hash of the asset bundle is also included in the URL. This is a pretty common cache-busting technique for static assets and lets you send more aggressive cache directives to the browser.
This is a separate issue. We just added the Private Token feature on the /settings/applications page. This is essentially a password, so we wanted to make sure that it required password confirmation. This will be behind sudo mode later today hopefully.
It would, but it would create other problems also. If I were to link to a raw.github.com URL on HN, it would be disallowed because the Referer header would be "incorrect".
Alternative this is much more sneaky: run an obfuscated tunnel. Most firewalls will allow egress DNS for example, so tunnel your TCP over DNS. This will also allow you to sneak out of pay-for wifi setups like at the airport. http://analogbit.com/software/tcp-over-dns