W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2018

Re: [webauthn] None hardware/device option - as for ssl client certificates

From: Markus Schräder via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Aug 2018 15:24:57 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-411446162-1533741896-sysbot+gh@w3.org>
> > I also think that it is just unethical to force users to buy hardware to get security [...]
> Again, note that we expect that TPMs and secure enclaves built into laptops, mobile devices etc. will be usable as WebAuthn authenticators. We do not expect every user to buy an external authenticator - most will likely just use the ones already built into their iPhones and Android devices.
> The main drawback of software authenticators ...

Its a non-evidenced claim that there will be TPs or anything like that at a users. The current design of the document and the implementations currently still means:

> **Everybody needs to buy a token for at least 15$ got get security!**

Yeah, software protection is less good then hardware protection. But this is not the point!

**This is just abuse of the power by the joining of the four big browser vendor against the users.**

This is not the first thing you just do as you want against the users, Google is generating in Chrome big problems with QUIC against traffic shaping its own fq-codel mechanisms, so we must installed provider wide a filter against Port 443 and 80. Firefox is removing the keygen tag - the last possible way to import client certificates on windows, without a repacement and forcing users to buy hardware.

You just are breaking the internet down, and violate standards and establised protocols - cause you can.

This means to be evil.

GitHub Notification of comment by pRiVi
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1027#issuecomment-411446162 using your GitHub account
Received on Wednesday, 8 August 2018 15:25:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:54 UTC