I use a YubKey NEO-n. It's a tiny device, only extends from the USB port by a millimeter or so... just enough that you can touch it to activate it. I just leave it plugged into my laptop all the time, so there's no "fumbling with USB sticks", I just run my finger along the side of the laptop until it hits the key. It's extremely convenient.

There's an obvious downside of leaving the key plugged into your laptop, of course. If someone steals your laptop they have your key. However, in order to make use of it they have to have (or guess) your password as well, so it's really only a risk if someone is specifically targeting you, in which case they could also steal your phone. Well, it's also a problem if you use a particularly lousy password, and if you don't notice that the laptop/key are gone soon enough that you can disable the key before the attacker guesses your password.

FWIW, Google switched to using security keys for corporate account authentication a while ago. Google's security operations team determined that the risk of theft of a security key is actually lower in practice than the risk that an employee's phone-based OTP might be phished. I would have thought that Google employees were too smart to be phished... but I suppose resistance to phishing attacks is as much about social intelligence as anything else, and Google hires a lot of socially inept people.

This is the core issue. When evaluating what should be done you have to consider available technology... and in this case your baseline is 10-20 years ago because old systems don't get replaced very often and for new systems backward compatibility is important, as is minimizing the number of distinct products you have to manage.

Exactly. The goal is to avoid being the easiest target around.

If bad guys wanted to work hard they'd just get a job. There are contexts in which the value of a target justifies expending a lot of effort, but they're the exception. In every case real security is all about correctly understanding the threat model and then applying adequate mitigation.

I was... and security was not successfully achieved by litigation, nor even by ITAR restrictions. I think I still have my DeCSS t-shirt somewhere, with the code printed on the back. At the time that t-shirt was arguably an illegal munition, which of course is why it existed and why I bought it.

That's your opinion, but it's not widely-held. I certainly don't agree with it, and I sincerely doubt that all of your downright genius acquaintances at Google stay out of mere inertia. It's much more plausible that they stay because they find it a better place to work than the available alternatives, for whatever combination of reasons. I do, and I've seen a lot of alternatives.

I do... because that's a few less milliseconds my CPU isn't idle, which reduces battery life.

Seriously, does anyone understand this benchmark? I see pairs of performance and battery life numbers which seem to have no real-world meaning, so it's not at all clear to me why it makes sense to compare them. In addition, it's common that for a given set of tasks, a device with better performance will use less power because it spends more time in an idle state. The notion that devices trade off performance against battery life makes little sense in the ARM world.

Maybe this actually does say something useful, but if so I'm too dense to see it.

The structure varies from device to device, yes. On the Nexus devices I'm most familiar with, which don't have SD card slots, there is no real sdcard partition. There is an /scdard, but it's a symlink. The advantage to not having a separate partition is not having to create a hard decision about how much to allocate to /data and how much to /scdard. This is one of the benefits of MTP over UMS that I mentioned, and it means that in terms of storage allocation you need only talk about /data, since it's the only r/w partitiion (except for actual SD cards, of course).

Given the other sub-thread asking about the conversion to Libraries of Congress, apparently it can be used to measure data content as well.

Yes, it was. The problem with UMS is that it's a block-level protocol, not a file-level protocol. This means that when storage is mounted via UMS, the host has no way to coordinate with the target device, which is a big problem if the target device is actually operating on the file system. Basically, it's not safe to have two operating system simultaneously using the same block device.

Because of that, when Android acted as a UMS target, it had to unmount the file system, which had all sorts of unpleasant effects on the system design. Among them, it forced the user-writable data to be partitioned into the portion that could be accessed via UMS and the portion that could not, which required guessing how large each should be. That enforced separation also added all sorts of subtle complexities to the OS, which had to take into account when /data was available and when it was not. SD cards have this same complexity, but core OS operational data isn't stored on them. Finally, it also forced the UMS-mountable data partition to be vFAT, which created many limitations around both functionality and (especially) security. /data could be ext3, or f2fs, or whatever, but MTP support is better across desktop OSes than support for random Linux file systems.

MTP is a file-level protocol. It leaves the Android Linux kernel in charge of managing the file system and just provides an API for browsing and manipulating the files, without exposing details of the file system representation.

UMS is like attaching your hard drive directly to another machine. MTP is like running an FTP server.

So, why don't they move, if they're underpaid and there isn't anything different about Google?

I don't think so, and I spent 15 years working in and around large banks. I've never seen a self-nomination/promo-committee process anything like Google's. I'm not saying Google's is especially good (though I do think it's better than many alternatives I've seen, especially the ones which depend mostly on your manager's political clout and the ones that are all about checking all the right boxes), but I don't think it's comparable to anything in the financial industry or anywhere else outside of Silicon Valley (most of Google's processes are modelled on Intel's).

Again, I don't see this. If that were true, all of my colleagues and I should be able to get a significant raise by moving, and as far as I can see that isn't the case. I've made a habit throughout my career of maintaining good ongoing relationships with a few headhunters and always being willing to talk about opportunities... and as soon as I tell them what I'd have to have to leave Google, they start talking about management positions, not individual contributor positions (what I am) or even team lead positions (what I've been and likely will be again soon). Granted that I'm not in SV; but Google would give me a raise if I agreed to move there, so I think I'd still be in more or less the same position.

Of course, I only have detailed knowledge of my own situation, but I don't see many (any, actually) colleagues leaving for better pay. In fact, everyone I know who has left has done it for personal reasons (location), or to go to a startup where they usually take a hefty short-term pay cut in exchange for heavy equity that they hope will someday explode. The latter happens mostly because Google pays so well, actually. After a few years of accumulating Google stock grants, most people can afford to take some financial risk, shooting for big rewards.

I was talking about the phone as a target device, and my explanation as to why it changed to use MTP for that purpose is correct. You and the GP were talking about it as a host. I don't know why stock Android doesn't acts as a USM host.

This is the reason I like working for Google. I've worked with dozens, perhaps even low hundreds, of engineers over my four years with the company and in that time I only ran into one idiot.

I also have to disagree somewhat with the GP's characterization of Google. I spent 20 years working in ordinary large enterprises (as a consultant I saw many), and Google is dramatically different. Oh, there is some amount of bureaucracy creeping in. I think that's unavoidable in a company with tens of thousands of employees. But the company fights it really hard, and with a fair amount of success. It's not perfect, but it's the best place I've been, large or small.

Regarding pay, seems pretty good to me, particularly when you include bonuses and stock grants. I don't hear a lot of complaints from my colleagues, either.

(Disclaimer: I work for Google, not as a statistician, but I do have an interest in statistics, subscribe to internal stats discussion mailing lists, and occasionally talk to Google statisticians.)

From what I can see R is a lot more heavily used in Google than Matlab. The article's focus on Matlab is odd. Personally, I mostly use Mathematica. That's less because it's ideal (I haven't learned R so I can't compare, really) than because I already know it.

That said, Google definitely is interested in people who can extract knowledge from data, using whatever tools.