2 ms·

> Since this is Google, I think this just means that they don’t trust employees Since this is google, the repo is hundreds of terabytes. Not only that, having

> Since this is Google, I think this just means that they don’t trust employees Since this is google, the repo is hundreds of terabytes. Not only that, having lots of copies hanging around on laptops is a big risk, even with encryption. Considering that google's likely threat model involves state actors, not having code on laptops is a reasonable mitigation. But I suspect the biggest issue is that most of the tooling is design to run on whatever version of linux Google runs, not OSX/Windows/ubuntu.

prepend 4y ago
As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with. State actors have security clearances for employees with equipment that allows them to contain state secrets on devices. This is a solved problem and Google not allowing any on device source code is not a security issue, it’s a control issue.
- KaiserPro 4y ago
  > As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with. Unless you are very special/lucky then your code will need all sorts of the repo to work. One of the joys of working at a big tech company with a single repo is just how much shit is pulled in by your dependencies. my code shouldn't need a custom C++ library that does BLAS 0.15% more efficiently than the opensource lib, its just moving data from one bucket to another. However, it does because of a massive chain of dependencies. > State actors have security clearances for employees with equipment that allows them to contain state secrets on devices What level of secret? and how many secrets? all of them? No. Security services don't generally allow people to store secrets on mobile devices, because they get lost a lot. They certainly don't allow all secrets ever stored in the DB to be carted around on >70k employee's laptops (of which at least 1 a day is stolen, most often in sleep so the disk encryption key still accessible) Thats not to say that low-side devices don't ever contain secrets. They clearly do, but they are supposedly risk managed to limit the blast radius. ie, they need to have a good reason to have that secret, a time till destruction, and clear paper trail to see where and when that secret went. Thats not really scalable to a repo with > 5 million files.

prepend 4y ago

As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with. State actors have security clearances for employees with equipment that allows them to contain state secrets on devices. This is a solved problem and Google not allowing any on device source code is not a security issue, it’s a control issue.

KaiserPro 4y ago
> As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with. Unless you are very special/lucky then your code will need all sorts of the repo to work. One of the joys of working at a big tech company with a single repo is just how much shit is pulled in by your dependencies. my code shouldn't need a custom C++ library that does BLAS 0.15% more efficiently than the opensource lib, its just moving data from one bucket to another. However, it does because of a massive chain of dependencies. > State actors have security clearances for employees with equipment that allows them to contain state secrets on devices What level of secret? and how many secrets? all of them? No. Security services don't generally allow people to store secrets on mobile devices, because they get lost a lot. They certainly don't allow all secrets ever stored in the DB to be carted around on >70k employee's laptops (of which at least 1 a day is stolen, most often in sleep so the disk encryption key still accessible) Thats not to say that low-side devices don't ever contain secrets. They clearly do, but they are supposedly risk managed to limit the blast radius. ie, they need to have a good reason to have that secret, a time till destruction, and clear paper trail to see where and when that secret went. Thats not really scalable to a repo with > 5 million files.