I mean the services Google provides to users in the form of web applications, yes. The terminology is sucky.
As for concrete examples, Hangouts only works in non-Chrome browsers (including ones with WebRTC support) if you install a Google-provided binary blob. Which you may not be able to do.
Gmail only supports offline access in Chrome (see https://support.google.com/mail/answer/6557?hl=en the "two exceptions" bit). Whether not having offline access to your mail counts as mail "not working" is up to you, I guess; for me it counts as "not working".
https://bugzilla.mozilla.org/show_bug.cgi?id=973754 is an example where as far as I can tell they built the feature around non-standard Chrome-only functionality even though Firefox supports the standard version.
They do fix these bugs sometimes (the UA sniffing ones, where they just got the sniffing flat out wrong, tend to get fixed once someone diagnoses them). And sometimes not.
> Hangouts only works in non-Chrome browsers (including ones with WebRTC support) if you install a Google-provided binary blob.
The Google Hangouts website uses some carefully-constructed language to imply that people must download Chrome to use Hangouts, even though a Hangouts NPAPI plugin supposedly exists:
The Hangouts Chrome extension won't work in your current browser. You'll need to
download Chrome before installing the Hangouts Chrome extension. Do you want to
download Chrome now?
Google+ photo editing is another Google feature that requires Chrome. I believe it uses NaCL to optimize some photo effects.
The NPAPI plugin is one binary blob. The Chrome extension is another. The Google Hangouts home page only offers the Chrome extension. To actually find the NPAPI installer, you have to know it exists and search for it.
It's not nefarious on the part of the _developers_. They were given concrete goals. I wasn't privy to those, but it sure looks like those were: Must work in Chrome (Android) and on iOS, working elsewhere is nice to have but optional. They were also given deadlines. Then they proceeded, with no nefariousness, to deliver a product that works on Chrome and iOS and not elsewhere. I'm sure if they had more time or more people they would have made it work elsewhere too.
Then you ask yourself why the goals were set the way they were. Obvious guess at an answer: because they only want to target "mobile" and Android+iOS cover most "mobile" clients. Had iOS had less market share, I will bet the goal would have been Android-only (modulo advice by lawyers based on antitrust worries in that situation, of course).
No malice anywhere along here, but the end result is not so distinguishable from malice, sadly.
Every single case is different, but with with Microsoft it was corporate policy to do so - "Embrace, Extend, (Extinguish)", and it was executed again (MS-DOS vs. DR-DOS) and again (IE and Frontweb) and again.
The old saying was "Windows is not done until Lotus won't run", and the DR-DOS case shows it might not have been an exaggeration
Google/Chrome also works hard to support "what's already out there", which is what you mention, but what we're discussing now is building on your supposedly-open-but-really-proprietary platform _against_ other players, whether that's policy or coincidental with constraints.
Microsoft spent effort making sure Windows itself WON'T run on DR DOS before that. They constantly ignored web standards after they won the browser wars (conveniently working well with Microsoft tools that produced non-standard markup, though) ... up until the moment they lost them again, at which point they started to pay attention to standards again.
With their last few releases, Google seems to be adopting this Microsoft style of evil. Some people defend that, and some don't.
Yeah, people who think individual developers at Microsoft were trying be evil just aren't thinking clearly. Now upper management, on the other hand....
btw, the Inbox team clearly didn't bother to contact Mozilla about the Firefox performance problem because Mozilla fixed the bug within a couple hours of it being reported on HN:
This is a huge problem for the overall strength of the open web and Mozilla unfortunately is no less guilty of this. Many of the tools developed for FxOS are targeted for Gecko and wont run on other rendering engines. More and more it seems the only people actually building libs for the open web are independent developers and small shops. :(
I think there's a difference between ChromeBook or FxOS apps, which may need functionality and more importantly permissions that are not available on the web yet and creating web apps that use functionality that's supported in multiple browsers but restricting to only one browser.
That said, I agree that more FxOS bits need to end up on standards tracks. The permissions issue really needs solving to make serious progress there.
As for concrete examples, Hangouts only works in non-Chrome browsers (including ones with WebRTC support) if you install a Google-provided binary blob. Which you may not be able to do.
Gmail only supports offline access in Chrome (see https://support.google.com/mail/answer/6557?hl=en the "two exceptions" bit). Whether not having offline access to your mail counts as mail "not working" is up to you, I guess; for me it counts as "not working".
Various Google properties use UA sniffing to deliver degraded content to non-Chrome browsers. https://bugzilla.mozilla.org/show_bug.cgi?id=921532#c9 is an example.
https://bugzilla.mozilla.org/show_bug.cgi?id=973754 is an example where as far as I can tell they built the feature around non-standard Chrome-only functionality even though Firefox supports the standard version.
Google news menus don't work in standards-compliant browsers because they rely on a Chrome/WebKit bug. See https://bugzilla.mozilla.org/show_bug.cgi?id=1083932
Google patent search uses UA sniffing and locks out various browsers as a result. See https://bugzilla.mozilla.org/show_bug.cgi?id=1013702
Google Translate will fail to work in Firefox unless you have Flash installed (good luck on Mobile).... or spoof the Chrome UA string. See https://bugzilla.mozilla.org/show_bug.cgi?id=976013
They do fix these bugs sometimes (the UA sniffing ones, where they just got the sniffing flat out wrong, tend to get fixed once someone diagnoses them). And sometimes not.