Funny to see Google and Mozilla siding on ethical issues. It really seems like the W3C has finally lost its compass and now wants to venture into the blockchain. Only positive thing is to see Google loosing once in a standards fight, however, I think it might just have been the wrong anarchist endeavour inside the W3C. In the end we will get more centralisation because looks like nobody except the big ones can push standards on a technical decent level (indirectly pushing their agenda).
> Funny to see Google and Mozilla siding on ethical issues
It's not the first time Google and Mozilla sided together against the W3C on web standards, and the last notable time resulted, over time, in the W3C ultimately being displaced from any role in the HTML and DOM standards.
The standards group that implementers listen to (which, for some reason, seems to be the one that listens to implementers, when there are competing options) is the only one that matters, in practice.
> It's not the first time Google and Mozilla sided together against the W3C on web standards, and the last notable time resulted, over time, in the W3C ultimately being displaced from any role in the HTML and DOM standards.
> Only positive thing is to see Google loosing once in a standards fight
It is far from the first time. For instance, Google was involved in the WHATWG, which developed the HTML standard while the W3C pushed XHTML.
The standards war, itself, is only lost when nearly nobody uses the standard, which is what happened to XHTML, which lost to WHATWG’s HTML when browsers simply didn’t use XHTML.
It sounds like a lot of cryptocurrency companies wish to prop up this standard, but it is not clear to me that actual people would use it for a non-circular goal.
All browsers implement XHTML. It's referred to as "the second concrete syntax for HTML" in the WHATWG spec.[1]
Indeed many websites do use XHTML, the HTML application of XML. However, since proper documents render identically, you won't be aware that you're visiting an XHTML site - that is, unless you check the source.
Fun history side note: Browsers like Netscape and Internet Explorer didn't agree on how to parse HTML in the past. They handled omitability differently, for example, in overlapping hierarchies (<p><b></p></b>). To fix this mess, Sir Tim asked well-respected SGML practicioners to create a clean subset of SGML and define a document type definition (DTD) for HTML. They came up with XML, the clean subset, and XHTML, the DTD. [2]
Basically, XHTML was the first actual standardization of HTML. Unfortunately, minor syntax errors will prevent a XHTML document from rendering, which, to some degree, is probably why it was never widely accepted by developers.
Internet Explorer did not. It completely refused to render XHTML pages served with an XML MIME type (application/xhtml+xml). It would only display pages if they were served with the text/html MIME type, which meant that none of XML’s vaunted features (such as strict parsing) came into play, and such pages were effectively treated as “HTML with syntax errors.”
A big part of why WHATWG was able to dethrone W3C was W3C’s insistence on dropping HTML in favor of XHTML when the overwhelmingly dominant browser of the time had zero support for it.
> They came up with XML, the clean subset, and XHTML, the DTD. … Basically, XHTML was the first actual standardization of HTML.
No, the first formal HTML standard was 2.0 (RFC 1866), which was released in November 1995 and had a DTD that among other things disallowed overlapping hierarchies. XML’s first draft was released a full year later (November 1996), and the first W3C spec was XML 1.0 in 1998. Later that year came the initial drafts for XHTML 1.0, which was a straightforward translation of HTML 4.0 to XML.
The outcomes of decentralization sound good until you realize it means you’re either running your own server, or using a blockchain and need to protect a private key somehow. But normal humans want nothing to do with either of those responsibilities and always rely on a centralized service.
If this ID standard included a way to use a centrally-controlled email address (the defacto ID standard today that works just fine for most legal activities) or a social login then maybe some of the bigger players would be onboard and it would take hold. As is it seems like it’s just gonna be another crypto fad.
Yes, but the universal ability to create authentic sources of data means people will use what is convenient but always have the option to go to the base layer without permission should they dislike their service.
I don't buy this idea that average people can't manage a keypair. Humans already manage secrets in the form of passwords, it's not that much different.
In the worst-case scenario in which users defer to some weak/centralized system, how is that categoricially worse than the centralized systems we already have?
> Humans already manage secrets in the form of passwords, it's not that much different.
Humans are bad at this which is why we recommend password managers.
That said, I do think keypairs are the way forward, I just also think they need either strong integrated software support in whichever device is being used, or strong external hardware support.
(Yubikeys are nice because they kind of extend the “key” metaphor that people are already used to, but I wish they shipped with a paired backup key that was provisioned with the same key material. Maybe colored red to distinguish it.)
> but I wish they shipped with a paired backup key that was provisioned with the same key material
Two identical keys, is less secure, for those who would otherwise have bought many different keys.
If you instead buy two different keys, then, when you lose the first, you can know it's safe to continue using the second one. And you can block the first one, without locking yourself out.
Maybe getting two different keys would be a good idea
The trouble with this is that you need the second key present each time you need to enroll it to an account, meaning you can’t stash it in a safe deposit box as a backup. And you have to remember to add it to each and every account or it’s not really functional as a backup.
Yes, two different keys are more secure, but they have some pretty severe usability problems.