Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

And the thing is it's sadly not a lie. YouTube and such do work best with Chrome. Google's effective web vertical integration means they control every stage of the pipeline. They control the sites and the browser. They can deploy experimental tech in Chrome which nobody knows about and which only Google sites use.

It's terrifying.

View on HN

One example of "google only APIs" that I ran into recently is the chrome extension browserAction.openPopup API. This API is whitelisted (in stable) for use by the Google Cast extension. Extensions authored outside of Google cannot use it. This is creates an uneven playing field.

https://bugs.chromium.org/p/chromium/issues/detail?id=436489

So when are they going to get hit by lawsuits like the ones Microsoft got in the '90s?

They've already been hit with that in the EU. And, I imagine the first thing after this current election cycle in the US ends will be newly minted (or newly defrocked, as the case may be) politicians attempting to take a cheap shot at Google -- especially since Popular Luddism is circling the political backwaters these days.

As already stated, they were already happening, and Alphabet is in large part an initiative to head that off.

It seems it's not necessarily malicious. From https://bugs.chromium.org/p/chromium/issues/detail?id=399859:

"The popup is anchored to the extension icon, which might be in overflow or not even exist, in which case it is anchored to the Wrench menu. That kind of anchoring would make the message in the popup to appear to be from the Chrome browser (since it points to the chrome UI) and would present a vector for tricking users into thinking the message is from a trusted source.

Since this is not safe to allow all extensions to do we'd need a lot better reasoning than "I'd like to use this in my extension" before allowing widespread use of this API."

I agree, I would guess extensions also probably don't have access to chrome's password store. Trusted code can be handled differently.

I agree that the API limitation is most likely not malicious and I did not intend to imply otherwise. Still, lack of malice does not change the fact that the Google Cast extension has a competitive advantage over other non-Google extensions (which can't use all of the same APIs).

This seems remarkably similar to Philips:

"While the Philips Hue system is based on open technologies we are not able to ensure all products from other brands are tested and fully interoperable with all of our software updates. For guaranteed compatibility you need to use Philips Hue or certified Friends of Hue products."

After all, it'd just be downright unthinkable that any non-Philips lightbulb should be compatible with our light sockets, that any brand of plug should fit into our wall sockets, or that non-Google-branded plug-in should be able to use a web browser's APIs... I mean, goodness, next we'll be thinking that the term "plug-in API" suggests its supposed to allow things that other people created to interoperate...

That's nothing. One of the biggest injustices with Google Cast is that capturing system audio on Android is a whitelisted system-only permission and only Google Cast (and a couple system apps) are allowed access to this. Somehow screen video capture isn't a system-only permission.

Nobody other than Google (or your OEM) is allowed to build complete screen casting apps on Android. All third party solutions require you to output your audio through your speaker and capture it with your microphone, which is much worse quality, single-channel, and makes sound (I want to hear my device audio through the speakers of the device I'm casting it to).

It makes no sense, especially when any device on your network can emulate being a Miracast receiver and get access to the same audio data that you aren't allowed to access on your own device. In fact, Windows 10 insider preview currently includes a Miracast emulator just for this purpose of Android screen sharing.

At some point, YouTube worked better with Safari than with Chrome or Firefox. YouTube would serve VP9 to browsers that supported it, but it was not hardware accelerated, so it used much more CPU.

This is most likely still true. Safari only supports h.264 which has better hardware support than VP9 just now.

Reply on news.ycombinator.com