3 ms·

>QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is p

>QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".

jrockway 4y ago
I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
superkuh 4y ago
You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
- WHATDOESIT 4y ago
  Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.

jrockway 4y ago

I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.

superkuh 4y ago

You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.

WHATDOESIT 4y ago
Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.