There's a number of tradeoffs to be made between internal secrecy/silos and trust/openness in any company, and google tends to lean heavily towards trusting their employees when it comes to corp data + resources, designs, strategy etc.

User data is an entirely different matter, and is appropriately treated as such.

It doesn't need to be about "secrecy", it's about "security". Even when you ignore the employee trust issue, and assume everyone at your company would never betray you, "least privilege" is still not just best practice for security, it's common sense.

People should not be able to access data they don't need. If they need it, you can grant it. But the assumption should be that someone who doesn't use the design server shouldn't have access to the design server.

I don't want to know about or see information I don't need to have at work. It's not that I'm not trustworthy. It's not that I would abuse it. I just don't need the liability that it gets out through me.

Because your account credentials could get stolen. Your laptop could get stolen. Your laptop could get hacked into. Your laptop could get malware. Reducing the list of people who have access to a resource insulates against all of these things... automatically. And sure, all of those risks have other ways to mitigate them as well. But layers of security is key. And hey, it also stops employees from sneaking off with your data too.

Stealing a Googler's laptop or account credentials don't get you access. At best, you might get temporary access to my gmail in the browser. I could give you my username and password and you could accomplish nothing.

Googlers all have to use 2-factor access via hardware tokens, so you'll need to steal their laptop and steal their token, and murder the employee before they report it to security.

Google laptops only permit the installation of software from Google, they are locked down and don't allow arbitrary installation of software, much like an iPhone. Those using Chromebooks are even safer.

Having to ask permission for every thing not only adds huge overhead, it inhibits global code gardening and technical debt reduction, and it inhibits learning, because you don't even know if you need to ask permission for something until you see it. You don't know what you don't know. If I want to learn about Google Translate because it might benefit my project, asking permission is bureaucracy, because I don't even know if what they have will help until I see it, and if I had to write a long justification for access rights, I probably either don't have a clue why I really need it, or might just not bother because of the hassle and seek out other open resources.

I feel sorry for you if you work for a company that operates internally like North Korea. One of the rewarding things about working at Google is the constant learning experience of exploring other people's stuff.

Having access to code and data you don't technically "need" is often how people learn new skills and advance their careers without leaving the company. It's an important part of the culture.

Why is "the culture" always used in Silicon Valley to justify incredibly bad decisions?

Again, "bad" is your opinion. People aren't machines: how much trust you place in them affects your relationship with them. Culture is about your team's interconnected relationships.

For example: Smaller companies often have the luxury of more trust / transparency. As companies such as Google grow, they have to resort to things like sending internal notice of big announcements very close to when the actual announcements come out (because leakers). If you have 10 people, you can usually trust the whole team.

Google tries very hard to allow as much transparency and openness as is allowable for its size. It fosters a culture of trust. Logging access rather than restricting it is one of those culture moves. It makes employees feel trusted, and puts responsibility on them to behave ethically. When they don't, the other end is that Google can still take legal action.

Culture isn't a fake floofy thing, it's real.

Their model was "trust the employee, and use the courts to enforce punishment if that trust was misplaced."

We are in phase two of that right now.

I'd like to add to what other people are saying here. I've worked at a company where people were given, basically, the minimum level of trust. All the horizontal projects were dead, teams competed with each other for the same clients, and we chose meeting rooms to avoid being overheard by other teams when we were discussing things.

It sucked. I left.

This is entirely not related to what we're talking about here. It's not about trust, it's about good practice. If someone needs access to something, they request it, you grant it. Simple. But there should be common sense controls on data access, for everyone's benefit.

You're talking about a hostile work environment. I'm talking about a secure one.

That's more than just an oversimplification.

Security is inherently hostile, I don't see any other way of putting things. We tolerate a certain amount of hostility in order to reap the benefits that security gives us, and we tolerate a certain amount of vulnerability in order to reap the benefits that laxness gives us.

> If someone needs access to something, they request it, you grant it. Simple.

The saying goes that for every complex problem, like security, there is a simple solution, like that one, and that solution is wrong. The cost of such a process is just too high for most companies. You have to request access, explain why you need access, someone has to review it, then grant it. That's how it worked at the company I was complaining about. Processes that should take minutes took hours, those that should take hours took days.

Security, like so many things, is subject to cost-benefit analysis. Better security systems use the full triad: prevention, detection, and response. From the article, it sounds like these are working as intended. The security team detected the exfiltration and responded with a lawsuit. Trying to rely only on prevention will just lead to paralysis.

I might also be jaded, because when I hear phrases like "good practice" my instinct is that it means "omitting the cost-benefit analysis."

The problem is, it doesn't seem like prevention or detection was working here at all. Even though they clearly collected enough data to reconstruct what happened, they both failed to prevent this, by not having even common sense security protections, nor did they detect it when it occurred, only finding out because a supplier ratted out another client.

These are not high cost processes, these are basic, common sense practices we're talking about, that nobody really has any excuse to not have in place.

You are continuing to let your experience with a single, hostile work environment cloud your openness to something that... isn't even controversial. If you aren't locking down your files to only those who need them, you aren't equipped to be in business. If this is somehow uncommon among Silicon Valley, it explains why so many "they stole our trade secrets" lawsuits are going on right now.

> You are continuing to let your experience with a single, hostile work environment cloud your openness to something that... isn't even controversial.

I'm flattered that you want to talk about me, but really, I'm not the subject of the discussion here, and it's inappropriate to talk about what's going through my head or to try and psychoanalyze me.

> These are not high cost processes, these are basic, common sense practices we're talking about, that nobody really has any excuse to not have in place.

I've worked at a few different places on this spectrum in my career. Three of them have been fairly open, internally, like the way Google apparently operates. Maybe there are some high-value IP repositories you don't have access to, but you mostly have access to any source code you want to look at without getting access reviewed first. These companies were very open about the risks that this entailed, and openly discussed the fact that leaks were possible. The benefits became rather clear the longer I worked at each place. Whenever a system I worked on interacted with another system, I could follow what the other system was doing and even submit patches to other systems if necessary.

Saying that restrictive security is "common sense" or "not even controversial" is begging the question and argumentum ad populum, respectively. My argument here is that there are benefits to open access to most company IP, and that these benefits are important enough that the decision should be made on a company-by-company basis.

The access controls that would have prevented this particular case from happening would have to be rather draconian indeed. Anthony Levandowski's work was basically the genesis of autonomous vehicles at Google. Google purchased Levandowski's autonomous driving startup, 510 systems, in 2011. I don't know what kind of access controls you'd need to prevent a startup founder from accessing the technology built on top of his company's IP.

So, the head of my department doesn't have access to... most of what I do. That isn't to say she isn't in charge, or doesn't have every right to see that information. But it isn't her job, and she doesn't need that access, so she doesn't have it. If she needed it, she'd get it. There's no trust issue here, she is completely trustworthy. But her not having the access protects her just as much as it protects the rest of the organization. Because she doesn't have to worry about any risks to that access through her credentials.

In this case, Waymo has a design server, Anthony clearly didn't work on it's contents, because he didn't already have the software to access that server on his computer. Therefore, regardless of the source of the IP (which isn't his, he sold it), he really shouldn't have ever been given access to it. When the server was first spun up, access should've been given to... the people who would be using it, and nobody else.

Of course, if at some point he did need to access those files, he could ask, and be granted that access. And that doesn't need to be a difficult process (granting access to things takes an IT person a minute or two), but there is now an additional person that knows that user has been recently added to access. Even informally, this is a pretty good security measure, because in most cases, it should be fairly obvious why someone needs something. And if it's not obvious, and maybe that employee has been, as the article says, talking about leaving the company and replicating the technology elsewhere... suddenly that IT person maybe has a reason to mention the issue up the chain.

Where I work, I can make changes to what I'm working on that break things far away, from time to time. In well designed systems this doesn't happen too often, but you might be surprised sometimes how a seemingly insignificant change can make a system fail somewhere else because someone made an assumption that is no longer true.

So I can make a change, see that it breaks some test somewhere else (failed CI test), and peer into the diffs on the opposite side of the code base to decide what to do about that. It's proven quite useful, from time to time. I've seen weird problems like hitting pessimal access patterns for software developed halfway around the world.

> Anthony clearly didn't work on it's contents, because he didn't already have the software to access that server on his computer.

That doesn't follow. I work on a source code repository every day, but I'd need special software to exfiltrate a copy. Same with the various design documents and things I work with—all stored in a private cloud. If I wanted to exfiltrate it I'd get a script to do it automatically.

Remember, this wasn't just the guy who started the autonomous driver project. He wasn't just the "department head". He's an industrial engineer who founded a Lidar startup. The idea that he should be denied access to Lidar design documents is patently absurd.

Apple implements very restrictive internal secrecy, yet leaks haven't been stopped. So what's the point? Live in a police state, still get leaks, or live with freedom and benefits, and get leaks. I'll take the latter.

There's a huge difference between security of user data and security of company secrets. Having access to the latter is not unreasonable; access to the former should be heavily restricted and closely monitored.

And it is.

There's a huge difference between employees being able to see our source repository, and employees being able to see user data or secrets. Generally, Google values its openness internally, and most employees can see the source code of most projects. In fact, that's how large scale refactorings and bug fixes work: I find a bug, I might have to fix the library in question, but also find all callers in the entire code base and fix them as well.

In general, when I develop, I virtually have all of Google's code base 'checked out' and can edit any of millions of files in my snapshot of the world. I don't need to check out multiple silo'ed repositories or beg for access, diving into any code in the universe has almost zero transactional overhead, it's all mapped into one giant filesystem. (https://plus.google.com/+MattUebel/posts/4dQBDF5CmdX)

On the other hand, production systems are heavily walled off from the corporate network. For all intents and purposes, the corp network your desktop is plugged into is "untrusted"

Nice try though.

I'd like to see you enter a Google data center and try to steal data.

> is it also possible for Uber to sue the supplier for leaking their confidential data back to Google?

My first reaction to the waymo announcement is also on this. "apparently inadvertently" sounds like a blatant lie.

Chances are Google shares patent royalties with companies that help them build the technology they use, so the supplier was likely ensuring their continued royalties by informing on the infringement.