[frut]

This is just depressing. Sure, sell us out to big corporations by not implementing proper features in protocols like HTTP/2 so we can get tracked for decades to come. Yet, represent freedom by yet another cool way to "fool" governments. When historians look back at what happened to the Internet, or even society, they are going to find that organizations like the IETF was to busy with romantic dreams of their own greatness to serve the public. It's like people leaned nothing from Snowden.

[pjc50]

> sell us out to big corporations by not implementing proper features in protocols like HTTP/2 so we can get tracked

What are you referring to here?

[frut]

Authentication mostly. The lack of which is the major reason why the majority of us are still typing passwords into boxes in the browser and send them over the Internet in contradiction to best practices. Doing away with that would potentially solve a lot of problems, like phishing, but also replace cookies. Meaning it would be much harder to track users across the Internet threatening not only the revenue of major player but also their dominance since being able to handle security issues is a major advantage for them. So instead of fixing the problem at the source, we have security people recommending password managers and the EFF making cookie blockers.

Essentially every geek I have ever talked to support standards, decentralization, community efforts etc. Yet, here we have the company that has more influence than anyone else over the Internet almost single-handedly designing the protocol.

[wmf]

Google gave us HTTP/2 but they also gave us U2F. But they didn't give us soft U2F so everyone still uses passwords instead.

[ryukafalz]

There's already a protocol for that[0], just almost nobody's using it. Which is a real shame, because with a cleaner UX and more adoption it could be a serious win.

[0] http://webid.info/

[ubernostrum]

Mozilla tried with Persona (née "BrowserID"), which had similar goals. It didn't go anywhere, even with Mozilla's support behind it.

[xingped]

What features are missing that should be implemented?

[teddyh]

Not the OP, but omitting support for SRV records in HTTP/2 was a terrible missed opportunity, as I’ve written about here before:

https://news.ycombinator.com/item?id=8404788

https://news.ycombinator.com/item?id=8550133

I quote myself: “It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else.”

[Shoothe]

I would also like to see SRV record support in HTTP/2 but IIRC Mozilla did some telemetry tests and found out that a significant amount of DNS requests for SRV records failed for no reason (or probably for reasons mentioned in this submission). Unfortunately I can't find a source link for that claim right now.

[teddyh]

I know of two rather large users of SRV records already: Minecraft servers and (the big one) Microsoft Office 365. I’m less than convinced that resolution of SRV records is that broken.

[Shoothe]

Do you mean accessing Office 365 via browser uses SRV records or something different?

[dylz]

o365 general services (lync skype, outlook, ... / exchange autodiscover) uses SRV a fair bit.

365 is not just the browser suite

[stock_toaster]

Yeah, I agree that this was a really unfortunate omission.

[Shoothe]

Support for Client Certificates.

[slrz]

Heh? People use client certificates with HTTP2 all the time. Is that nonstandard?

[Shoothe]

Are you sure it's HTTP2 or just HTTP2 that was downgraded to HTTP1.1 over TLS? Last time I checked client certs did not work on HTTP2 due to multiplexing see e.g. https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...