Google man opens curtain on cloud apps firewall glitch As Google builds HTML5 offline access into its Google Docs web-based word processor, the company has introduced a change that inadvertently causes problems for some netizens using the service behind a network firewall. Google will not reverse the change, saying that it's required for offline access, due later this year. But it …
"As a firewall admin for a large company, it's shit like this that only reenforces my "fuck the cloud" mentality."
Crumbs - you open ports to individual servers outbound on the web? I'd imagine opening port 80 and port 443 on a per IP basis could get a little tiresome. You should try one of those new fangled web proxy security gateway thingies. VoIP and old school Exchange must really wind you up with the range of ports and protocols they use...
"[VPNs]* are prohibitively expensive, to the point where Google cannot feasibly add new ones"
Can someone shed any light on this statement? Does he mean expensive financially, or computationally? or in some other way?
And either way, surely Google could afford it?
(I'm not having a go here, I'm actually curious to know what he means)
* VPN / VIP - yes I know he said 'VIPs', but from the context it seems he means what we generally think of as VPNs. Correct me if I'm wrong.
That whole section of the explanation makes no real sense. To take it again;
"In order to connect over SSL (which we use for everyone for security reasons) we need to set up a virtual private network (VIP). VIPs are prohibitively expensive, to the point where Google cannot feasibly add new ones. To get around this we added docs as a something called a subject alternative name (SAN) on one of our only existing VIPs (Gmail's)"
1) SSL isn't a virtual private network, not really. SSL VPNs exist, but Google Docs isn't one.
2) A virtual private network doesn't become "VIP" when you make it an acronym. it becomes "VPN"
3) VPNs are expensive, but you're not creating a VPN when you connect to Google Docs.
4) The term VIP is used by F5 (and others) to signify the external ip clients connect to before being reverse proxied and load balanced to back end servers. Which presumably Google are, although I've no idea if they use F5s for that or something else. Perhaps he believes setting up a new VIP would be expensive, although I can't think why that would be true ...
It reads a bit like he's a bit vague about this part, got himself in a muddle and just kept talking / writing.
I'd also question whether this is actually a firewall problem, or a proxy server problem. I don't know anyone who blocks sites by domain name on their firewall. They may well do so on their proxy servers.
Wait a second.... "But on the SPDY mailing list, Google has said that SPDY is enabled in Chrome and Google servers for SSL traffic."
Since (most) webservers don't compress HTTP headers (normally) (hence why they "already developed a prototype web server" to use the spec), wouldn't SPDY require Chrome to bounce through a Google compression server before finally dumping the data to your browser in order to "speed up" "normal" websites that don't support SPDY? The only thing I can see being able to take advantage of this spec would be Google-hosted sites (Google Apps for instance). In this case, SPDY is next to useless unless (most) everyone gets on board.... But to use SPDY with non-supported webservers over SSL would require such a "bounce" server to be able to decrypt, compress, and re-encrypt an SSL session.... I may be totally off-base though, and inferring the SPDY system is trying to do more than it actually can, in which case, there's no issue. Yet.
First, you said that they wanted to have more than 6 users able to collaborate on a document at once. That's not the problem. The problem is having more than 6 documents open at once.
Second, to Ammaross Danan.
SPDY isn't used for everything. It's just being used experimentally right now. I did a packet capture to double check, and normal websites are all still loaded with vanilla HTTP.
The fix involves whitelisting gmail, and in the discussion, people are saying that Gmail is blacklisted by policy. Wonderful.
I will count that as a Fail from Google, I'm afraid. They should have seen this coming. Considering how much they are hoping to convince people to use Google Apps, this looks really bad.
As my old CS professor used to say:
"My dear, you cannot have your d*** in your both hands and your soul in paradise."
Or the more tame version for the few lady students taking a CS elective amidst us at that time (25 years ago):
"Dear, there is no such thing as a a little bit pregnant".
You ether use Google services or you do not. If you try to use them while blacklisting them at the same time, complaining that they do not work is disingenuous at best.
"The fix involves whitelisting gmail, and in the discussion, people are saying that Gmail is blacklisted by policy"
or... get a Firewall which actually blacklists what you asks for. It seems that part of the problem stems from firewalls lazily assuming that a certificate named mail.google.com is only being used for that subdomain. Sounds like the firewall companies didn't read the bit about Subject Alternative Names.
So the actual problem is that there are sites wanting to *block* Google Mail but also rely on Google Docs? Considering both are within *.google.com, it was never more than dumb luck that such a setup worked in the first place. For that matter, I'm surprised they used a separate SSL certificate for *.mail.google.com, rather than using *.google.com for it all - which would avoid SSL complaints about the SAN.
Yes, if your firewall policy requires discriminating between foo.google.com and bar.google.com over SSL, it will be difficult - but then, it probably isn't a very bright policy in the first place. The world would be a better place without firewalls and firewall admins like that. Block Google, don't block Google, just don't block them then whine when their services stop working for you!
Why doesn't Google just use WebSockets for this instead of pushing people to their own browser and protocol? Wasn't one of the goals of that precisely to allow real-time time collaboration?
Google has been one major contributor to HTML5, even the spec editor is a Google employee. I'm sure they could see this problem coming.
Finally am I the only one shocked and the rats nest of a solution needed for even a simple feature? How many man-hours have gone into devising this solution? When we weren't trying to run everything over the Web protocol this would have been simply done with a single IP and port.
Is this really the future?
The current Web Sockets specification are not suitable for practical use as there are numerous security flaws that have been discovered with in the current draft specification.
Which is why the code has been disable on most of the current browsers, Safari, Firefox 4 has disabled and Microsoft did not even brother with it. . I believe Chrome still has it has standard but if people are complaining about about reconfiguring there fire walls, imagine the complaints google would get if Google Docs only worked on Chrome.
I believe the current specification is being rewritten to be secured. When this will be done to a level where it is practical to implement this in a mainstream product is anyone guest, unless it already have been and I have heard about it.
I use various Google tools for my own purposes but I would never consider using them, or any other cloudlike object for anything that involved confidential information. That pretty much rules it out for the 3rd biggest employer in the world (At least until NHS "reforms" bite.)
I can guess that the Indian railway probably wont care too much about using goggle docs, considering how well (or little) they respect IP and software licensing, they're probably all using MS office, the government probably bought 1 copy and sent it around to the entire government...
If you were referring to NHS, the 5th largest employer in the world, yeah they're probably gonna be a little pissed, especially since they recently told M$ where to stick it...
1 Chinese Army 2.3m
2 Walmart 2.1m
3 Indian Railway Service 1.6m
4 State Grid (Builder of Chinese power grid) 1.533m
5 NHS 1.3m
Have a nice day!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
