Posts tagged google

The security and data protection measures implemented at Google Data Centers are extensive and impressive, as revealed in an official Google Apps video tour of a South Carolina center. It’s like something out of a sci-fi movie: constant surveillance and security presence, highly restricted access, special lenticular printed badges, biometric identification like iris cameras, hard drive location tracking, files indecipherable to humans, rigorous redundancy, “robust fire detection and suppression capabilities” with data being automatically shifted to another data center in the event of any disruption, “video analytics, that are designed to automatically detect anomalies in the video and alert security staff to investigate further,” and in some cases, “sophisticated thermal imaging cameras that can identify potential intruders… using heat signatures,” allowing staff to monitor data centers under any conditions, with carts, jeeps and scooters for rapid response (with local law enforcement on-call). Then there’s the secrecy, with “additional safeguards… that we do not disclose publicly.” My favorite part, however, is the multi-step destruction process:

For hard drives that have reached the end of their life, Google has a destruction process that is designed to further ensure that none of the data on that drive can ever be accessed. The drives are destroyed in a multi-step process. One device that is used to destroy old hard drives is known as the crusher… A steel piston is pushed through the center of the drive, and the platters are deformed, making them unreadable. Another step in the process is the drive shredder…

Once drives have been sufficiently crushed and shredded, they are recycled. Watch the video for all the wonderful detail. The crushing starts around 3:30, but the whole video is interesting if you want to see how Google manages data behind the scenes.

Options are generally worse than just making the right decision up front.
They have a cognitive cost to users (try skimming the options in Seamonkey or Opera). They don’t solve the problem for the 90% of people who don’t look in the options. They increase code complexity. They increase testing burden and generally the non-default choice gets accidentally broken a lot.
Options are often a design cop-out. It’s better to make a firm decision.

Google Chrome Software Engineer Peter Kasting (pkasting), in a reddit IAmA thread where him and two other members of the Chrome team answered user questions. In an earlier comment, he explains how simplicity is maintained: “I don’t think people realize that simplicity comes from a willingness to say ‘no’ to a lot of requests. I’ve made a lot of people angry on the bug tracker by closing their bugs, but that’s an important part of what it takes. (Note, I’m not suggesting we should never listen to our users; I’m suggesting that tradeoffs are an inherent part of design.)”

Eben Moglen on the dangers of centralized social networking, in his excellent keynote at The Free and Open source Software Developers’ European Meeting (FOSDEM) 2011 in Brussels, Belgium on February 5, 2011 (full transcript here):

Social networking—that is, the ability to use free form methods of communication from many to many, now, in an instantaneous fashion—changes the balance of power in society away from highly organized vehicles of state control towards people in their own lives.

What has happened in Iran, in Egypt, in Tunisia—and what will happen in other societies over the next few years—demonstrates the enormous political and social importance of social networking. But everything we know about technology tells us that the current forms of social network communication, despite their enormous current value for politics, are also intensely dangerous to use.

They are too centralized, they are too vulnerable to state retaliation and control. The design of their technology, like the design of almost all unfree software technology, is motivated more by business interests seeking profit than by technological interests seeking freedom.

As a result of which, we are watching political movements of enormous value, capable of transforming the lives of hundreds of millions of people, resting on a fragile basis, like for example, the courage of Mr. Zuckerberg, or the willingness of Google to resist the state, where the state is a powerful business partner and a party Google cannot afford frequently to insult.

We are living in a world in which real-time information crucial to people in the street seeking to build their freedom depends on a commercial micro-blogging service in northern California, which must turn a profit in order to justify its existence to the people who design its technology, and which we know is capable of deciding, overnight, all by itself, to donate the entire history of everything everybody said through it to the Library of Congress. Which means, I suppose, that in some other place, they could make a different style of donation.

This problem is directly related to the issue of dominant market share and the high cost of switching services. For an alternative to make any significant impact (like the federated networks that Moglen and others see as crucial), it must integrate with existing services and maintain compatibility, allowing the services to co-exist and the transition to be seamless (more on that in a later post).

The technical capability was there with Google Gears, and Google even helped get offline app cache implemented in HTML5. Yet Google Gears support (and with it offline access) was disabled in Google Docs at the beginning of May in favor of HTML5, with the promise of it returning soon, and in June 2010 for Google Reader (perhaps permanently, which would be a shame). It’s been more than six months, and while the Chrome Web Store brought various offline-capable web apps, Google cloud apps were not among them (although some apps developed by Google were, like Clock and Scratchpad). Even the mobile version of Gmail has offline access with HTML5 (although Eric Schmidt did say Google has a “mobile first” strategy). When the Chrome OS pilot program was announced, Google Docs offline support was said to be coming early this year, so it’s safe to say it’s right around the corner. I would say the same about Gmail, considering the amount of time it’s been (and in June 2010, a Gmail engineer said Gmail’s offline support would eventually be migrated to HTML5). Furthermore, offline support is a very important feature, especially with Chrome OS, and when Google wants Google Docs to replace desktop software. The fact that Google Docs and some other Google cloud apps can only be used with a reliable connection is a major hindrance to moving entirely into the cloud (which is what Google seems to want). Offline support through HTML5 must surely be coming soon — but I’ve been thinking that for months, so what’s taking so long?

[Answer this question on Quora, where I originally posted it]

(Source: qr.ae)

Juan Carlos Perez writes that Larry Page’s replacement of Eric Schmidt as Google CEO “begs the question of whether the company is trying to fix something that isn’t broken.” This is missing the point that something doesn’t need to be broken for changes to be made, not in the interest of fixing a problem that doesn’t exist, but because a shift (of focus and management structure) can be beneficial in its own right. Google’s never been afraid to shake things up because they can, not because something is seen as “broken.” Over the last year especially, Google has shown its tendency for bold decisions and innovation where none was demanded — withdrawing operations from China, a redesign of its core service (search), Google Instant, self-driving cars, Chrome OS (announced in 2009), the Nexus One and Nexus S, Google Wave (despite its demise as a Google product), and more — and this move should not be seen any differently.

No one expected Schmidt to step down as CEO, but neither did anyone expect innovation from Google in established areas like e-mail (Priority Inbox) and search (Google Instant).