Hacker News new | past | comments | ask | show | jobs | submit login
Why Is Google Blocking Inbox on Firefox? (gist.github.com)
213 points by diggan on Nov 14, 2014 | hide | past | favorite | 208 comments

On the HN thread accompanying the release of Google Inbox, a (supposed) engineer working on Inbox was saying that the reason for the exclusion of Firefox was a performance issue with accessing sparse arrays with huge indexes.

Link to the post: https://news.ycombinator.com/item?id=8495498

Link to the bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1087963

Thanks a lot for that information! Will include it in the post when I get a chance.

The performance is kind of bad in Firefox but I'm not sure it justifies blocking the entire browser because of that. For a comparison, Google Photos is slow as hell in Firefox, but you could still use it if you want to.

Google blocked Windows Phone from accessing Google Maps in the browser (both the desktop and mobile versions) with the claims that IE was unsupported, even though Google Maps UK worked just fine.

Google does have a history of blocking browsers they don't support, no matter how functional it may seem.

Yeah, they seem to use the whitelisting strategy for all of their properties. If something isn't QAed it doesn't get enabled. I suppose at that scale the support cost isn't worth the "let them use it in a degraded way" mantra most of the web community follows.


You can't get support out of Google at any price, unless you're an advertiser. But in that case, it's only help for your ads and nothing else.

You can't talk about "support cost" when it's zero.

"Support cost" doesn't apply only to customer support.

Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky.

What cost is there?

If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are using it - how then could that be an extra cost?

School me, please.

It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.

There's a big difference between "provided a degraded experience in non-Chrome browsers" and "actively blocking non-Chrome browsers by means more invasive than UA checking"

Remember, there isn't any kind of really legitimate API for 100% determining which browser you're running in. There's a lot of ad-hoc methods which usually work.

These folks spent extra effort to block it from even TRYING to run in FireFox.

How are the FireFox devs supposed to see the bad performance that they need to fix for Inbox to work right if they can't run it at all?

There is also a big difference between "provided a degraded experience in non-Chrome browsers" and "you have to actively disable CSP (a global setting) for it to work in Firefox."

Also, with respect to performance, this comment in the article might shed some light:

"Also see Bugzilla entry. The use of spare arrays with huge indexes was a performance issue in Firefox. It's been fixed in Inbox and in FF but not shipped in FF yet. (https://bugzilla.mozilla.org/show_bug.cgi?id=1087963)"

But we're specifically talking about not hobbling other browsers not supporting them - you (or whoever) said that there are still support costs even when a browser isn't being "supported" (ie enabled to operate with a site at a suitable level).

Did you read the part in the article about CSP?

Even if they don't support customers they still have to support internal customers (everyone that works for Google). I worked on a project recently that didn't support IE8. Nevertheless, the day after release there were a ton of emails from one particular office that the site didn't work. There was a bit of a panic, various theories thrown out (it's working for everyone else, why is it not working for this office, networking issues?). A couple of hours (and who knows how much money) was wasted in an all-hand-on-deck meeting to fix the issue before it was found out that this particular office had an IT department that only allowed XP+IE8 machines.

When you get bug reports from internal customers it's never "the site isn't working in Firefox 33 with all extensions turned off. It loads but is a little slow.". The bug report you get is simply "it isn't working, you get a blank page".

Answering those types of emails cost real money.

Support cost doesn't mean customer support.

This probably has more to do with undermining WP (which is competing with android in the low end phone market) than anything to do with browser support. They would block iOS too if they could, but they can't so that's why safari is 'supported'.

Were there differences between the IE on mobile and desktop though?

I recall back in the IE5 days that IE on Mac was a significantly different beast than IE on Windows despite being named the same.

The engine was supposedly exactly the same on WP7, on WP8 the entire browser is the same with the exception of the UI (obviously). Google Maps UK worked fine on both the mobile and desktop site views of IE on Windows Phone.

If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn a non trivial percentage of early adopters off the entire product. They cannot win here, it was a bug in FF, it is now fixed, presumably they'll stop blocking when the fix is more widely available.

They could have made the effort to make this work on firefox from the start, but someone decided the effort wasnt worth it.

The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Firefox is fast enough if you write code with it in mind.

...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari crashes screw them for not using android right?

Its Business Politics at play, not technical restrictions.

>The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works

Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first):

1) It's in beta, so you want to get it right before focusing on making it work everywhere

2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some experimental webkit features, which are either not available in Firefox/gecko

3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things.

And just to point out,

>dont release product until it works

is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.

I'm sure it's different for large projects, but for my own work, if I wait until the app is "finished" (or at least in a workable state) before working on cross-browser compatibility, I hate my life and want to die. YMMV, but I find that working on compatibility from the start is the way to go. That said, if there indeed is a big performance bug in Firefox, that would totally be a valid reason not to support it (for now).

My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".

It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

If you plan to support cross platform, do so from the start.

You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.

You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.

I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.

I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.

I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).

>It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

Maybe in GUI applications, but not so much in web browser applications.

>If you plan to support cross platform, do so from the start.

You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.

Again, your arguments might apply to a OS application, but not to web browser "applications".

Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.

Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.

You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.

Just to finish of,

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...

I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.

If you put 'applications' in 'quotes' when you refer to websites, we are so far from being on the same wavelength its not even worth continuing the discussion.

I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.

(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)

*experimental Blink features

> The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works.

Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite?

By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.

If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...

> Its Business Politics at play

Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss.

Even in a company as awash with money as Google, someone has to justify budget choices.

I would have expected this sort of comment in most forums, but not necessarily in a community where many members actually deal and grapple with questions of "what platform gets supported when" and understand that "effort not worth it" is not the same thing as "business politics"

I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out.

And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.

This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."

In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.

Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.

Don't say "blocking" (or maybe that is preferred since the tone of the post is to insinuate Google is being evil) and say "not supported yet" since the product is still in beta.

To me, "not supported" means that no effort has been put into making it work and you can't expect any help, but also that no effort has been put into not making it work. If the only problem is performance, then "not supported" would imply that it can be used, but it will be slow and you shouldn't complain about it being slow because you're doing something to supported. If there's code explicitly added to make it not work on Firefox, then "blocking" is a perfectly good word to use.

I'd also like to point out that, if you read the bugzilla bug, it was fixed on the same day that it was reported!

Nobody from Google bothered to file any bugs against Firefox; it wasn't until a Mozilla engineer saw the Google engineer's complaint on the HN thread that he filed it and fixed it himself!

FWIW, Safari (webkit) is mostly working. IE is, unsurprisingly, a train wreck.

performance issue with accessing sparse arrays with huge indexes

...what? Why would they need "sparse arrays with huge indexes" anyway? This sounds more like a problem with the developers doing something ridiculous, and not the browser. Maybe Chrome is faster at it, but that's like saying "compiler X has a performance issue with bubblesort."

More precisely, I'd like to see what exactly they're trying to do with this sort of code. Optimising "sparse arrays" sounds like matrix algebra and scientific computing, not an email client.

It should be noted that the Inbox folks didn't bother to report the issue, and that once it was reported it was fixed within a few hours....

Any time you see a comment like "With some more man hours, it seems trivial for Google to get the application to run in Firefox", you know the author either doesn't know what they're talking about or just hasn't thought about it very much. Anyone who's done any serious web-app development in the past decade knows that cross browser compatibility at the bleeding edge (ie, past what the JS frameworks have worked out) can consume as much time as the rest of the application put together.

At the early fast-iteration stage of a limit-seeking webapp like Inbox, it makes sense to focus on the app itself and limit yourself to just one browser. For Google, obviously they will choose Chrome. Once the app reaches some stability, and major changes are coming far more slowly, then it makes sense to start working in cross-browser compatibility.

I think that most of those comments stem from Google-hating, which is currently a big fashion here. Were it Apple doing it, they'd be lauded for their attention to user experience. Was Inbox a product of a random startup, it'd be praised for good business approach and proper prioritizing of developer time. But it's Google, so it must be some evil plan.

I'm sure that there's a lot of that going on, yes.

But Google has the legacy of their "don't be evil" company motto to content with. Which is to say that people expect (foolishly) for them to at least try not to appear evil.

The difference between Google prioritizing Chrome vs anyone else is that Google owns Chrome whereas Apple doesn't, and some random startup certainly doesn't.

It smells of Microsoft's "we'll only make this work in IE and fuck everyone else" strategy and that doesn't bring other warm thoughts to mind.

So it's not JUST that it's fashionable to think the worst of Google these days.

Google Chrome is the only browser running Google's own V8, a very bleeding edge piece of technology. Google is working on things like browser-based material design and persistent connections. Things which Inbox uses.

Providing backwards and parallel compatibility is a secondary concern.

"Providing backwards and parallel compatibility is a secondary concern."

And this is exactly why people are worried about things like this. Google has, depending on who you ask, somewhere between a quarter and a half of all desktop browser usage share. They're the browser shipped by default with Android nowadays, and Android is a big part of the mobile and tablet market these days. By the same token, Google is a huge part of the Internet -- Google runs many of the most popular sites, and is also probably the single-largest source of referral traffic for the vast majority of websites.

And now, you're saying that Google views pushing the bleeding edge in the browser for its browser-based applications is more important to Google than being compatible with other browser implementations. And you wonder why people are starting to worry about Google?

Apple is doing the same thing for icloud.com on mobile browsers. Only works on mobile Safari AFAIK.

Yes, but Apple never talked about how interoperability was important for them. Apple has always been a walled garden, like it or leave it.

Google, on the other hand, has done a lot for open standards and interoperability.

Is it unreasonable for people to flip out on Inbox while it's still very much in beta? Sure. If it's a real beta. Gmail was in beta for what, 5 years?

Does Google have any obligation -- moral or otherwise -- to make Inbox work cross-browser? None whatsoever.

But them not doing so would constitute a break from past policy which is something that people are worried about.

Why is picking one browser to get their product tested and working on first (that they happen to own) such a big deal?

These comments really are just FUD and hating (jealousy?) on Google for ignorant reasons.

So Mozilla is "some random startup"?

You might have an argument if Chrome wasn't open source.

Being that is not the case...

Chromium is open source, Chrome is not.

How does open source invalidate that argument?

Anyone can build and release a compatible browser whereas one would be stuck with Internet Explorer (and no compatible browser) if something were only to work on IE.

As it stands, Chromium exists.

How is it any better that something can run on a bunch of slightly different versions of Chromium, but no other browsers built from a different base?

Chrome isn't the only option. It is not a case where it could be Microsoft making Hotmail only work in IE, for example.

Don't want Google's services in your browser? Download Chromium or the dozens of other browsers forked from that codebase.

With something being limited to working in IE, THERE IS NOTHING ELSE, binary or otherwise.

When Apple does it, I see a lot of comments about how crappy it is to focus only on their own browser, especially when they exclude Chrome which is highly similar.

If a random startup does it, they don't have the same conflict of interest as a maker of a major browser does, so there's no reason to expect the reaction to be the same.

Just out of curiosity, what do people typically slam google for? I feel like I have a lot of trust in their services -- a hell of a lot more than facebook, and somewhere around on par with apple. Sure, they collect a bunch of your data, but it's for the purpose of them being able to serve more relevant ads to you if I'm not mistaken, since that's where most of their money is made, and their ads are fairly clean and not questionable as far as I've seen.

Overall, they have really solid products that have been incredibly useful to me, and you can see how they are working hard on so many important things: surpassing apple on the mobile design front with material design, cranking out bleeding edge and experimental innovations like self-driving cars and glass, and even working on a lot of projects that help to bring technology to those who don't have it, like project loon, the lower cost and open source android stuff, etc -- and these projects have actually been making a really big difference in third world countries (with no strings attached unlike facebook's total bullshit "charity" initiatives).

I'm not a google fanboy by any means. I more or less just use gmail and calendar, and just got an android phone after having an iphone 4 for like four years just to try it out. Just pointing out things I have passively observed about how they run. I would really love to hear the other side of the story though to perhaps balance my perspective a bit more!

"Sure, they collect a bunch of your data, but it's for the purpose of them being able to serve more relevant ads to you if I'm not mistaken, since that's where most of their money is made." You gloss over this as if its not a big deal.

Well, is it?

Personally, I am beginning to fear that the whole idea of privacy starts to block progress and in the end we'll have to choose between the two. Apart from the dystopian future everyone fears, there are also astoundingly huge amounts of good things that can happen thanks to data companies like Google or Facebook collect.

Please cite examples in which Google has demonstrated that they could not be trusted with information that they use to deliver targeted ads to you.

Did they ever pull a Facebook-esque social experiment by trying to limit what you saw in order to manipulate your feelings over the course of a day?

Do they sell personal information about you for other companies to use however they please?

Think about this a little bit before you respond with a generic, mouth frothing "BUT GOOGLES SELLS YER INFO" when they actually don't. They sell access to you when you are exposed to ads. Not access to your info.

> Did they ever pull a Facebook-esque social experiment by trying to limit what you saw in order to manipulate your feelings over the course of a day?

I'd also like to point out that the drama around Facebook's social experiment was totally overblown. People essentially mixed up what Facebook did (something not unlike an A/B test) with what some imagined Facebook in theory could do (silently but significantly influence emotional state of users), and after articles started calling this "manipulating your feelings" the Internet totally lost it. After all, the extent to which Facebook "manipulated your feelings over the course of a day" is much smaller than, say, 9gag's or that of a television ad.

This is the same problem as the one you're complaining about here - generic accusations about totally overblown things.

By your logic, since AFAIK the NSA hasn't ever targeted me specifically, then they must be a okay!

>By your logic, since AFAIK the NSA hasn't ever targeted me specifically, then they must be a okay!

An exact example of the false equivalence fallacy.


Yup, I'd like to know it too. Everything I saw or read confirms that they're one of the most benevolent big companies ever, and yet for some vauge reasons they are called evil.

Google tries to copyright cookies: http://www.freepatentsonline.com/y2014/0156738.html

Bullshit actions in partnership with Apple: http://pando.com/2014/03/25/newly-unsealed-documents-show-st...

And, to me, the worst - Bulling the CSS WG: http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...

BS. Half the comments would be slamming them that it's only for Safari (just look at the comments for the stories involving Apple's safari-only streams).

I think skywhopper hit it on the head. Just good ol' abuse of the word "trivial" and an underestimation of how much work is needed to finish the last 1%.

That is a great technical argument, however, the reason this has attracted so much attention is because this product is about email. Email plays such an important role in our modern lives that any announcement hinting that Google is moving towards vendor lock-in for email access is going to attract scrutiny -- regardless of whether it is by innovative features, enhanced performance, or browser lockout.

> any announcement hinting that Google is moving towards vendor lock-in for email access is going to attract scrutiny

I think that - like often is on the Internet - scrutiny can be attracted too soon. Google stated clearly that current Inbox is not a replacement for GMail. Such "vendor lock-in" can currently be completely explained with the fact that they're just playing around and testing if people like new UX.

Adding innovative features is now considered vendor lock-in? Interesting.

The "innovative feature" in question here (that they're depending on in Chrome) is performance of sparse arrays with enormous indexes. That's not an "innovative feature" in my mind; in most languages that would be considered an abuse of the built-in array type.

This doesn't seem to have any relevance to "vendor lock-in" though.

Yes, it does. It was the reason cited for blocking non-Chrome browsers—i.e. locking in users to a specific vendor.

What are they doing to extinguish competitors?

In this case, blocking them from their properties and requiring that they switch to Google's browser.

> Anyone who's done any serious web-app development in the past decade knows that cross browser compatibility at the bleeding edge (ie, past what the JS frameworks have worked out) can consume as much time as the rest of the application put together.

Sure thing. As a web developer, I also know that I NEED to follow CSP on every application I do. Something Google doesn't seem to do when running in Google Chrome.

I also know that adding two prefixes along with another prefix, isn't that hard to do.

If you want to be early, fast and get feedback, make sure your application works for more browsers than your own in-house browser. Because when you release it, people will surely use other browsers than your in-house browser.

To build upon that, it's worth noting the context: a public beta that's only a few weeks old.

This is an extremely naive comment. While cross-browser testing does take work, it makes an unfair assumption about the experience & knowledge of some of us commenting. Diggan (the user who wrote the gist) is not a regular person - he is an experienced and knowledgeable web developer (I don't necessarily agree with all his opinions, but I do respect his knowledge - I have previously had a vigorous conversation with him on IRC on some technical stuff). When I said CSP and animations are "trivial", it isn't without having had experience doing just that.

As someone who has had to work on teams and who now leads teams on apps with cross-browser functionality (and native mobile via Cordova), I get the challenges. Google definitely has the resources to meet them though. Time is just the x factor, and with this sentiment, I agree with. I have no problems with what Google did here - I merely made observations.

> At the early fast-iteration stage of a limit-seeking webapp like Inbox, it makes sense to focus on the app itself and limit yourself to just one browser. For Google, obviously they will choose Chrome. Once the app reaches some stability, and major changes are coming far more slowly, then it makes sense to start working in cross-browser compatibility.

Would you also agree that it would be OK for Microsoft to create products that only work in IE, then, and to advertise IE whenever you try to use those products?


From the linked article: "First thing I tried, is to switch the user agent from Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 (Firefox default user agent for me on Ubuntu Linux) to my Google Chromes user agent instead Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36"

Well, isn't it what the whole article was about? ;).

Google is not the same it wanted to be back in 2009 [1]:

Today, we base our developer products on open standards because interoperability is a critical element of user choice.

[1] http://googleblog.blogspot.com/2009/12/meaning-of-open.html

I think this slide explains everything about how Google has changed the way of handling their business.


They are more focusing on managing their business which is limiting their contributions to open standards.

Which of the 54 slides?

Sorry for typo, I meant "slides", but especially second and third slide.

Yes. It's now Microsoft circa 2001.

Considering Microsoft is now Open Sourcing dotnet and releasing it for OSX and Linux, at what point did Google and Microsoft crossed each other?

Within the last couple of months literally.

I think to be honest that some of the stuff Microsoft have been working on behind the scenes is probably scaring the crap out of Apple and Google. There's not been a platform as holistic and complete as Microsoft's offerings so far and they are adding REAL value daily rather than just moving the chess pieces to great fanfare.

I hope you are right, but nothing I've seen has made me go, "I need to build on MS."

One thing has for me: people are spending lots of money on them. Top slicing that is pretty easy.

Oh and most problems are solved or canned so all we're doing is gluing things together and making it look pretty (which is what programming via abstractions is all about).

> Within the last couple of months literally

I would rather say it has become apparent over the last year. I say windows 8 marks the moment.

That's where Microsoft realized they needed to garner goodwill and at that point Google had so much global market share (web traffic, browsers, mobile) they could say fuck all to everything and anyone.

And they started doing just that. Anyone else remember the forced and sneaky adaption tactics that was Google+?

I would say on Microsoft's part it was when Ballmer was ousted and Nadella took the reins. Nadella seems to be genuinely open to working with instead of against other companies and open source projects. I think he realized the ship was sinking, and he's doing what he can to save it, throwing out old and dead business practices in the process.

I actually like the "new" Microsoft and the direction it's heading, and I'm still trying to wrap my head around that fact.

Ballmer was at the helm when this train started rolling. It has taken years to get here. When Hanselman said to Miguel, "We did it." on stage at dev connect, I took that to mean something much larger than open sourcing Core.net. There has been a push from within on open-sourcing and pivoting on their approach to many of their lines of business that has taken so many people so many small battles, that I would sya Satya's ascendancy was the coming out party for a movement vs. some catalytic event.

You're right of course, these changes didn't happen with the flip of a switch. It just seems that so much good has happened at/from Microsoft in the relatively short time since Nadella took over, it's almost as if that was the moment the shackles were taken off. Obviously the ground work was laid when Ballmer was still in charge, but it was almost as if he resisted the changes that were coming down the pipe to the very end.

Google still open sources their apps. That's why there's almost always two versions of each app on Android. Messenger versus Hangouts. Google also allows you to remove ANY AND ALL information they have on you that is used to target advertisements. Google also allows you to export ANY AND ALL data you use in their services and to import it to any other service you choose.

Really much ado about nothing here.

Are both versions of their apps open source and do they have equivalent features? Second question (maybe based upon old info) but I thought deleting email from GMail does not really delete the email which is retained for Google's purposes? These are sincere questions and not intended to be rhetorical.

Equivalent features that are not tied into Google services? Yes. Messenger does MMS/SMS. So does Hangouts. I don't think it's unreasonable to expect that specific services (Voice calling over GTalk) should require the specific app (Hangouts)

And no, Google does not keep emails. After 30 days you cannot recover anything.


>If you can't find your messages in All Mail, Spam, or Trash, or by performing a search, then they've been permanently removed from Gmail, possibly deleted by someone else. We regret that we are unable to recover messages that have been permanently deleted.

I can confirm that having emails permanently deleted, such as when I unsubscribed from mailings from a store I deleted my account from... I stopped receiving advertisements in the sidebar related to that store. When you stop getting ads about specific things after deleting all emails about those specific things, I would say that's fairly conclusive.

When one can run Visual Studio on OSX/Linux...

That's not going to happen any time soon. Not because they don't want to but because the whole process would be monumentally complicated and expensive.

I suspect we'll see a new 100% managed code IDE in the next 3-5 years that will fit this area nicely. It'll have bits of Visual Studio in it and it may even be called Visual Studio but it won't be what we have now.

They literally just said Visual Studio 2015 will run on Linux and Mac.

--As people pointed out, this isn't true. I was confused by Ars Technica's headline declaring VS to be "cross platform".


Are you confusing "Visual Studio 2015 ... uilding applications that run on platforms including Windows, Linux, iOS and Android." with "Visual Studio 2015 will run on"?

I was confusing "cross-platform" with "runs on", yeah. I thought that as Ars says Visual Studio is cross platform, that it would mean it runs on multiple platforms. A closer read indicates that may not be true.



AFAIK only .net will which is not visual studio.

The last paragraph:

"However, we still haven't figured out exactly why Google is blocking Inbox on Firefox. That the application is not working, seems to not be fully true. With some more man hours, it seems trivial for Google to get the application to run in Firefox to. Maybe too much Chrome specific technologies or just a try to limit the usage of Firefox on the web?"

Is odd as he's spent the rest of the article pointing out that there are bits of missing functionality (such as transitions), he's disabled CSP which worries him and that there are errors showing, and that's just what a relatively brief review found. Given what is listed it seems pretty straight forward to me that in it's current form it shouldn't be supported on Firefox.

What I know, given the right vendor prefixes, transitions works mostly the same way on both platforms. I don't think it makes sense to only have transitions for one browser when it's trivial to support other browsers as well. The CSP issue I honestly don't know why that's so but I'm fairly sure they should be able to follow CSP on their own domains, just like the rest of the applications on the web have to do.

To me, it feels like Google has an unfair advantage on doing web applications when they can do stuff on their own domains that no one else can, unless they also develop their own browser with unique features.

To me, it feels like Google has an unfair advantage on doing web applications when they can do stuff on their own domains that no one else can, unless they also develop their own browser with unique features.

And legally dangerous, too. It's as if they forgot entirely about the half a billion Euros Microsoft shelled out for doing precisely the same thing.

or they bought the right people this time and are sure to be free from that fate.

remember that Microsoft wasn't sued out of the blue. competitor companies lobbied for it. if Google lobbies first they should be fine.

Looking at the CSP error, it looks like there's a blob being blocked, not some XSS from Google's domains.

My guess at the cause would be an CSP implementation difference.

Animations are not important enough to justify. Not wanting to serve all your content from a single domain is not enough to justify. These are excuses, not technical reasons.

I disagree.

They're short cuts you might take to get a product out and get early feedback, the same sort of shortcuts most of us have taken when pushed to release something sooner. This is a product in Beta, not the finish article.

Even if everything work in theory just dropping multi-browser testing would save time. If their aim is a beta product for early user testing, I really don't think what they've done is unreasonable.

Getting a product out in the web development world includes getting it out for other browsers than the browser you develop in house. Otherwise, you won't get the early feedback you wanted. Especially when your application is working, with some minor glitches.

It's not like the application is completely broken in Firefox with the fixes mentioned. Bypassing CSP for your own domains feels like a hack that you shouldn't be able to do.

Given how over subscribed the beta is I think they're getting feedback.

Remember with this sort of product the questions they have are "is this interesting?", "is this useful?", "do people like what this does?".

Can we get this running on Firefox simply isn't an interesting question to them - they know the answer, it's yes if they throw resource at it, but for a new product team with questions over whether this product should even exist that's not a priority.

Remember, this is Google who have a long history of canning this sort of project. If I were the company who produced Wave, I'd probably look at how I could reduce the cost and time to feedback for my next new thing too.

As an aside, I've tried Inbox and, to me at least, it's the next Wave, not the next Gmail.

You have to admit it seems a little shady when it comes from the browser vendor. It would be fine if the message said, "we haven't tested this, it might not work, YMMV". Instead, the message says, "click here to download our product", the implication being they'd like you to convert to only ever using their product.

I might agree with some things but not with e-mail, it's too important to most people say "hey this is probably OK but who knows".

And because of that there is the risk of reputational damage around one of their core products. Working in tech you understand what a Beta really means and you can make that call on an informed basis but that's not true of a typical G-mail user today.

It doesn't sound like they're dropping e-mails or anything else painful like that (something I've experienced several times trying to run GMail on Firefox and/or Opera). It sounds like they wanted to break CSP and have some animations and not have to worry about proper data modelling. Or maybe they just want to keep throwing rocks at people using browsers other than their own.

Lazy or evil, pick one.

Google's attempt to take over email does not sit with me well. We need better email. But email is too important to be proprietary. We need open standards here. And we need open source developers to kick it in high gear to create better email clients.

In case you haven't seen it, you might consider Fastmail [0]. They have a great webmail client, they just released native mobile apps (for both iOS and Android at the same time, wow!), and they are very much working to expand the standards to meet the needs of modern e-mail.

[0] https://fastmail.com

Privacy-wise, personally, I'd just love to see what are my options for self-hosted email service.

Presently it's just Postfix and Dovecot on the physically-owned server and Thunderbird and K9 Mail on desktop and mobile. Quite old-fashioned.

I had seen links to some fastmail support branch for cyrus and some jmap.io, but didn't really get what thase are and all on Fastmail's website suggests it's a service, not software. But maybe I had missed something.

So... is it for me or not?

very much working to expand the standards to meet the needs of modern e-mail.

Obligatory links:

https://github.com/brong/cyrus-imapd/tree/fastmail http://jmap.io/

+1 for Fastmail, and thanks for the heads up on the mobile client that I had no idea about.

Happy fastmail user.

I don't think the issue is as much with the clients as it is with the spam filtering Google provides. The sheer volume of emails they handle allows them to have the best spam filtering in the world. Something, that will be very difficult to duplicate through OSS.

The issue is with sending mail. Running my own mail server just feels like a loosing proposition as inevitably it'll be blocked because it's not a well known one.

Certainly this is what will happen if everyone thinks the same way as you...

(I have been my own SMTP server (hosted by OVH) for a few months now. I was blocked exactly once, by custom filtering from a small provider where the delivery status notification said to appeal to abuse@, I emailed them and they fixed it in minutes.)

> Certainly this is what will happen if everyone thinks the same way as you...

What will happen? More people will block small providers because fewer exists? The issue is much larger than that. There need to be better ways to deal with email than just dropping it for arbitrary reasons.

> I was blocked exactly once

... that you know of

I've worked for companies where our internal mail servers just couldn't email some people; we presume their ISP black listed us and never published it on a shared list. (We only know this because people would call because they never got the email with the link to their purchased item.)

I do not have the time to worry about if every email I send will get delivered. Many systems don't send you a status notification; they just accept and then drop the message, meaning you may not see an error in the logs. You may not show up on public black lists for days. That's not something I want to be sinking my time into. I'd rather pay someone to run a well-known service that is very unlikely to have delivery issues.

Pretending to accept an email and then dropping just seems wrong. Is this something that reputable email providers do?

(From my experience, I have never witnessed a situation where an email I had sent to someone had silently been ignored.)

Yes, it is a practice that big players do.


My understanding of this answer is that the SMTP said it had accepted it, but the sender would have been notified afterwards that the message had not been delivered, had the return addresses correctly been set up. This seems OK to me; I would have received the bounce.

(Also, the mail was sent from www-data, which I think was an acceptable clue to classify the message as spam no matter from which server it came from.)

It doesn't always need to send a bounce if it doesn't want to.

Similar story. I couldn't email msn (or exchange, etc.) but there was a web form I could fill out. Annoying, but I got to have some fun describing the type of emails I sent to my "list" and its "unsubscribe process".

I've never had a problem. I have a VPS I use as a smart relay.

There's no shortage of mail clients. There's even a decent choice of webmail clients. But Gmail offers free hosting with decent antispam, which are things that otherwise cost money.

Unless people want to get syndicalist/cooperative with their email, they'll go with the large free email providers.

Since you can be pretty sure that Google reads and hands over your email just as much as Microsoft does, you should give outlook.com a chance. It has a really nice UI for personal email and, apart from a few UI deviations, is pretty much the same as Gmail was before they started trying to make it "better."

There are couple of problems with the open source clients, one is the front end the other is anti-spam. Many of them are hideous and look like 10 years old. Some of them are functional and look nice, but you still have to deal with bad anti-spam filters.

There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome. Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense.

I use three web browsers for just that reason. Chrome for Google products (YouTube, Gmail, now Inbox, etc.), IE for Microsoft products (Outlook.com, etc.), and Firefox for the open web and general usage.

Yes there is. It's the world wide web. An interoperable universal interaction standard. Or it was until Google started pulling an IE6 game.

I use Firefox for everything because there is no central motivation to specialise. If a site doesn't work well, it doesn't get my business.

I'm with you. The day Google announced Inbox, and the fact that it wouldn't work with Firefox, was the day I finally got motivated enough to set up my own email server. I ended up just using mail-in-a-box, which doesn't come with the _best_ client, but is good enough, and I can use it from any browser I want without any problems.

Well, yes, that'd be nice if we had a "interoperable universal interaction standard." But now the majority (and soon, almost everyone) will be using the internet on tiny personal computers (smartphones) that run native apps. Using a web browser will become less and less important or even relevant. In such a case the costs of optimizing for multiple run-times makes little sense. Really, abandoning the browser for native apps (in the old days we called them "programs") across the board makes more sense, and leave browsers to what they were originally intended for - document perusal and simple data collection.

And web browsers absolutely suck at UI for applications. Imagine the man hours and effort that went into building Gmail. It boggles the mind. Who would even want to maintain that?! All for something that could have been created as a native app much easier. There's a lot of reasons that people have gravitated towards apps on phones, but one of them is assuredly that the experience is better than using a web browser.

As someone who is old enough to have written "programs" and sees the instant relationship to "apps", I vigorously disagree. Lets consider these points:

1. Firstly there are competing platforms on which to deploy your programs. This means there is little common ground between the three major sectors of the market. You either have to pick one and lose market share or pick all and increase cost. Nothing (yet) has solved this problem adequately without increasing cost or decreasing agility and/or quality and consistency.

2. Each of these platforms has many barriers to entry from subscription fees, having to buy specific hardware and learn how to use it, distribution and vendor costs, QA cost and the risks of rejection and having your product closed suddenly.

3. All of the markets are primarily consumer oriented which makes deploying things to corporate entities a pain in the backside requiring more hoops to jump through.

4. None of the programs have longevity, a stable platform to run on, security guarantees or predictable security evolution.

So at the end of the day, you're pitching programs sold behind a walled garden by someone who wants a slice of your cash and doesn't give a fuck if the device works after you've sold it versus a platform with zero entry cost, total ubiquity and importantly absolutely no distribution or sales model at all so you can build your own?


People take apps because they're cheap, free or the vendor is pushing them. That's it. If it wasn't the case, the first thing we'd do when we unboxed a mac or a PC was download and install facebook. Which we don't do.

As for mobile first everything, not a chance.

You make some excellent and valid points, to which I don't necessarily disagree. I just think the inertia is towards the use of native apps over web browsers as delivery mechanisms for software - both mobile and PC.

A couple of points:

"Firstly there are competing platforms on which to deploy your programs."

I see the major web browser as those competing platforms. The effort to make something work on different web browsers is huge, almost, or equal to, the difficultly of choosing a cross platform development tool and targeting multiple OSes.

"...the first thing we'd do when we unboxed a mac or a PC was download and install facebook".

A native facebook application might be pretty cool. Really, do I do something much different when I use Thunderbird and eschew Gmail?

A small tangent.

> and doesn't give a fuck if the device works after you've sold

Which is even worse on the web, where most of the time that someone also doesn't give a fuck about you at all and will just pull the product the moment he gets enough users to make an exit.

There are good things about having a working binary on your device; the author can't just take it away from you just because he doesn't care about the product anymore.

There are good things about having a working binary on your device; the author can't just take it away from you just because he doesn't care about the product anymore.

Tragically, in the modern software world, that often isn't true either.

Buggy junk gets shipped routinely even when people are paying real money for it. Software developers assume you'd love to have their regular updates, even if those updates also change interfaces and modify or even outright break/remove functionality however they feel like. If you don't apply the updates, you don't get security fixes either, so for any software that is at all involved with sharing data or communicating on-line many users have little choice. The idea of long term support for any stable software that people actually rely on is a joke for many projects. And that's before we even get to all the DRM/activation junk.

Ironically, the worst offenders are probably Chrome and Firefox. IME, the next worst offenders are often the supposedly high-end professional software that comes with a thousands-of-dollars-per-seat price tag -- assuming you can even buy a copy instead of renting it these days.

I'm mildly optimistic that a new generation of software seems to be arriving where people are expected to pay for good work but the prices are much more reasonable: not App Store peanuts, not Enterprice Pricing (call for a quote, because hell will freeze over before we publish any useful information publicly). A lot of these tools are relatively small or specialised, but they do their jobs well, they get very favourable feedback from users, and they have real, commercially viable development organisations behind them. Also, they rarely incorporate the user-hostile junk. So good work can still be done commercially, and of course for some of the important geek-friendly software like development tools and OS/server/networking infrastructure there are Open Source projects that are usefully stable, reliable and comprehensive. I look forward hopefully to a day when these kinds of projects are the norm for software we rely on, and we can all get on with using our computers without constantly fighting with them.

Well considering most of these binaries are tied to app stores and talk to the web they're about as much use if the vendor pulls the plug.

>And web browsers absolutely suck at UI for applications.

I prefer web apps to native apps. Day to day, at work, our CRM, bug/issue/project tracker, document management, help-desk software, phone system management, knowledge base, email, document/spreadsheet software are all web-based. Historically, those were all native 'programs' (as late as mid 2000s) and they were all crap.

>All for something that could have been created as a native app much easier.

I don't know about that. Some things are easier with html/css/js than with a native framework, but it's not just about developer comfort. Web applications provide huge benefits to users over native apps - that's why we're willing to deal with the development stack (which is getting better every year).

>Imagine the man hours and effort that went into building Gmail.

It's probably not that bad. Writing maintainable web code isn't that hard these days.

>There's a lot of reasons that people have gravitated towards apps on phones

Yes. It all really boils down to performance. If you could get 60fps with a web-app on mobile (which in principle you should achieve), I don't think users would care. You'd also see an even bigger uptake of webview-based 'native' apps (a la phone gap).

I use gmail everyday on my phone and have not bothered with downloading its app. It is pointless as I get a good enough experience on the browser and I do not want to deal with updates.

And native apps are good for things like Microsoft Office or things you expect to use offline and frequently. But if you make me download an app for Facebook or gmail and get me to update it every now and then, I will get pretty annoyed.

Well, I do use GMail off-line all the time - this (+ less crappy UX) is the reason I keep the app. Being able to browse and send e-mails shouldn't require being constantly on-line.

I've spent the last 8 months working on my own stuff. Before that I worked primarily as a backend engineer. My UI experience was limited. I did see the need for the skills.

I also believe that there should be at least a strong mobile offering with any web application now-a-days. That said, here's my thought on the matter.

UI sucks for everything. It really seems to have always sucked and probably will continue to suck. Swing is a pain to develop. WinForms too. I assume from looking at Cocoa code, so is Apple.

I've been working on a Pomodoro app during this whole time. Just getting lists to work efficiently in Android is a bitch. You have to serialize objects in and out of view items to make sure scrolling doesn't absolutely crap out when you've got a lot of items. Even with Swift, the same is fundamentally true in iOS.

Making a native app that looks 1) unique and 2) nice is terrible. You have to have a team with a designer and developer. Anything less and you're going to be out of the market longer. Making a native app that meets the two criteria above on multiple platforms is incredibly time consuming.

So I've now decided to use Ionic + Angularjs + Cordova. I've been on that platform for 2 weeks now. In that time, I've learned Web SQL, Angularjs, Ionic and enough Cordova to get plugins installed. I am also further along than I ever was in my Android development. It even looks pretty using the default Ionic styling (I got a free UI team by using their stuff).

So even if I accept your speculation that apps will dominate the world. I assume it will be developed on an HTML5 or HTML* stack. That does require "interoperable universal interaction standards".

I'll continue this speculation to say that I think the appearance of apps will merge. There is little reason to have a brand for Android and a brand for iOS and a brand for Tizen, etc. Ionic apps look like Ionic apps without having to spend a lot of GUI logic saying stupid things like, If Android, put the tabs on the top. Again, you need a common standard for this type of design and that is HTML.

P.S. I know that games will suck in JS in the browser view. I know that JS has some serious issues with performance that will probably not be overcome for sometime. I've seen that analysis blog post too. But for CRUD apps like the Pomodoro or Foursquare or LinkedIn, Ionic and its ilk are perfect. The reason is, to beat the horse, is because of advancing open, compliant standards. CSS animations can now be hardware accelerated. JS performance is constantly improving (even if it is a horrible, horrible language).HTML is being banged out to house newer features. This isn't a polemic about how native has no values. It's a polemic against the idea that CRUD apps should have gone native.

>an IE6 game

That's harsh.

It's accurate.

Any technical reason they might offer (sparse array performance) is just facetious. They have the technical know-how to solve such problems, but business wise it makes little sense.

Indeed. They cared about open standards when Microsoft was still dominating and the new categories were in their infancy. Later, they cared because Apple dominated smart phones and tables for some years. But now that Android has an ~85% worldwide marketshare, Google Mail is probably the most popular e-mail provider, and Chrome made serious inroads on the desktop, they feel confident enough to slowly start ignoring standards to lock other browsers and ecosystems out.

Of course, the historical difference compared to Microsofts rise is that hackers always had contempt for Microsoft, while Google is loved in large contingents.

"There's not really a good reason for Google to make applications they create work outside their own run-time environment - Chrome"

Except that the only reason Google built a run time environment in the first place was to encourage people to use their services - that is, the things that collect the data and serve the ads that make them money.

Google has no business reason to block Firefox; quite the opposite, in fact. So it's reasonable to believe them when they say they have a technical reason.

When Google _wants_ to make sure something they create works with Firefox, they take some steps to make that happen. Things like filing bugs on issues in Firefox that are blocking it working and contacting Mozilla about those issues directly via the dedicated coordination mailing list we have set up for issues like this.

None of those things happend with Inbox. There were no bug reports filed, no mention of issues getting it to work, nothing.

So this was a pure business decision to not put any particular effort into making Inbox work in Firefox.

Now you might say that simply writing to standards should make it work in Firefox and if it doesn't that's a problem with Firefox, and I agree. But in my experience "writing to standards" doesn't really describe Google properties very well, especially when they try to push the envelope where standards don't exist yet.

>They have the technical know-how to solve such problems, but business wise it makes little sense.

In this case, the business priority was a release coincident with Lollipop.

There are always more problems that you can solve before you release a product. This is universally true of all products. It doesn't matter how developed the thing is, there are always more things you can do.

But at the end of the day, you do need to ship a product. Which means some of those go un-done. Especially when it's a product in beta where you're looking to get feedback and iterate.

> I'm not 100% sure on how the browsers implementation differs with CSP but there is a main difference in that there seems to be no CSP protected between Google domains in Google Chrome

If this is true, does this mean that Google is short-cutting internet-security for their own applications in their own browser?

Or am I reading this all wrong?

That's the way I read it too and I'm surprised no one else has mentioned this. Unless I'm missing something Google is allowing XSS for their own domains in chrome.

yes. and much more.

for example, even when using open source web kit or chromium they actively removed all options to disable referrer.

go on. try to find it on your current chrome build. or even on chromium thanks to their legacy.

then remember that referrer with its most exposing setting is required for Google to monetize both their organic and paid search.

The only way to do it in Firefox is through the scary and arcane about:config (or an extension). Historically, methods to remove that have not been provided by browsers, whether Google-developed or not. I've always done it via Privoxy, never the browser.

> scary and arcane

i use it every day.

even on firefox mobile!

and it serves my purposes just fine. not to mention you are not exactly right. as you can update those values via user scripts that can be easily distributed or even made as an extension that change those values for you and/or provide a new settings controller UI.

Yeah, and I use the command line every day. Whenever people see it on my screen, they think I'm "hacking".

There are Chrome extensions to do it as well. The point is, the lack of a UI control usable by the average user is not some Google conspiracy. It's always been the standard in pretty much all browsers.

I subscribe to Google Apps for Business ( Gmail, Calendar etc.) The Google Admin console for my company is barely functional in Firefox. Switching menus causes the page to crash and Firefox prompts me to stop the scripts. On the other hand , the same console works fine on Chrome. One could argue that this is because FireFox "is not as fast as Chrome and I should use Chrome if I use Google Web applications". Hmm -- I do recall hearing a similar argument sometime in the 90s.

I think the term "blocking" is a bit misleading. It implies they have it running properly in FireFox and are going out of their way to make it only run in Chrome.

It seems more likely they had an aggressive plan to ship inbox across Web, Android and iOS. And they started with "Chrome only" to save development time. I'm sure support for other modern browsers will follow soon.

Yes, it is indeed functional in Firefox, with some adjustments to their animations, it would be "running properly". And yes, they are going out of their way to make it run only in Chrome since all the rest of the browsers are blocked.

Going into your firefox flags and disabling content security policy does not count as "working in Firefox". Also the linked post reports performance problems.

Never assume malice when there is a perfectly reasonable explanation. They shipped an awesome product as fast as they could. Firefox support is probably coming soon.

> Never assume malice when there is a perfectly reasonable explanation.

A technical explanation? You mean like Google disabling security checks on their own domains, violating internet-standards?

Well yes certainly that would be a problem, unless they also controlled a majority-share browser.

Oh wait. Does this sounds like Microsoft of the 90s yet?

Except that with a few quick changes the application ran, so intentionally blocking seems like a valid description.

Changes that included disabling a browser security policy - not something it's reasonable for Inbox to request its users to do.

But serving all content from a single domain is a reasonable thing for Google to do.

Running is not the same as running securely and with acceptable performance. You don't ship things you know will perform poorly.

That is not true, the application does not run, or at least not securely, with its animations, etc.

Because, you know, "Best viewed in Chrome" is a thing, and somebody is becoming the new IE. It's saddening.

Google have produced a product which offers a great experience on one browser. They are happy with the performance of the application on that browser. They have no doubt tested it on other browsers and found the performance to be sub par. That application is clearly still in 'beta' mode (The app is still invitation only). I am sure that they will 'un-block' the browsers that Inbox doesn't perform well on once they've resolved the performance issues - I'm sure it's also not a slight against Firefox or any other browser. The alternative of course is that instead of this discussion thread we'd have a thread about how poorly Inbox performs on firefox which would damage the products overall reputation.

Or, you know, a third option. They could always do what every other web developer must and make their software progressively enhance so it works at the very least on a few major browsers.

And I absolutely expect them to do that, but when you have a platform you know works well with your software then you'd rather get to market there and then once you have everything working across the board release for all. Again, as every web developer must, release a beta that works under x specific circumstances and then fix for all resulting in your v1.0 product. If you don't do that then time to market doubles or more.

To me that too sounded like the "Occam's razor" explanation from the start. I totally admit Google shouldn't be looked at as saint, but in this particular case at least, I fully understand that performance is a feature (see also e.g. http://blog.codinghorror.com/performance-is-a-feature/).

They also produced a product that leaks user data (mostly to them).

In their book, 'How Google works' they claim to settle with more what's best the user than their customer. That's such a bold claim when you are a monopoly.

I get really frustrated with the monopoly attack on Google, and really, with any attack on a company that is a monopoly through being great at what they do. Google is the best search engine; we use Google because it's really fucking good at what it does. Yes DDG exists but it doesn't compete, Bing is well, Bing, and others don't hold a flame. You may not like that they are a monopoly but for 99% of people, Google is the Internet.

There's nothing wrong with being a monopoly. But when you are, the worry becomes how will you use that monopoly? Will you keep working to push the market forward? Will you keep doing what you do best? Or will you abuse your dominant position to keep competitors out, leverage that monopoly to further your market position in another area, and act in a way that is unfriendly to everyone but yourself?

Microsoft has done it, and got busted. Apple has done it, and got busted (albeit in a fairly small way). People are I think rightfully worried that the same thing could happen with Google. Even more so because of how respected they are with the hacker community and the tech community at large.

It's not about how they got their first monopoly, it's about how they got every one after that and what they do with them that matters.

I think the most telling fact is that Google made zero effort to file bugs against Firefox to help make things work.

A Mozilla JS dev fixed the sparse array bug the SAME DAY it was filed. Note that the bug wasn't filed until somebody saw a Google dev here on HN stating that the sparse array bug was the reason why Firefox couldn't work with Inbox.

A $400B company cannot get their app to work securely & performantly in Firefox, so they’re blocking access via UA sniffing. Seems legit.

Release early, release often, iterate fast. Google's doing these things.

Just because you have the resources to do something doesn't make it a wise use of resources.

Achieving web compat with Firefox (and possibly other browsers) is not a wise use of resources? What?

For an initial beta release on a product with no revenue gains? Yeah, probably not. For later releases? Sure.

Like accessibility, web compatibility is harder to achieve (and requires more resources) when addressed late in the development process. A web app must be accessible and compatible with the major browsers, so ensuring this from the start is the optimal approach.

And it's clear that they were looking at it from the start. If you read around a bit, you'll see that they ran into a particular performance problem with Firefox. They're working to solve it, but decided they could release something usable for Chrome users immediately.

> They're working to solve it,

They are?

They didn't even take the first step to solving it, which is filing a bug about it with Mozilla. When they mentioned the problem on HN, a Mozilla developer filed the bug for them and fixed it within a few hours.

So had they been _working_ to solve it, it would have been solved long ago. Like within days of them encountering it (adding some extra time to pin down the problem, which they _did_ do before not bothering to tell anyone about it).

Still, I suspect Google’s developers are too focused on development in Chrome-only. If true, this may have contributed to perf issues arising in Firefox, in the first place. I also suspect that Google’s web compat team is not sufficient to handle their products.

Did you read the clearly documented technical details? Basically, array slicing on sparse arrays in Firefox is much, much slower than on Chrome.

It's not a matter of lacking competence or skills or anything of the sort. It's a basic question of what level of resources you are willing to put into a product before you have something to beta-test. Inevitably, that's less than the amount required to be perfect in every aspect.

> array slicing on sparse arrays in Firefox is much, much slower

You mean "was", since it's fixed?

> It's not a matter of lacking competence or skills or anything of the sort.

Yes, it is. Not reporting a bug when you run into it but instead just complaining about it is in fact lack of competence.

Arguably using super-sparse arrays in JS is also lack of competence, but the other is much more obvuous.

> It's a basic question of what level of resources you are willing to put in

Filing a bug takes about 5 minutes.

Because they don't want a slow webapp under their logo. And this one would be particularly handicapped by that.

Everyone praises Apple for user experience, right? There you go. They're giving you want you want. And at least Chrome works on multiple platforms, even Linux.

What seems like a more arbitrary limitation is that Inbox doesn't work with Google Apps. Thought it, too, probably has some technical reason deep in the belly of the beast.

Whoa, good to know. But considering that the product is beta, they probably want to test it on regular free customers first...

I removed chrome from both linux and windows and use Firefox all the way. If no Firefox, then I'm just walking away.

Google Inbox is using between 365MB and 460MB, when Ghostery and Add Block Edge is activated, it is more than 600MB. This is where multi process seems to be useful (otherwise it is using much more memory for no real gains), and extensions can be really taxing sometimes.

why do you even bring that up?

also, unless you know what's on that memory and also tell us about total ram I'm just writing this off as anecdotal cache usage.

This is a good exploration of how the blocking is being done.

As far as why, it seems self-explanatory. They're not ready to support other browsers yet. Why does this need to be a thing?

TLDR: 1. Inbox currently using XSS right now, it is disabled by default in firefox. Refer: https://developer.mozilla.org/en-US/docs/Web/Security/CSP 2. Firebox has option to enable XSS, so inbox can work on it. But that allows XSS attacks.

1. Develop app specifically for Chrome

2. Wonder why it doesn’t work well in Firefox

3. Block Firefox via UA sniffing

4. Disband web compat team and use money on NASA hangers, balloons and robots

5. Profit

For those who did not see my comment in the gist, I'll paste it here:

"Probably the performance threshold Google has for its consumer facing products - if it runs slow on Firefox, then it would have normally have been a release blocker."

Google cares probably the most out of any tech company I have seen about performance, especially with any consumer facing apps.

CSP would probably be trivial for Google to fix. Animations/transitions similarly so. The only real explanation that makes sense is performance.

Yet they didn't file a single bug against Firefox!

Key quote from article: ""It's slow, a lot slower than Google Chrome.""

So, InBox (which I really like by the way) is a rapidly developing project and the team only wants to optimize for their own Chrome browser during rapid development -- this seems really reasonable to me.

If InBox does not run well on Firefox and Safari a year from now, then the author of the article would have a valid complaint.

Out of curiosity: does it work in Opera?

There is always a conspiracy theory on everything Google does. I think this has nothing to do with that.

Besides, everyone that has a startup and fresh ideas is always "afraid" of Google next step not stepping on top of its startup.

This generates paranoid among us, its natural given the size of Google.

I want to point out that a while back Apple seemed to "block" -- or at least not implement -- iOS apps uploading on Chrome or Firefox. The page would just stall loading forever, but it worked in Chrome.

tl;dr: here are a couple stabs at why, but I still don't know.

I don't understand the 4 downvotes. The blogger himself says "However, we still haven't figured out exactly why Google is blocking Inbox on Firefox. That the application is not working, seems to not be fully true."

When you decide whether to release a product on a certain environment, it's not as simple as something like:

a) if it works, or seems it would work, on that environment, then we should release it there.

or b) that environment is a competitor, so we shouldn't release it there.

If you think it should be that simple, you never worked with a real product manager responsible for products with millions of users.

Having a product to support a new environment isn't a trivial effort for devs, QA and a bit design. At a particular stage of the product (think about the goals they want to achieve for Inbox at this stage, which I think is something along the line of polishing the product based on mass but controlled feedback), I would've probably made the same decision if I were the product manager.

just like Microsoft was praised for releasing their OS with a free, supported browser. with all the development and qa done for free...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact