And you are here why?

From the README —  https://github.com/google/crunchy “CrunchyCrypt is an open-source collection of cryptography APIs, safe and easy-to-use wrappings of lower-level crypto libraries such as boringssl [and] is designed to be extendable to both bleeding-edge and legacy cryptography.” “CrunchyCrypt has a built-in key versioning protocol, where [payloads are optionally] prefixed with a few bytes of key versioning information. This allows project owners to gracefully rotate new crunchy keys while maintaining backwards compatibility with old keys, even while switching the underlying algorithm.” The key (lol) here is that the use cases are, primarily, safety and ease-of-use. Which translates to ‘this is not a full on openssl/boringssl replacement” Also, in case you are wondering, this is a replacement for   keyczar . From   https://github.com/google/keyczar/issues/213 “Our internal version of keyczar is being rewritten as Crunchy Crypt … One goal of CrunchyCrypt is make...

Heres round two, with an awesome  NSA cameo.   Round 1 can be found here

Brilliance - sheer  brilliance CollegeHumor's Favorite Funny Videos

via GoogleSystem While Google Drive lets you upload any file, the support for files that can't be edited using Google Docs/Sheets/Slides is limited. For example, you can embed PDF files and videos, but Google doesn't offer permalinks for images. So you've uploaded a photo to Google Drive and the only options are to download the file and link to the image page. But what if you want to embed that image in a web page or simply post a direct link to the image? You may think that right-clicking the image lets you copy the image URL, but that's not true. Even if you check the source code of a page or use features like Firefox's "view page info", you'll get a link that doesn't work. Fortunately, there's an easy solution - replace this URL from the address bar: http://docs.google.com/file/d/FILEID/edit with:  http://drive.google.com/uc?export=view&id=FILEID (where FILEID is a long sequence of digits and letters).   This only works if you...

via Information Geographies , we have a chloropleth of the most visited web-sites by country - weighted by that country's internet-using population. The weighting is particularly useful, as it keeps mail.ru from taking over the top-spot due to the sheer size of Russia. The key take-aways? The supremacy of Google and Facebook over any other site on the Web is clearly apparent. We also see an interesting geographical continuity of these two “empires”. Google is the most visited website in most of Europe, North America, and Oceania. Facebook, in contrast, is the most visited website in most of the Middle East and North Africa, as well as much of the Spanish-speaking Americas.  The situation is more complex in Asia, as local competitors have been able to resist the two large American empires.  Baidu  is well known as the most used search engine in China, which is currently home to the world’s largest Internet population at over half a billion users. At the same time...

There is a paper out by Google on how they migrated from MySQL to F1 for AdSense . Its fascinating reading on its own, but its got some key take-aways for scaling and reliability.  I'd recommend going and reading it, but these two are worth emphasizing Scaling Eliminate the R in ORM .  In short, instead of building out a nice layer (hibernate, whatever) between your DB and your code, go the other way, and deliberately expose the workings of your DB to your application developers.  This actually makes tremendous sense - in many ways the advent of NoSQL has been due to people specifically picking data stores that map to their application requirements .  Need a key-value store? Use Riak .  Need a document store wht guaranteed writes?  Use CouchDB .  Hiding the specifics of your data store behind an ORM layer is - increasingly - becoming irrelevant, and Google quite probably just made it official. Fault-Tolerance Use 5 replicas. 5? Why 5...