timothya

Good catch. I skimmed that page quickly and saw 10 GB and didn't look closer. Sorry for the confusion.

They really need to increase the maximum file size to be competitive. As a comparison, Dropbox files can be up to 10 GB each[0], and Google Drive files can be up to 1 TB each[1].

[0]: https://www.dropbox.com/help/5/en

[1]: https://support.google.com/drive/answer/37603?hl=en

Super-cool game! I was doing well until Level 9 when they started swapping the left and right controls. I couldn't wrap my brain around that and lost all three points that round because of that.

In fact, they do more than just talk: they often publish papers describing how they work. The open source community has since recreated a lot of them, which has proven useful to a lot of people (e.g. HBase, Hadoop, Apache Crunch, etc.)

I'm not sure why exactly I would need this (I don't need a cup to tell me what I'm drinking, and I don't find it difficult to keep track of my beverage habits).

This is interesting from a technical perspective, though. How does it know what's in the cup?

A lot of people are complaining about putting this into CSS, but I think that people are forgetting that using null transform hacks[0] is already the status quo for making animated elements more performant.

What this property does is lets us continue doing the same thing, but in a way that the intent is clear ("I'm using this property to make the animation on this element more performant" vs. "I want to add a transform that does nothing"). Furthermore, it lets the browser decide if it wants to add any optimization, and it can decide which sort of optimization is best.

While it would be nice if we didn't have to do this hinting at all, the fact of the matter is that it's hard for the browser to predict what will happen on the page in the future, and we're already having to do this (just in the cryptic null transform way), so it's nice that the web platform is letting us do it in a standardized way that communicates our intent clearly.

[0]: http://aerotwist.com/blog/on-translate3d-and-layer-creation-...

Here's the paper on how this works: https://media.blackhat.com/us-13/US-13-Stone-Pixel-Perfect-T...

If you're watching a video and your connection becomes slow, it prompts you to take a look at the report to understand what's making it slow.

It's not a direct phone number, but a reasonable number of average people will hopefully take a look while their video is buffering and start to understand that their ISP may be the reason YouTube seems slow.

I just came across this on Twitter: https://github.com/warewolf/truecrypt/compare/master...7.2

This is supposedly the commit for the 7.2 release. Just looks like a bunch of code replaced with the app aborting as insecure.

I'm not sure how legit this is, the repository was just created a few minutes ago. Apparently there is a new binary release that goes along with this, though.

[I've created a fork here just in case the original goes down: https://github.com/timothyarmstrong/truecrypt/compare/master...]

I've been to Japan, and my iPhone didn't make any shutter sounds while I was there.

I don't disagree; I think that slow rollouts of large products make sense from a technical standpoint (you can make sure that nothing breaks down at the large scale, and fix problems before they become a big issue), but I think that invite-only betas which last weeks or months can often hurt product uptake.

I was just clarifying that the invite-only stage didn't last more than a year.

It was in the invite-only stage for less than 3 months.

That's an interesting use case, but the only time you're actually using Google Hangouts is when you're already in a conversation with someone, so I imagine that's not where most people would go when they want to schedule a call with someone.

When I think about scheduling, I immediately think about Google Calendar or Google+ Events, because that's where I would go to schedule any sort of event (with a video call or otherwise). Both of those places support adding a Hangouts video chat to an event.

He was also one of the two people who prepared the fix for Heartbleed in OpenSSL[0].

[0]: https://github.com/openssl/openssl/commit/731f431497f463f3a2...

I want to know this as well. Google Drive also will stream your media, and allows files of any filetype for general storage. Also, easy sharing with anyone anyone on the web (even people who don't have a Google account).

Chrome also has a button[0] to do this automatically in the Developer Tools, which is what I used when I wrote the initial comment.

[0]: https://developers.google.com/chrome-developer-tools/docs/ja...

It's tricky to tell exactly what's happening because the code is obfuscated through compilation, but as best I can tell, it's using the `answer` value to prevent another global from making it seem like the Analytics code has already been initialized.

There is a JavaScript object representing all of the Google Analytics state and functions. When this object is set up, they add the property "answer = 42" to it. Then, before making this object globally accessible at `window.ga`, they double check that `window.ga` does not yet exist or that `window.ga.answer` does not equal 42. If it already equals 42, then the initialization must have already happened (maybe the Analytics code was included twice?), and so it doesn't proceed to clobber that already-initialized global Analytics state. Checking that the `window.ga` variable doesn't exist is not quite enough, since other JavaScript on the page may have set that property for some reason (of course, this logic wouldn't work if other code on the page had simple set `window.ga.answer = 42`, but that's unlikely to happen by accident). As long as it looks like the initialization hasn't already run, then it goes ahead and does the initialization and makes the result globally accessible at that point.

tl;dr: It's not just a joke; it's actually used to make it less likely that other JavaScript on the page hasn't created a global variable called `ga` which may otherwise prevent the Analytics code from running.

Yes, it should be one of the first things you learn when learning JavaScript. JavaScript only has function scope, meaning that you only get new scope inside of a function.

Remember that this is likely to have touch and voice input too, unlike the Pebble.

The real login page is on a *.google.com domain, of course. But this phishing scheme is on a different domain, namely https://googledrive.com/...

Which they don't. Google Drive data is served from a different URL for precisely this reason.

I couldn't find a page that looks exactly like the screenshot, but the Google Scholar page is pretty similar: http://scholar.google.ca/scholar?q=search

Then again, this article is from Google Ventures, so maybe they are just using internal design resources.

Then it should really make sense why they are purchasing a company that does login better.

Side question: What is long and convoluted about Google's account management? It's one account with a single login which works across all Google products. Seems pretty straightforward to me. It only gets a bit more complicated if you try to disable parts of your account, but that's not the normal use case.

It's interesting to me how entitled people feel to get a public SDK. Presumably there was a reason that Google chose to not release it until now; the usual reason is that Google doesn't want people building apps on unstable APIs, because that means a bad experience for both consumers and developers. I'm personally happy that they spent the time to actually make the SDK solid.

You could do:

    var boundEvent = handleEvent.bind(this);
    document.addEventListener('click', boundEvent);

and later:

    document.removeEventListener('click', boundEvent);

This situation is a bit messier, though, because you have to keep track of both `handleEvent` and `boundEvent`.

The big difference is that unlike `apply` (and `call`), `bind` does not call the function, it just gives you a new function that you have to call later (or use as an event handler).

`bind` returns a new function, which has it's context `this` set to whatever you pass in, along with arguments partially applied.

`apply` calls the function, using the context object you provide and the arguments provided in an array. (`apply` also has a sister function `call`, which also calls the function with the context object you provide and the arguments you provide individually).

I've used bind to do partial function application for quite a while, and it really is a convenient pattern to use. It does have the downside that it's a bit harder to quickly understand what's going on, though, since the arguments being passed into a function can come from different places.

My common use case is when I'm setting up event handlers and I want the event handler to know about a companion object I have to the element in the DOM. For example:

    MyObject.prototype.buildDom_ = function() {
      for (var i = 0; i < buttons.length; i++) {
        var button = new MyButton(...);
        this.myButtons_.push(button);
        var element = document.createElement('div');
        element.addEventListener('click', this.handleClick_.bind(this, button));
        this.rootElement_.appendChild(element);
      }
    };

    MyObject.prototype.handleClick_ = function(button, clickEvent) {
      // I have access to the MyButton instance passed in.
    };

In this case, I use the partial application to pass in the MyButton instance so that when I'm in the handler for a button click, I have access to the original JavaScript object that was created when the event handler was set up.

I agree that automatically-updating extensions has the potential to be somewhat insecure. However, I don't see how the alternative could be a better alternative. If they didn't auto-update, then the majority of users would likely never update their extensions, and the ones that do would be unlikely to audit the extensions that they update for malware. Do you audit the apps on your phone before you update them?

To mitigate the problem, Chrome does have the permissions model to limit what extensions can do, and if an extension requires more permissions after an update, Chrome will give you a warning, along with an option to remove the extension. Your best defence is to not grant overly broad permissions when you first install the extension.

Regarding your comment about Chrome's automatic updates being "bad", I disagree wholeheartedly - the web platform would not be able to move forward at the same rate that it can today. One of the biggest problems with IE was simply that it was updated so infrequently that it was really hard to support the large percentage of outdated versions. We'd be in the same situation with Chrome if it didn't auto-update. Furthermore, I trust Chrome to make good decisions for my security. I'd rather have my browser updated quickly so that vulnerabilities in the browser can be fixed quickly before they affect me.

> All IPC happens using the Chromium IPC libraries

Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.

I think the point he is trying to make is that most people think they understand it when they really don't.