If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.
Comments
If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.