[sebazzz]

It is just genius. After actually building a better browser, just implementing web standards while they are still on the standard track - or even before it - forcing competitors to implement them and also slowing them down in the process.

[talldayo]

To me, the genius part is how they've forced the industry's hand. There's demand for cloud gaming, USB APIs, Bluetooth functionality and graphics libraries, but many OEMs don't implement it on their system. Chrome tells them that they either brush-up their native APIs, or lose their users to an arena where their browser is more capable than their smartphone.

That part I fully support, and it's Google's "die by the sword" answer to Apple's stubbornness. Google's AdSense abuses are a horse of a different color though, and absolutely deserving of antitrust remediation. The impact of AdSense has been so harmful that I genuinely fail to imagine a "solution" to the scale of it's harm. Alongside the Apple case, it's a posterchild for "Things the DOJ Should Have Done Years Ago" in this industry.

[a_wild_dandan]

How does Google abuse AdSense? And why is finding a solution difficult? I'm ignorant here.

[blackeyeblitzar]

There’s an argument to be made that it is abusive by simply existing. It’s a business that is built on network effects since it is a multi-sided auction (people offering ad space and people bidding to show ads in those spaces). There are massive barriers to entering the ad network space as a result, which lets incumbents get away with whatever they want. In my opinion, markets that are inherently not competitive, like ones reliant on network effects, need regulation and forced competition.

But more specifically, it is things like Google forcing site owners to enter anti-competitive agreements (see https://curia.europa.eu/juris/document/document.jsf?text=&do...). As part of the agreements Google required, site owners had to preserve the best ad space on pages for Google’s ads instead of ads from rival networks, they were not allowed to insert ads from rival ad networks on the pages that Google search results link to, and they had to get permission from Google before changing how rival ads were displayed on pages where both existed (allegedly).

Note that even if site owners found these clauses problematic, in a practical sense they have no choice but to just say “yes”. They need ad revenues to survive in today’s economic environment. And for them, the risk of not having ad revenue is existential while Google doesn’t have anything to lose by being aggressive. It’s an uneven situation where there isn’t really choice for anyone except Google.

[talldayo]

Too many ways to count, really. It's an enormous system and I'm not qualified to explain it in detail, nor am I a customer of their products.

The long-and-short of it is that Google wields undue monopoly power by mediating their competitors in online advertising, and abuses that control to manipulate ad rankings and kneecap paying advertisers. They do this in several ways, like changing the font/frame/location of the advertisement and fixing it's ranking relative to Google's own products. This is the main argument against them, though there are tons of little inconsistencies that many highlight as salient.

[NotSammyHagar]

Part of it is that they are just way better at building a web browser that works really well and advances fast and fixes security issues fairly quickly. There's an open source variant (it's degoogled). Google loves this because they have a lot of tracking for their ad platform, but also it works really well. I know that Google also provides a lot of important services like noting dodgy websites and (too late sometimes) noticing dangerous extensions, all the way though, tracking most people all the time for serving them ads.

Tesla is a little bit of the same thing with their superchargers. Tesla has done the amazing thing of building them in lots of areas with enough superchargers that they are usable. But the thing that Tesla did that the entire rest of the dcfc industry can't do is just - fix them when they break. It's just stunning that more than a dozen companies can't do this this (EA is the one that really wasted billions, there are known reasons). Tesla is in line to be the predominant EV gas station for the future. Maybe they had some early mover strategy, but as someone who had both a Tesla and a ccs car, there's little comparison. Now that Tesla opened their sc to ccs cars (first with an adapter, later by incorporating that plug in the car directly if wanted), they are likely to control that market. This is incredibly powerful and will set them up to be really successful. Similar things with the Tesla vehicles having fantastic drive trains. Musk is ruining their reputation with his X related comments - but earlier he started ruining Tesla vehicles by removing turn signal stalks, removing drive train stalk, removing physical sensors (for things like curb and rain) and replacing them with poorly working "ai" things.

But to get to their predominant positions, I really think Tesla and Google got there by making better mouse traps, which of course also helped their other businesses incredibly.

This is way too long but I also wish there was a 100% capable de-googled chrome browser.

[pompino]

Chrome is not a better browser because of the various ways it spies on you. It's essentially a keylogger for Google.

[troupo]

Chrome often only pays lip service to the standards process. They often spit out a semblance of the spec, and enable it by default almost immediately. See, e.g. most of the hardware and PWA/related APIs.

[pgeorgi]

There precedence: https://www.powermapper.com/blog/web-standards-implementatio... says draft spec, then candidate recommendation (unstable), then 2 independent implementations, then recommendation (== spec in w3c terms)

It's still in their docs, too: https://www.w3.org/2023/Process-20231103/#implementation-exp... "are implementations publicly deployed?"

[troupo]

"Implementations publicly deployed" is widely understood as "released behind a flag to gather feedback and work out issues", not "release without a workable spec"

[winter_blue]

> They often spit out a semblance of the spec, and enable it by default almost immediately.

On the flip side, standards committees can be painfully slow.

Can anyone explain why DOM access from WebAssembly hasn’t even been specced out yet (let alone even implemented) despite years and years (approaching a decade) of discussions around this? Like, seriously, what is going on with this?

[wbl]

How else do you get to learn what works in the real world? Saying "you can't make a feature until everyone agrees" is a recipe for stasis.

[troupo]

It is literally described in the standards process.

[wbl]

Rough consensus and running code

[harles]

> you can't make a feature until everyone agrees

Except that’s exactly how the web is supposed to work and the reason Google was able to build a giant search business in the first place. This is absolutely them shitting in the punch bowl. We made plenty of progress without fragmentation.

[dragonwriter]

> Except that’s exactly how the web is supposed to work and the reason Google was able to build a giant search business in the first place.

No, because whether or not that's how the web is supposed (by whom?) to work, it is not how it did in fact work when Google built that business, in fact, it's farther from how it worked in the period Google was building a giant search business than it is now.

[ajross]

> ["you can't make a feature until everyone agrees" is] exactly how the web is supposed to work

That's just wildly incorrect as a matter of history. To first approximation every technology we use was implemented via Netscape and Microsoft jamming features in as fast as they could and implementing ones from their competitor only once it was clear they were reaching adoption. The interest in a "standards process" really only showed up after the turn of the millenium, once Netscape had faded and IE had begun to stagnate. And in fact Chrome was by far the biggest driver of this change.

[strongpigeon]

In a sense though, the WHATWG was fragmentation and was what helped move the web forward after the W3C got too slow and hard to get anything through… Requiring consensus to add anything to the web is how progress will slow down to a crawl and we have precedent for this. The current process seems pretty good IMO

[zer00eyz]

The whole point of a slower moving standard is that you are less likely to fuck yourself.

Plan Ahea

d

At some point whatwg is going to jump the shark. They are going to feature paint themselves into a corner and have to make the choice of "cut off some chunk of the web" or "go forward on a new stack". The all gas no brakes add features like were a start up forget about thoughtful or engineering is a bad way to sustain something.

[joshuamorton]

> They are going to feature paint themselves into a corner and have to make the choice of "cut off some chunk of the web"

This of course is actually much more likely (and functionally happened) with pre-WHATWG standards because they'd standardize things that were infeasible and no browser ever implemented, ever.

And at the same time everyone had their own weird nonstandard extensions (does no one remember the whacky stuff like https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre... and how absolutely garbage-awful it was for maintainability?)

[talldayo]

> They are going to feature paint themselves into a corner

Has the web not done that, several times over at this point? We've lost too many online standards to count, from all of the FAANG vendors.

> The all gas no brakes add features like were a start up forget about thoughtful or engineering is a bad way to sustain something.

If native smartphone runtimes were not complete dogshit, I'd probably agree with you. Without the industry's cooperation though, expanding the lowest-common-denominator platform was an inevitability. People want emulators, game streaming, proper download management, the real features that the OEMs are too afraid to publish. If they won't provide that, then their users will find another way.

And so, these "all gas no brakes" features are a product of legitimate demand. It's sad, yeah; but what's even sadder is the miserly behavior from companies like Apple that market user freedom as a security apocalypse. The openness of the web has finally caught-up with it's most-restricted users.

[joshuamorton]

I think you're misremembering, there's functionally never been a time when any browser implemented only the standards. Fragmentation was much worse in the pre chrome era.

Sometimes you had standards, but they were often misimplemented because they were bad, the whatwg process is vastly less bad, since it keeps the beta features in beta and no single browser can force them through popularity alone.

[jauntywundrkind]

I struggle to think of any piece of software or any group on the planet that has better commitment to transparency & doing it right. Who do you think does a better job, and how?

https://www.chromium.org/blink/launching-features/#new-featu... shows the process followed. Creating an explainer comes first, which is to be presented immediately to an incubation venue like WICG. Prototype behind a feature flag. Then widening review further, getting request for positions. It's recommended to start an origin trial which will run for a quarter or more. If everything is going fine, then one can start the intent to ship process.

Looking at https://groups.google.com/a/chromium.org/g/blink-dev paints such a picture of slow, controlled evolution. It's absurd to me this kind of flak blasted in the air trying to shoot down something that is generally so measured & controlled & steady in releasing. No one else has anything half this controlled. Who else does Intent to Experiment or Intent to Prototype? Few software has such a model where it's so clear what's coming, what's happening, where change & evolution is done in a controlled, slow, deliberate fashion, where prototypes are worked on & tested in the field for a significant amount of time before coming back to shipping. Few other softwares have such an extreme responsibility in going to working bodies, in soliciting requests for positions, where all manners of discovery are done.

> See, e.g. most of the hardware and PWA/related APIs.

Unclear what specific specs you are trying to throw under the bus here. PWAs took a long time to cook, in my view; hardly did they seem rashly done. A lot of people are really offended the web has MIDI & Gyrometer & other support, to the degree that they wouldn't let others enjoy this.

[troupo]

> shows

> paints

Exactly. You can show and paint all you want. And then there's reality.

> Unclear what specific specs you are trying to throw under the bus here.

Almost all the hardware specs (most of which are "not on any standards track", shipped in Chrome), things like Backround Fetch and Background Sync (same).

There are also others that Google shipped even before there was consensus and there were glaring issues in the spec (like Constructible Stylesheets)

> A lot of people are really offended the web has MIDI & Gyrometer & other support, to the degree that they wouldn't let others enjoy this.

To call this a misrepresentation of reality is a gross understatement

[jauntywundrkind]

What? Generic-sensor API is a candidate recommendation from Devices and Sensors Working Group at the w3c, "intended to become a w3c recommendation". That's like 85% of the sensors. This seems incredibly weird to quibble over.

I'm struggling to see great difficulties in Background Fetch and Background Sync, specs from 6 years ago. WebKit's big fear in their position was that maybe a background fetch for a user who changes networks leaks more data than expected... Ok, maybe, yeah, but also an incredibly tiny corner case that'll affect like 1e-8% of uses.

FUD FUD FUD.

Go read the mailing list folks; figure out for yourself what if anything seems so onerous & terrible about what's happening. By all means, freak out & share if you have concerns. But this looks like a very useful benefit to us all, happening day by day, getting as much consensus and buy in as they can, to me.

[troupo]

> What? Generic-sensor API is a candidate recommendation

I said hardware APIs, not sensors. There are more hardware APIs than just the one you decided to cherry pick.

> I'm struggling to see great difficulties

Whatever you're struggling with, the status of these is literally "not on any standards track"

> FUD FUD FUD.

You asked which standards are not on the standards track and are enabled by default by Google. I listed some of them. No matter how loudly or hysterically you shout "FUD", reality remains unchanged.

I don't have time for your emotional outbursts. Adieu.

[jauntywundrkind]

Sorry, which hardware APIs? Webusb? Others?

Excellent as usual chery picking. Way to be perpetually offended & antagonistic & address nothing. We should all be done with whining nothing's like this crap roll.

You have sold fear fear fear & your counter of trying to disregard & ignore is a strong strategy indeed. Strongly cast down then say nothing when the time comes! Well done. Expert moves. Have you at any point obeyed the HN guidelines that discussions should get more specific? No, you just moan and belly ache. Insult belittle & degrade. More broadly & pitiful than the last time.

Society would be better without these shit show tantrums. Sound & thunder, full of nothings.