Hacker News Reader

Hacker News

Comment by sergiotapia | Hacker News Reader

Full thread

sergiotapia

- Killing the web with AMP

- Killing email with gmail specific garbage

- Killing mobile phones with walled gardens

- Killing browsers by implementing their own spec and fuck everybody else

- Killing open source tools by releasing closed source extensions for VS Code

Google has done a complete and total 180 in the past 10 years. I remember when the name inspired and made you feel safe that this thing you were using was made with character and thought to your well-being. Now it's a dry-heave feeling having to touch anything Google.

View on HN

I don’t think they’ve done a 180, I just think we understand (through experience) their tactics better now.

We saw/feared where it would go and now it’s gone there.

Was it there 10 years ago? I don’t think so. At least not so explicitly.

They’ve been an advertising company since 2000, so I’d argue that yes it was there, people just didn’t recognise it/gave them the benefit of the doubt.

Granted, advertising in the early 2000s was vastly different though. It was served organically, with none of the tracking or embedded-scripting nonsense that's ubiquitous today (whether from Google or other actors). The very notion of "ad-blocking" or "tracker-blocking" would have made no sense back then.

While tracker-blocking in today's sense would have made no sense, there certainly was ad-blocking and cookie-blocking before the 2000s.

AdSubtract advertised it's ability to block doubleclick.com cookies in March of 2000: https://www.computerworld.com.au/article/91102/adsubtract_bl...

The article also mentions Siemens' WebWasher product which blocked cookies. Other cookie-blocking products were released in the same time period.

I remember using Privoxy back in the early 2000s because even then certain ad networks were regularly serving up malicious content and pop-ups.

at that time Google was the good guy serving up only text ads.

I was referring more to their motivation for doing things, not specific shitbag things they do now.

- Yeah, hate that Google walled garden. Much better to go with Apple.

- Yeah, that gmail specific stuff is evil, except it isn't gmail specific at all.

- Yeah, killing browsers with Chrome. Just like IE6 except it's open source, cross-platform, evergreen, and pushes standards forward rather then trying to subvert them. The biggest problem now is others like MS using their browser engine is reducing diversity, but I guess that's their fault for making it open source. evil!

- And yeah, they have now officially destroyed VSCode (which includes lots of closed source MS stuff) by releasing a closed source extension.

> - Yeah, hate that Google walled garden. Much better to go with Apple.

For a lot of people, it is.

I trust Apple not to sell my data. And I'm willing to pay the hardware markup for that.

The issue was OP's anger (to put it mildly) that Google was creating a walled garden.

These arguments don’t invalidate OP’s critique of Google’s positions though.

https://en.m.wikipedia.org/wiki/Two_wrongs_make_a_right

Your only two options on mobile are Apple & Google and he is calling out Google (in fairly extreme terms) on a point where they are easily the better of the two.

It shows what a silly contortion he was going through to tell us to hate Google.

This is natural for corporations which grow to this size. It's not about good vs evil, they just weren't at a scale where they could do these projects which are all based in some combination of good intentions, serving customers, and profit.

This isn't some law of physics. A corporation could decide that their ultimate goal is to improve society, the planet, employees’s lives, consumers’s lives, etc above pure profit. This would of course result in less profit.

They could. But if they commit to relinquishing control of their enterprise to outside VC investors (as practically all SV companies do; there's no such thing as a self-bootstrapped unicorn!) they won't.

If you want an example of a tech company that actually decided to prioritize public good, I'd present Kickstarter, which has specifically registered itself as a public benefit corporation. They are admittedly a lot smaller, and I'm sure there were a lot of situational details that made it possible, but they did it.

There are billion-dollar companies like Zoho and Atlassian that have been bootstrapped.

Atlassian and Zoho are B2B enterprise shops. Not unicorns, and not facing the same bad incentives as consumer-facing companies.

A unicorn are startups that have gone to become worth at least $1 billion. That's it. B2B is not relevant to that classification.

I said these projects are launched with both good intentions and profit. That Google has done plenty to help the world is indisputable.

Publicly held corporations won't make such a choice. The shareholders demand value over everything.

Purism (the makers of Librem hardware) are a "Social Purpose Corporation": https://en.wikipedia.org/wiki/Social_purpose_corporation

Which I believe both can be publicly held, and as stated in Florida, shareholders can actually go after them for failing to create a public benefit.

Perhaps in the future, we should be hesitant to ascribe positive social traits to corporations which don't have this in-built motivation.

Corporate management defines that value.

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.

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).

> 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.

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,

I don't have much to say regarding your work issue with IPv6 and a K8S cluster. However, I do have some comments regarding DNSSEC:

As I understand it, there you have basically 3 options for local DNS w/ DNSSEC - 1) you can run a local recursive resolver, such as BIND; 2) You can use a non-validating stub resolver which requires that you trust the the recursive resolver you use _and_ the channel to the resolver; or 3) You can use a validating stub resolver. The problem with option 3, is that I don't believe it's possible to do DNSSEC validation for a record without fetching a bunch of parent records - so you end up running something that looks a lot like a recursive resolver with a cache, so, its really not clear to me why someone would do this over option 1.

Anyway, that basically leaves you with two options: a recursive DNS server or you have to trust the recursive server that you do use and the channel to the server. While its fine to run your own recursive server if you want to, there are legit reasons someone (such as myself) wouldn't want to - its another service to manage and it may not perform as well as a shared cache in a recursive server someone else is maintaining. What that leaves me with, is that I want to use a non-validating stub resolver and I suspect that is true for most people as well.

Unfortunately, as DNS traffic is not encrypted, when I use a non-validating stub resolver, it's easy for anyone that can eaves drop on my traffic can log where I'm going. Anyone that can modify traffic, can send me whatever responses they want. It doesn't matter if the domain I request is protected by DNSSEC if someone in the middle sends me back a bogus response that my resolver has no way to verify.

DoH actually works alongside DNSSEC in some situations - by encrypting the channel between my stub resolver and a validating recursive resolver, it means that DNSSEC validation can't be easily stripped out by someone that controls whatever local network I'm connected to.

Even with a local validating recursive resolver, you have little protection against NXDOMAIN substitutions and the like unless the domain you are talking to has DNSSEC enabled. However, DNSSEC is being slowly deployed and, in my opinion, it's very unclear if it will ever get to 100%. Unless it does, something like DoH still has value in protecting users from interference on the local network for non-DNSSEC domains.

My points: I don't think that a Local DNSSEC resolver running on everyone's computer is realistic; DoH actually benefits DNSSEC by securing the channel between a stub resolver and a validating recursive resolver.

Sources:

https://tools.ietf.org/html/rfc4033#page-12

https://lwn.net/Articles/665055/

1) You don't need to personally maintain your local resolver. The OS can do this for you. Linux+systemd and OpenBSD already come with this out-of-the-box, and macOS and Windows could feasible do this as well. (IIRC some macOS services already rely on an internal caching resolver, anyhow.) OpenBSD 6.5 almost shipped with DNSSEC verification enabled by default but they decided at the last moment that it still caused a few too many headaches.

2) DNSSEC isn't a panacea and there are absolutely problems with depending on it. And of course it doesn't directly address the confidentiality issue, either. My point is simply that too many technically-oriented people are willing to throw up their hands; they'll give centralized DoH/DoT to Google and Cloudflare a pass as a fait accompli but endlessly bikeshed the downsides to DNSSEC.

In truth DNS confidentiality is a fundamentally difficult problem because DNS is fundamentally centralized, as would be any system reliant on recognizable identifiers for its namespacing. And while we can maybe trust Cloudflare and Google today that can easily change, and there's no going back once we centralize even further--as described by another poster who described how 8.8.8.8 is ubiquitous enough at this point that it has set expectations for actual resolution behavior. It's not DoH or DoT that is the problem, per se, it's the fact that it will be enabled by default and be performed by the browser directly to Google and Cloudflare.

Authentication is solvable, however, and while more difficult to orchestrate DNSSEC usage, the result would be preferable long-term compared to making Google and Cloudflare yet another point of centralization. Even if you think DNSSEC sucks it represents at this very moment a stark choice between a whole universe of sucky options in the future versus vs the preservation of our ability to pursue better options down the road, independent of its specific merits. Would you prefer DNSCurve over DNSSEC? Once they broker most DNS traffic both Google and Cloudflare will have an even stronger incentive to promote the most baroque alternatives because additional complexity favors the large incumbents, just as large corporations, once regulation becomes inevitable, will lobby for particularly complex regulations requiring particularly costly compliance as a barrier to competition.

And, again, it doesn't require you to necessarily do anything. You don't need to be a mechanic to understand the value in preserving the viability of being a mechanic.

The main challenge I see in what you are advocating is that it's not clear to me how to avoid having a large, centralized recursive resolver such as 8.8.8.8 or 1.1.1.1, without increasing DNS query time or having to deal with badly behaved ISP resolvers.

* We've tried having ISPs run recursive resolvers - and many ISPs demonstrated that they either ran slow servers, servers that sent back faked responses, or both.

* DNSSEC lets you validate a response, thus getting rid of faked responses. However, even if the OS making running a local DNSSEC validating resolver easy, I don't see how that can be made fast. In order to validate any response, it has to be validated up through the root, which requires more requests. Caching helps, but, it still won't be as fast as a well implemented shared cache.

* It seems like it would be possible a central cache to return all of the signatures up through the root in response to a request to allow for local verification. That would solve the extra requests issue while ensuring that all responses are genuine. So, even if an ISP wanted to send back bad responses, they couldn't. However, it's my understanding that there are real advantages to keeping DNS requests and responses to below ~1,280 bytes to fit inside of single transport frames - having to send all of that extra data seems like it would make it hard to do that. Since DNSSEC uses RSA keys, which are huge, that would probably be impossible, but even with EC keys, it might be tricky. Also, it doesn't really address the very real issue that some ISPs have done a poor job by running slow DNS servers.

* Any solution that doesn't involve some sort of centralized cache, is going to have a hard time keeping up with 8.8.8.8 or 1.1.1.1 performance wise.

So, while I value decentralized solutions, it just feels like it's a very difficult proposition for a decentralized solution to win when it's at a performance disadvantage.

Regarding DNS forwarding.. I'm not far off giving up myself. We have DNS servers acting as recursive servers across the enterprise, and there's a bikeshed every few months about how it needs to forward to Google. Multiple external consultants have come in and explained that having a 1500 user enterprise refer to our own DNS servers will be just dog slow, because actually returning a cached result is apparently something only Google and Cloudflare can do.

I'm tired. I want to go make some changes that improve things. I expect I'll move to a forwarding configuration just so I can let people consider a "win" and move on something else.

Reply on news.ycombinator.com