5 ms·

Because IE6, Outlook-Web/Hotmail and Windows Mobile were so much better, right? I understand your POV, but this has nothing to do with Google specifically. Noth

Because IE6, Outlook-Web/Hotmail and Windows Mobile were so much better, right? I understand your POV, but this has nothing to do with Google specifically. Nothing has changed structurally since 10 years ago, the game is the same as it always was. The Internet will detect damage and route around it, as usual.

wahern 8y ago
The brain damage caused by Outlook/Exchange and IE remain with us. The brokenness and complexity don't go away; it slowly grows, making it increasingly difficult for decentralized communities, and increasingly easier for large corporations, to take the reigns. In many respects the Internet doesn't route around damage so much as accumulate damage. And that's partly the result of apologists within the engineering community endlessly excusing Google (and more recently Mozilla), as well as increasingly greater numbers of engineers having no memory or even conception of running fundamental services independently. As the base layers become increasingly complex economies of scale increasingly prefer centralization, both in design and especially implementation. There will always be competition. In many respects Cloudflare is a breath of fresh air, pushing against the stampede to AWS. Likewise, Mozilla viz-a-viz Chrome. But there are certain interests that large players will always share to the detriment of small organizations and individuals. DoH and DoT embedded in the browser intrinsically favor large organizations, and specifically Google and Cloudflare. And why do they promote DoH and DoT in the browser rather than promoting it at the system level (i.e. in Windows, Systemd, etc)? Because it's (a) less costly for them and (b) furthers their competitive commercial interests in their battle with other large organizations. One reads endless apologia on HN about how people would rather send their DNS requests to Cloudflare and Google rather than their ISP, as if those were the only realistic options, and no matter that doing so doesn't require delegating even more functionality to the browser oligopoly. They've already given up. They see their own role as choosing sides as consumers rather than actively participating as producers of these technologies, which is so utterly depressing from the perspectives of preserving an open internet and promoting free software. (For example, web developers are fine with DoH because they don't see how it effects their own server-side and client-side development. It doesn't matter to them that it would make it increasingly difficult to independently implement and maintain the software and systems--they're just consumers. QUIC? Not their concern--that's the responsibility of nginx and node.js, no matter that those projects likely never could have been founded outside large corporations if they first had to climb the steep hill to HTTP/3 and QUIC.) How do we stop this? By keeping an eye on long-term goals. While IPv6 and DNSSEC are more complex than some alternatives, from a long-term perspective they minimize overall complexity and substantially preserve independence, such as it is. Some options are even more clear cut: push DoH and DoT into the system resolver (and OpenBSD is doing, and projects like unbound and even, IIRC, systemd already support).
- dagenix 8y ago
  > While IPv6 and DNSSEC are more complex than some alternatives I'm not sure what you are getting at. IPv6 is pretty similar to IPv4 - and in some ways simpler - and I'm not aware of any other alternative. And I don't really see how DNSSEC (or IPv6) relates to anything else you are talking about - DoH addresses a different use case.
  - wahern 8y ago
    I intended them as general examples of people pushing against certain kinds of change in favor of simpler short-term options that favor or preserve centralization and complexity. I agree IPv6 does make many things simpler, but moving to IPv6 can be difficult and introduces some additional complexity (e.g. link-local addresses, shift away from DHCP, etc). The argument against IPv6 is that NAT is simpler if only because NAT is already the status quo, and we already have "solutions" to deal with the limits of small address spaces. How many people use Cilium with IPv6 transport instead of UDP over IPv4 over VXLAN?[1] Local DNSSEC doesn't solve ISP confidentiality but it does prevent NXDOMAIN substitutions, which is one of the biggest immediate benefits for browser-based, default-enabled DoH/DoT. And one argument for doing DoH/DoT to centralized servers rather than locally is that it partly obviates the need for DNSSEC--it's "simpler" because it doesn't depend on orchestrating larger infrastructure changes. (I guess the logic is that without DNSSEC centralization is inevitable anyhow, and if people are convinced that ubiquitous DNSSEC will never come than doing DoH/DoT in the browser vs at the system resolver is a distinction without a difference. A poor argument but implicit nonetheless.) [1] At work I suggested Cilium with IPv6 and IPsec for policy and LAN confidentiality of K8S clusters but everybody thought I was nuts and favored Cilium's UDP+IPv4+VXLAN mode and transparent Istio proxies for automagic mutual TLS. Why? Because it's what they know and understand and they can reasonably expect everybody else will make the same judgment. It's ultimately a much more complex, error prone, less performant, and less flexible approach but it's the path of least resistance. And in the long-term the complexity will mean proprietary managed solutions will prove that much more enticing, an irony apparently invisible to people who believe K8S will keep them independent of AWS, Azure, etc,
    - 8y ago

wahern 8y ago

The brain damage caused by Outlook/Exchange and IE remain with us. The brokenness and complexity don't go away; it slowly grows, making it increasingly difficult for decentralized communities, and increasingly easier for large corporations, to take the reigns. In many respects the Internet doesn't route around damage so much as accumulate damage. And that's partly the result of apologists within the engineering community endlessly excusing Google (and more recently Mozilla), as well as increasingly greater numbers of engineers having no memory or even conception of running fundamental services independently. As the base layers become increasingly complex economies of scale increasingly prefer centralization, both in design and especially implementation. There will always be competition. In many respects Cloudflare is a breath of fresh air, pushing against the stampede to AWS. Likewise, Mozilla viz-a-viz Chrome. But there are certain interests that large players will always share to the detriment of small organizations and individuals. DoH and DoT embedded in the browser intrinsically favor large organizations, and specifically Google and Cloudflare. And why do they promote DoH and DoT in the browser rather than promoting it at the system level (i.e. in Windows, Systemd, etc)? Because it's (a) less costly for them and (b) furthers their competitive commercial interests in their battle with other large organizations. One reads endless apologia on HN about how people would rather send their DNS requests to Cloudflare and Google rather than their ISP, as if those were the only realistic options, and no matter that doing so doesn't require delegating even more functionality to the browser oligopoly. They've already given up. They see their own role as choosing sides as consumers rather than actively participating as producers of these technologies, which is so utterly depressing from the perspectives of preserving an open internet and promoting free software. (For example, web developers are fine with DoH because they don't see how it effects their own server-side and client-side development. It doesn't matter to them that it would make it increasingly difficult to independently implement and maintain the software and systems--they're just consumers. QUIC? Not their concern--that's the responsibility of nginx and node.js, no matter that those projects likely never could have been founded outside large corporations if they first had to climb the steep hill to HTTP/3 and QUIC.) How do we stop this? By keeping an eye on long-term goals. While IPv6 and DNSSEC are more complex than some alternatives, from a long-term perspective they minimize overall complexity and substantially preserve independence, such as it is. Some options are even more clear cut: push DoH and DoT into the system resolver (and OpenBSD is doing, and projects like unbound and even, IIRC, systemd already support).

dagenix 8y ago
> While IPv6 and DNSSEC are more complex than some alternatives I'm not sure what you are getting at. IPv6 is pretty similar to IPv4 - and in some ways simpler - and I'm not aware of any other alternative. And I don't really see how DNSSEC (or IPv6) relates to anything else you are talking about - DoH addresses a different use case.
- wahern 8y ago
  I intended them as general examples of people pushing against certain kinds of change in favor of simpler short-term options that favor or preserve centralization and complexity. I agree IPv6 does make many things simpler, but moving to IPv6 can be difficult and introduces some additional complexity (e.g. link-local addresses, shift away from DHCP, etc). The argument against IPv6 is that NAT is simpler if only because NAT is already the status quo, and we already have "solutions" to deal with the limits of small address spaces. How many people use Cilium with IPv6 transport instead of UDP over IPv4 over VXLAN?[1] Local DNSSEC doesn't solve ISP confidentiality but it does prevent NXDOMAIN substitutions, which is one of the biggest immediate benefits for browser-based, default-enabled DoH/DoT. And one argument for doing DoH/DoT to centralized servers rather than locally is that it partly obviates the need for DNSSEC--it's "simpler" because it doesn't depend on orchestrating larger infrastructure changes. (I guess the logic is that without DNSSEC centralization is inevitable anyhow, and if people are convinced that ubiquitous DNSSEC will never come than doing DoH/DoT in the browser vs at the system resolver is a distinction without a difference. A poor argument but implicit nonetheless.) [1] At work I suggested Cilium with IPv6 and IPsec for policy and LAN confidentiality of K8S clusters but everybody thought I was nuts and favored Cilium's UDP+IPv4+VXLAN mode and transparent Istio proxies for automagic mutual TLS. Why? Because it's what they know and understand and they can reasonably expect everybody else will make the same judgment. It's ultimately a much more complex, error prone, less performant, and less flexible approach but it's the path of least resistance. And in the long-term the complexity will mean proprietary managed solutions will prove that much more enticing, an irony apparently invisible to people who believe K8S will keep them independent of AWS, Azure, etc,
  - 8y ago