Hacker News Reader

> Currently, all of Google's services work on non-Chrome browsers.

Google Earth is Chrome-only, because they use the Chrome-only NativeClient.

Google Hangouts dropped calling support on non-Chrome browsers for quite a while: https://news.ycombinator.com/item?id=15889018

YouTube (and perhaps GMail) is extra slow on non-Chrome browsers because they use a dropped-and-never-standardised feature that is available only on Chrome, and force a slow polyfill on Firefox (and perhaps Edge): https://twitter.com/cpeterso/status/1021626510296285185

> YouTube (and perhaps GMail) is extra slow on non-Chrome browsers because they use a dropped-and-never-standardised feature that is available only on Chrome, and force a slow polyfill on Firefox (and perhaps Edge): https://twitter.com/cpeterso/status/1021626510296285185

I work on the Polymer team at Google, and have worked with YouTube on this. I can promise you that the folks at YouTube are working very hard on porting to the specs that are supported crossbrowser. Switching to the final versions of the specs is super high priority for all of us, there were just some changes between v0 and v1 that are hard to paper over, and as you might imagine, YouTube has a lot of code.

> Google Earth is Chrome-only, because they use the Chrome-only NativeClient

My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.

https://medium.com/google-earth/earth-on-web-the-road-to-cro...

https://developers.google.com/web/updates/2018/02/meltdown-s...

> there were just some changes between v0 and v1 that are hard to paper over

From my point of view, the moral of this story is that Chrome shouldn't be shipping v0 specs that are on by default.

It's not that people like me want to be cynical conspiracy theorists, it's just really frustrating to watch Google ship an unfinished API that's on by default, integrate it so tightly into its core products that it can't be easily updated after the spec changes, and then just kinda... sit on it. And it's really convenient that whenever Google messes up standards, it just happens to mess them up in a way that makes Chrome look better to normal users for all of its core products.

Heck, it's frustrating that Chrome is still shipping the v0 implementation. I don't want to be vindictive or bitter, but engineers on the Polymer team clearly thought the polyfill was fast enough for Firefox. They don't think it's fast enough that Chrome could be using it now?

I don't think I'm being a conspiracy theorist when I say that probably the reason why Chrome still ships with a working v0 implementation is because Youtube uses it. And it makes me feel weird to have a dominant browser deciding to contradict a standard because it makes a Google site fast. I think that's problematic and harmful for the open web.

So even though I know that the team's intentions are good, the intentions do nothing at all to mitigate or fix the harm. And I'm sure you can understand that when people talk about the dangers of a browser monoculture, it is exactly this kind of thing that we're afraid of. A lot of us feel like Google dev teams don't really have much respect for standards or community processes. Google tends to have an attitude that standards will always go the way it wants, and if other browsers are behind on that, we just need a little polyfill or stopgap or something until they catch up. Certainly they won't decide to go in a different direction.

Is that going to get better when Chrome has 95% market share? Won't Google devs feel even more emboldened to ship v0 implementations that disregard the standards process? Are there any new safeguards or internal policies being put into place to prevent devs working on Youtube or Gmail or Maps from building core infrastructure around browser APIs that haven't been standardized yet?

> I can promise you that the folks at YouTube are working very hard on porting to the specs that are supported crossbrowser.

I'm sure the folks at YouTube are working very hard on porting to the Web standard, but the truth of the matter is:

1. Non-Polymer YouTube works just fine, and yet isn't served on Firefox and Edge;

2. Chrome shipped and continues to support a Chrome-only "standard", which is never going to be a Web standard, for some reason;

3. YouTube, a sibling product of Chrome, and supposedly a Web app, built a whole redesign around this when it wasn't even a Web standard, or even available in more than one browser, and now apparently can't do without, without dragging every browser that YouTube is not related to down.

On these counts, the apparent favouritism is clear.

> there were just some changes between v0 and v1 that are hard to paper over

I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?

> My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.

You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly. Google Earth is currently available for the desktop in these forms: A native version, and a Chrome app. Yes, Chrome also happens to be a browser, but it is not just a browser, and Google Earth does (heavily) depend on its non-browser parts.

So, naturally, questions arise:

1. If it weren't for things like Google Earth and Hangouts, would Chrome's NativeClient still be around?

2. If it weren't for Chrome's NativeClient, could Google Earth and Hangouts have become the products that they have?

The answer to the second is easy: Hangouts did exist as an NPAPI plugin for a while, and does currently work on non-Chrome browsers via WebRTC, so it certainly could have used the exact same features on Chrome, and Google Earth has always had an installable, native, desktop version.

> 2. Chrome shipped and continues to support a Chrome-only "standard", which is never going to be a Web standard, for some reason;

It's going to be unshipped around April.

Chrome shipped the v0 spec in order to prove out that the specifications were valuable and worth implementing. It took time to get the other browsers on board. Writing a major application like YouTube with the specs provided a lot of valuable feedback for the final version of the specification.

Today, the other browsers are very much on board with these specs, Firefox is even rewriting many parts of their UI with these same specs. Three years ago there was more skepticism, and by building real world applications we could figure out what works and what doesn't, and address the (very reasonable) questions that people had about their design.

> I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?

YouTube does actually use the Shadow DOM polyfill today, even in Chrome, and Shadow DOM is definitely the most complicated and arguably the most performance-critical spec involved. Polymer v1 uses the Shadow DOM polyfill by default even in Chrome because if it used native Shadow DOM it would be too easy to write an app that would only work properly in Chrome.

> You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly.

Would you prefer that the NativeClient version of Google Earth not exist at all? The work that went into NativeClient has contributed to the wasm spec, and (I assume, but don't actually know) the NativeClient version of Google Earth was the basis of the wasm version.

Speaking just for myself, like, I get what you're saying, but I'm not sure how to actually translate it into action. If no one had used the v0 web component specs, then the v1 specs might never have gotten adopted at all, or at least would have been specified with way less experience on the table for how they need to work in the real world.

NativeClient is somewhat similar. It was a proposed standard that informed will (hopefully soon) be superceded by a final standard which could build on the lessons learned in building NativeClient.

Someone is going to be the first to ship a new feature. For a while, asm.js applications were really only usable in Firefox. They would technically run in other browsers through what amounted to a JS polyfill, but not very well. But Firefox's asm.js work was really good for the web, because they were able to gather a lot of real world info on how asm.js and similar techniques work in the wild.

Same thing with WebVR. As I recall, for a while Firefox was the only browser shipping experimental support for virtual reality in the web browser (someone correct me if I'm wrong here). Yes it's annoying when something works better in one browser than another, but how do you add new features to the web platform without experimentation and getting real world use?

The important thing is that the insights from shipping the experiment make it into a open specifications that are implemented cross browser.

They use a polyfill for Firefox on Youtube because of a never-standardised feature too: https://twitter.com/cpeterso/status/1021649116391075840

Google Earth has a desktop version too.

Google Meet still doesn't work with Safari, with no explanation. Safari supports the latest WebRTC, and AIUI Google Meet uses the current WebRTC standard, so why does Google refuse to let it work on Safari? This has to be deliberate.

Safari has purposefully neutered WebRTC, both Firefox and Google have full codec support while Apple tries to push H.264 only, plus things like web push still doesn't work on iOS: https://webrtchacks.com/safari-webrtc/

Google Meet also appears to have updated to support the WebRTC spec (rather than the oddball implementation Chrome had) so long as your browser supports it: https://blog.mozilla.org/webrtc/firefox-is-now-supported-by-...

I thought H.264 is free for Software Decode? Supported in Firefox as well. There is no reasons why Apple should support VP8 / 9 Which is a Google's Codec, even though it is free of charge.

H.264 isn't free, Cisco is footing the licensing bill for support in most software (including Firefox): https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Implementatio...

This is why Mozilla is pushing AV1 and VP8/VP9 so hard, being stuck with H.264 as the whole industry migrates to H.265 due to bandwidth savings is a major impediment, and the licensing body could easily extract usurious rent for H.265 if it becomes the only reasonable option: https://hacks.mozilla.org/2018/08/the-video-wars-of-2027/

Sorry I got mixed up, but it should be free for anyone which has H.264 hardware decode. Which is like 95%+ of All PC / Tablet / Smartphone sold in the last 5+ years.

And that article from Mozilla, I remember it, worst article from Mozilla for as long as I remember ( That is since Netscape Era ).

Rejecting VP8/VP9 due to Google's involvement is silly and pointless, they're free to use codecs that are much more efficient than H.264. Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA.

Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA.

If that’s true, why are they a member of the AOM, which promotes the royalty free av1?

How long can Apple push against all of the major content providers? Google, Netflix, Mozilla, AT&T & the plethora of other streaming providers will not fully support H.265, and Apple doesn't want to not have a seat at the table as they build a codec to supplant it.

I think this is a repeat of the USB C engineering participation by Apple, they may roll it out to their tiny MacOS install base, but it could be years before AV1 is supported on iOS. Safari on iOS is where Apple likes to draw its line in the sand, it also happens to be where they have nearly 1 billion users, versus 70 million on MacOS: https://ngcodec.com/news/2018/10/9/whats-in-a-codec-hevc-ver...

While it's true that Safari only supports H.264, Google already produces quite a lot of H.264 video. In fact, Google has a Google Meet iOS app; I don't suppose you have any idea if they push H.264 to that app, or if they've actually embedded a software VP8/9 encoder/decoder into the app? I sincerely hope it's the former for battery life reasons if nothing else (though we already know Google doesn't seem to care about power efficiency).

What does Web Push have to do with WebRTC?

WebRTC was created to replace the need for apps that handle calling, without web push notifications (like every other WebRTC supporting browser has) there is no way for inbound calls to cause the phone to receive a notification unless Safari is open and has the webpage pulled up.

WRT VP8/VP9, bandwidth is much more of a concern than you make it out to be. Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low (say hello to congested towers, or fringe 700Mhz coverage where 500Kbps is all you get :P), thus the best compression possible ensures that video quality and usability is top notch.

By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. Is it good for interop with a 2005 era deskphone? Sure, but not much else.

Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant.

> Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low

I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target).

> By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs.

It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile".

In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

> Google Meet is a video conferencing app, not a telephone replacement.

Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years.

Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.

Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned

> In any case, if you want better than H.264, how about H.265

H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu...

> I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P

> once again not WebRTC spec compliant

According to the page you linked, nobody is spec-compliant.

I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else.

> A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.

Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.

Also if alternate browsers mindshare dips too far they could argue it was too much effort to support such a small part of the market.

> Currently, all of Google's services work on non-Chrome browsers.

Last time I checked, Google Authenticator only works on Chrome.

Gmail and YouTube uses Chrome only features that make them slow in other browsers, compared to Chrome.

You imply they do this deliberately, do you have any evidence? It sounds super unlikely to me.

> Last time I checked, Google Authenticator only works on Chrome.

Google Authenticator is available for Android, iPhone, and Blackberry, and not for any browser; there are a number of third-party implementations, however, including a Chrome/ChromeOS one.

I don't use any of those things. I just know that I had to install Chrome to get Telegram's desktop app working.

FYI Telegram has a history of serious security issues:

https://www.theregister.co.uk/2018/02/13/telegram_messaging_...

https://www.theverge.com/2017/1/11/14237136/trump-leak-teleg...

https://gizmodo.com/why-you-should-stop-using-telegram-right...

Thanks.

But I did know that.

It was just that Everpedia used it for chat, and I was curious.