Hacker News Reader

Comment by shadowgovt | Hacker News Reader

It's not even so much about protecting the secret sauce as protecting user data. Every tool interfacing to the Google backend is a potential attack vector. When the time comes that nobody's willing to bear the cost to keep it updated as the core infrastructure changes, the product dies.

In a world where Google is split up, that'll still be true; it'll look more like "Google CoreCloud has just changed API foo to protect against backflooper attacks; all users must change by Q4 2022." And spin-offs that can't afford the change will kill features or products.

In fact, in a world where individual pieces of Alphabet are required to sink or swim based on their own profitability, I expect more products dead, not fewer. Ads pays for search. Who pays for search in a world where the government has stepped in and divested ads and search from each other?

View on HN

That's why we originally had an IETF and RFC's were publicly commented on and why standards are supposed to be company agnostic.

The whole proprietary-APIs-over-HTTP was a giant step back. Before we did that interop between internet based applications was far more common and supported. Now every company treats 'their users' as their own private little walled garden when before 'your users' were not so much cows to milk as they were users you exposed services to at the protocol level.

We have been able to move very fast and very far because of this shortcut but the price is a very high one and I'm not so sure if in the longer term we will end up with an advantage.

I'm not convinced, though there are, obviously, advantages to RFCs and IETF.

The primary disadvantage is speed. A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. Google has a streamed cloud gaming service running in its web browser right now; how long would it take the RFC process to kick out the protocols necessary to enable that?

> A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes.

But...that's part of standards process. It's quite common for the actors like Google to propose a new/revised standard after implementing it independently SPDY (became HTTP/2), HTTP over QUIC (became HTTP/3), Web SQL DB (became dead, but still started the standardization process), etc., all went this route.

Exactly.

I was talking to people at the IETF about this last year. One person said the ideal use of the IETF (and RFC process) is to take situations when multiple companies have solved the same problem. The IETF puts everyone in a room (/mailing list) together and lets us collectively figure out a single interoperable protocol that all the members can implement in order to make their systems compatible.

The golden path isn't "Joe blogs needs a protocol for something so he writes an RFC". Its "Joe need a protocol. He writes his own and iterates on it. Later he meets Sarah and Dave who've all written similar protocols to solve the same problem at their own organizations. Together they approach the IETF and form a working group to discuss a standard."

Reality is usually much more messy than this; but generally the IETF should never be a bottleneck for people who want to write code and try things out. Racing ahead of whats written in RFCs doesn't stand in opposition to the RFC process. The opposite - racing ahead is a necessary part of the process, because we need collective experience in how to solve a problem in order to write good standards.

There is another downside to IETF/RFC/public standard: it's hard to move forward.

My favorite example: e-mail. SMTP and IMAP are old and have so many issues. On the SMTP side it is hard to identify authorized senders, which is a reason for spam, IMAP doesn't really work nice with mobile devices. On the other hand there are messengers like WhatsApp which solves many of those issues and allows adding features (for good or bad) and contrary to mail is fully encrypted and signed (assuming Facebook didn't break it, yet, after adding Signal's technology)

RFCs don't get changed, they get replaced by new ones. Until we find something that is 'good enough'. SMTP and IMAP are now older than quite a few of HN's readers. They could be replaced by something better, all someone would have to do is design it and put out a new RFC.

What is true though is that once a protocol is 'good enough and it gains mass adoption that change is hard but this is more to be blamed on human nature and inertia than that it is to be blamed on the RFC system in itself.

And this is happening. The JMAP working group at the IETF is writing new RFCs to replace SMTP/IMAP, Caldav, and others with a much cleaner protocol built on top of JSON and HTTP.

Its already in use at Fastmail and a few other places. (The fastmail web client talks JMAP to get your emails from the fastmail servers.)

Specs and more here: https://jmap.io/

Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.

This was the final straw. I have been considering it for literally years but I believe in open standards including email itself. If fastmail is supporting and advancing that I have no problem paying for their service.

I just created a fastmail account and set it up on my devices. Now begins the long process of moving away from gmail.

Unless your plan is to change human nature, where the “blame” goes is pretty academic. The inertia is still an issue when going the RFC route, and less of an issue when standards are developed first to fill a specific need for an interested party.

The inertia is a good measure for how successful a particular protocol version is. See for instance IPV4 and how hard it is to get rid of it. And that inertia is good, you don't want to rip up your standards every two years.

Every two years, no.

When the standard starts to actively limit further development, though...

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

Nobody stops you from adopting IPv6, the reason that many people don't do it is because they have legacy stuff that they can not reconfigure so they're stuck. But it will happen, and IPv6 adoption is steadily on the rise.

Here in Australia my expensive fibre connection still has no ipv6 support. I file an issue every year or so to my ISP asking when they're going to add ipv6 support, so at least they know I care. But the answer is always "Its not on the roadmap".

Its difficult to remember to write ipv6-compatible software when I can't use or test it myself. Short of writing to my member of parliament and asking them to legislate it, I'm not sure what else I can do.

And on the other hand, any mail client can connect to any mail server, and any two mail servers can exchange email between each other, so the service is fully federated. The benefits here outweigh the downsides.

But also, why isn't there a commonly accepted better email standard yet? It's not because the RFC process is slower - it may be, but it's not that slow. It's because none of the big providers are interested in this form of interoperability. It's plainly obvious when you look at the sorry state of affairs in IM.

We're really, really lucky to have the interop that we have, solely because early days of the Internet were more collaborative, and enough of it got early adoption and stuck around, because it was too hard to uproot. But the more we go forward down the present path, the more Internet is splintered into proprietary bubbles.

Inability to move forward has less to do with IETF/RFC/public standards than it does with email and SMTP, to use your example, being heavily entrenched. Anyone can come up with a new way of doing something, but it's a walled-garden until it's interoperable with other tooling that other people, everyone else, are using.

OnLive was streaming games years before Google entered the space, there isn't much novelty in what Stadia has done.

The novelty will be if it's profitable / something people want.

There are already RFCs for realtime streaming of data. Also IIUC the RFC process often starts with a draft based on am existing implementation.

I don‘t know that much about how the standardization in machine building is done, just from using this standards when working in this industry. However, I would assume a lot of those standards took very long to establish but they are stable, work basically everywhere and are easy to understand.

A lot of standards coming from Google are - so it seems - here to solve things just Google likes to solve and nobody else mostly does not care about. And it‘s not standardization if you‘re the only one caring about it and forcing it onto other.

this is what organizations that participate in the RFC ecosystem have always done - they just view protocol-level interop and open standards as important.

Sure, it would be nice to go back to IETF and RFCs. But it seems like the discussion has wandered far afield from a Google breakup (more standard APIs/protocols may not result from a breakup and may not need a breakup).

And what I hate about Google/Facebook breakup discussions is how they seem driven by a mob of all those having complaints against these tech giants, where the complaints contradict each other (too much censorship, too little censorship, Google too few or too many products, etc) but the likely upshot on success is states gaining more leverage over these companies and using them as even more effective control/propaganda outlets.

The IETF and RFCs are alive and well. There is no going "back" we are still there. That's a good thing.

I don't see a complaint that Alphabet has too few services. The complaint seems to be that Alphabet is killing viable businesses or products because it can't spin them off profitably. Alphabet controls some amount of innovative economic capability that is creating products which Alphabet then wastes. Conversations about breaking up companies like this are about reallocating that economic capability to somewhere it can deliver value.

> Who pays for search in a world where the government has stepped in and divested ads and search from each other?

Since most of the revenue from Google's ads are from ads on search, presumably the broken-up ads company would be buying the ad space on the broken-up search company's SERPs. All the search company's revenue would still come from the ads company.

Is most of Google's ad revenue from ads on search? They have a huge display ads business also.

https://abc.xyz/investor/static/pdf/2020Q2_alphabet_earnings... breaks advertising into: "Google Search & other", "YouTube ads", and "Google Network Members' properties". My understanding is the latter is the display ads business, and you can see that it is pretty small, relatively.

(Disclosure: I work in Google's display ads business)

I guess the first category is maps and Gmail and other such offerings. (Still plausible to me that search is the primary driver there)

It's clearly enough revenue to support the existence of search today.

> Who pays for search

If search is of value to you, the user, wouldn't you, the user, be willing to pay for it?

The people who can afford to opt out are the same people who's views are the most valuable. Not going to happen any time soon IMO.

I'm willing to pay $5/mo

Much of India will pay $1/mo

Most people will pay $.1/month

What will the price be?

> What will the price be?

If you allow Google/Alphabet to practice price discrimination, it will charge customers in richer countries more. You and I would pay $5/month, much of India would pay $1/month, and people who can only afford $.1/month would pay that.

If you insist that the price be uniform over all users, then it has to be $.1/month, or whatever the lowest common denominator is. Of course in that scenario it's much harder to get to a revenue number that is anywhere close to Alphabet's current revenue.

Another subthread here states that ads on search are a majority of Google's revenue. Looking at [1], we see the US being 46% of the revenue. So, assume that search in the US pays for 20% of Google's revenue. Apparently Google's revenue is $160B/year. Do you think the US would have 100M customers willing to pay $320/year for search? Or 10M willing to pay $3200? Or, any mixture of that to reach the balance?

Dislaimer: I'm a Googler, but only base the above on this comment thread and the first results in Google search.

[1]: https://www.statista.com/statistics/266250/regional-distribu...

Revenue isn't a good comparison and is more of a distraction than a usable data point.

Presumably, if Google is servicing paying customers instead of paying advertisers, then google has much less work to do. Their revenue can decrease without their profit decreasing.

They don't need to manage engineering to store cookies and track interests. They don't need infrastructure to store profiles. They don't need cpu cycles to correlate interests. They don't need lawyers to fight off regulators. You can easily imagine other things they would not need for those customers.

How much would paying customers need to pay so that google would make the same amount of money? Revenue isn't even an upper bound on that question.

> ads on search are a majority of Google's revenue

That's not the same as saying that a majority of Google's revenue pays for making search work. The relevant question is whether search as an application, regardless of what else Google wants to spend revenue on, could bring in enough revenue from users to pay for itself.

Good point. Good question. Confidential answer ;)

In detail perhaps - but vaguely the answer is that it's not that much money. Microsoft pretty much willed Bing out of thin air and while adoption has been quite an issue it does have pretty reliable results. Microsoft has a ton of money to throw at things but I think - from the ancillary manner in which Bing was launched - that it honestly isn't that expensive on a day-by-day basis to run that sort of large scale search. I do suspect there is a lot of economy to be saved by already having a wide coverage of the globe with computing resources though so I'd guess at the market being hard to enter and easy to sustain costs once you're in.

I suspect Google works hard to keep from letting out how severable and independent their search business is in a large part to keep monopoly breakup calls from getting too much momentum.

The problem is that even if every Google user on the planet paid $5/month, it would maybe just barely match their current revenue.

You'd need something over 3 billion users at that rate to match Google's current revenue (about $16 billion a month). Google currently has about 2 billion.

However, Google's current revenue pays for a lot more than just search. It doesn't seem unreasonable to me that search could pay for itself with revenue from users instead of ads.

Pricing would be based on value. Someone who's willing to pay X is more valuable than someone who's only willing to pay 0.1X, so naturally the former should pay more.

Presumably spinoffs would end up with their own copy of all software infrastructure, which would evolve independently at that point.

I'm not sure that's presumable. It sounds like a better way to do things in the short run (in the long run, there's a net loss from the loss of the cross-pollination benefits of security and best-practice on the backend that Google enjoys now).

It depends on how stupid the regulators are - the one with the google name will win. Seriously people - domain names and awareness matter ans you can't just partition websites to regions with an international web.

We already know how incapable the regulators are. 20 years after they went after MS for their dominance in personal computer operating systems, productivity software and browsers, MS is still dominant in two and the third doesn’t matter to anyone except for Google.

MS had the highest market cap in the US in 2000. As of today it is #3.

The government had a monopoly suit against IBM in 1969 and finally withdrew it in 1983 and nothing came of it.

People in tech have been wanting the government to go after Big Tech for years. Four of the CEOs show up for Congressional hearings and then the government goes after...TikTok and WeChat instead.

>People in tech have been wanting the government to go after Big Tech for years. Four of the CEOs show up for Congressional hearings and then the government goes after...TikTok and WeChat instead.

The Big4 are US based companies. WeChat & TikTok are foreign owned companies, and that country is currently a safe play to bash. The gov't can go after the low hanging fruit so they can have something point at to say they are doing something about evil tech.

A big part of it is that trust busting in US is just not what it used to be, since getting borked back in late 1970s: https://en.wikipedia.org/wiki/The_Antitrust_Paradox

> Who pays for search

who says that 'search' has to be a consolidated system that needs to be paid for?

It's a hell of a lot more convenient as one. Not really thrilled about going back to the days of a fragmented web where webcrawler would give you some results, lycos some others, altavista yet a third batch...

Sounds great. These days we only get the Google or the MS batches of results.

... which cover five nines of use case. A fragmented ecosystem would give us three to five sites to search that still cover only five nines of the use case, based on past experience.

Oh but the things you discover! I didn’t learn BASIC by searching for it. I learned it because someone stuck a manual in the young adult section at my library by accident and I was curious...

Reply on news.ycombinator.com