Earlier quoted context omitted.
It can seem confusing but it all makes sense when you realise Chrome is designed to work for Google, not for you. I remember people switching their Grandmas to Chrome 15 years ago when they could've chosen Firefox. Many of us knew this would happen, but convenience and branding is everything, sadly.
I don't really think Firefox cares about having users. The one killer feature Chrome has is being able to access all your state by logging into your Chrome account. Firefox refuses to provide this basic service which will allow you to seamlessly use your data on Firefox and then eventually stop using Chrome. I wish Firefox nothing but the worst.
Mitmproxy 11: Full HTTP/3 Support
61–70 of 80 posts
Re: Mitmproxy 11: Full HTTP/3 Support
#62Only slightly related ... > Chrome does not trust user-added Certificate Authorities for QUIC. Interesting. In linked issue chrome team says: > We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP inst…
Those proxies tend to be strict in what they accept, and slow to learn new protocol extensions. If Google wants to use Chrome browsers to try out a new version of QUIC with its servers, proxies make that harder.
Re: Mitmproxy 11: Full HTTP/3 Support
#63Only slightly related ... > Chrome does not trust user-added Certificate Authorities for QUIC. Interesting. In linked issue chrome team says: > We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP inst…
Re: Mitmproxy 11: Full HTTP/3 Support
#64Earlier quoted context omitted.
If I were to guess, it's to allow Google freedom in experimenting with changes to QUIC, since they control both the client and large server endpoints (Google Search, Youtube etc). They can easily release a sightly tweaked QUIC version in Chrome and support it on e.g Youtube, and then use metrics from that to inform proposed changes to the "real" standard (or just continue to run the special version for their own stuf…
Companies that use something like Zscaler would be highly likely to block QUIC traffic to force it onto TCP.
Re: Mitmproxy 11: Full HTTP/3 Support
#65Earlier quoted context omitted.
He was arguing about 99.99% of users being people that cannot use your stuff because chrome doesn't allow the use of snakeoil / self signed certs for QUIC, specifically, and TLS encryption is mandatory. If you compare that to the graceful Connection: Upgrade handshake in http/1.1 and websockets, for example, this would've been much better because there is no isolation based on tools and libraries, only based on trust…
Then the OP used a bad framing, because it was apparent to me that they opposed QUIC in general, not QUIC in Chrome. Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads.
"HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was impacted by the lost packet." (Wikipedia)
I'm a text-only browser user; I also use TCP clients with a localhost TLS forward proxy. When I visit a website I only request resources manually and only from a single domain at a time. This works great for me. But obviously it is not compatible with ads. This is because ads requires websites that cause so-called "modern" browsers to automatically request resources (ads) from multiple domains "simulataneously", i.e., "in parallel". As such, I see no ads. Not a problem, I can live without them.
However, for those who let these browsers request ads automatically, there are problems. "The web", as they experience it, gets slower. Because although the requests to multiple domains may be executed "simultaneously", and the HTTP/1.1 protocol allows for pipelining requests, these browsers cannot process the responses that arrive out of order.
HTTP/1.1 pipelining does work. Outside the browser, when requesting non-advertising resources, for example. I have used HTTP/1.1 pipelining outside the browser for over 20 years. It works beautifully for me. I am only requesting resources from a single domain and I want the responses in order. So, right there, we can see that HTTP/3 is addressing the needs of advertising companies and their partners rather than web users who are reqesting non-advertising resources like me.
As the web became infested with ads/tracking and became slower as a result, the ad companies and CDNs, e.g., Google and Akamai, sought to "make the web faster" by introducing a new HTTP protcocol for the so-called "modern" browser. (This browser, as we know, is more or less under the control of an advertising company, the same one introducing the protocol.)
Now, a web user (cf. institutional player in the online advertising industry) might conclude the easiest way to "make the web faster" is to remove what is making the web slow: ads.
But the "solution" chosen by the advertising company was to keep the ads and try to make it easier for the so-called "modern" browser to process out-of-order responses from multiple domains, e.g., ad servers, faster.
Will HTTP/3 and its use of QUIC "lead to ads". That is for the reader decide. I think it is safe to say it will not lead away from them and it could help cement the ad infestation of the web even more.
tl;dr HTTP/1.1 is optimal for sequential information retrieval from a single domain. HTTP/3 is optimal for resource, e.g., advertising, retrieval from multiple domains "simultaneously".
Re: Mitmproxy 11: Full HTTP/3 Support
#66Earlier quoted context omitted.
Then the OP used a bad framing, because it was apparent to me that they opposed QUIC in general, not QUIC in Chrome. Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads.
"Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads." "HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recove…
The ad company created QUIC to make HTTP/3 possible. That's also certainly true.
What follows: the ad company created QUIC because they wanted to make ads easier.
But "QUIC exists to improve ad deliverability" is true only in the shallowest of senses, similar to "nuclear power plants exist to drop bombs on civilians" just because research on nuclear power was driven in large part by war needs. In reality, nuclear power has its own uses beyond the military.
Similarly, QUIC taken on its own merits does not have anything to do with ads. It's just another general purpose protocol.
BTW, multiple streams will not make it any faster to load ads from third parties. Head-of-line blocking only affects resources within a single TCP connection, which can only ever be to one server. That means QUIC's streams do nothing to make loading Google's third party ads easier.
Re: Mitmproxy 11: Full HTTP/3 Support
#67Earlier quoted context omitted.
It can seem confusing but it all makes sense when you realise Chrome is designed to work for Google, not for you. I remember people switching their Grandmas to Chrome 15 years ago when they could've chosen Firefox. Many of us knew this would happen, but convenience and branding is everything, sadly.
I don't really think Firefox cares about having users. The one killer feature Chrome has is being able to access all your state by logging into your Chrome account. Firefox refuses to provide this basic service which will allow you to seamlessly use your data on Firefox and then eventually stop using Chrome. I wish Firefox nothing but the worst.
If you're going to say that Firefox doesn't care about having users, point out its just stunningly stupid memory usage, blatantly stale developer tools (that one hurts me the worst because the Chrome dev-tooling is actually open source, so there's nothing stopping them from actually having Best In Class dev tooling other than no-fucks-given), or the har-de-har-har that comes up periodically of bugs that have been open longer than a lot of developers have been alive
1: https://github.com/mozilla-services/syncstorage-rs#running-v...
Re: Mitmproxy 11: Full HTTP/3 Support
#68Re: Mitmproxy 11: Full HTTP/3 Support
#69is mitmproxy an alternative to fiddler?
Re: Mitmproxy 11: Full HTTP/3 Support
#70Earlier quoted context omitted.
Then the OP used a bad framing, because it was apparent to me that they opposed QUIC in general, not QUIC in Chrome. Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads.
"Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads." "HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recove…