> For example, IIRC NetBSD required new developers to meet with one or two existing developers in person to verify their identity. (Pretty much like a regular PGP WoT.)
Debian also requires OpenPGP keys and WoT for all developers.
> What I'd really like to see is a JS implementation of the "dynamic" features like diffing
That's possible. I've made something like that (dynamically fetching git info via dump HTTP server protocol) using Git.js [0] although for a different reason and it worked very well. Some caveats: the decompression must be handled in a WebWorker or the UI is stuck pretty easily. But objects can be fetched on demand so it's kind of like Microsoft's Git Virtual FS. As you've said cross origin policies apply so either have the viewer on the same site as repos or add appropriate CORS headers.
They also take into account the state of the machine you're working on. So locked bootloader and probably a client cert in TPM-like component, plus "device health". Client certs alone are good for authentication (don't work in HTTP/2 though) but they want to reach even better target - no malicious software running on your computer.
That's from reading old papers, I don't know if anything changed now.
That's correct. Previous papers touch on the inventory data pipeline and machine health, though without as much detail as I might like in your shoes. Our agents track a wide variety of things on client machines, and we use that inventory data to determine how trustworthy a machine could be.
[I work at Google, and helped make these papers, and blog post, happen]
Interesting design. As far as I understood from old papers client certificates are used only to identify the device while user authentication is handled differently.
Could you elaborate on the technical details on user authentication? (If that's not top-super-secret) I guess it's just like accounts.google.com for Enterprise with mandatory 2FA (username+password+U2F key?). Does it work the same on mobile/Android (U2F via NFC or codes)?
Android supports U2F via NFC and Bluetooth now, which is used for user authentication on Android devices. We've also released an (experimental?) iOS app to support U2F over Bluetooth.
There's tpm and secure boot - does the (presumably signed, in the trusted boot->os->user binary/service-path) agent access signing services from tpm - backed by a key in tpm, and use that to identify itself as an authentic agent?
Otherwise I can't see how an (admin) user couldn't extract the key from ram and run the os and agent in a vm?
Yes. As far as I understand, the problem was that the requirement for a certificate is a per-request thing, but HTTP 2 can have multiple requests in flight over the same TLS connection at the same time and thus can't just renegotiate the connection when it comes up. There have been proposals to fix this, but nothing has gained the necessary interest and traction.
Servers can ask the client to fall back to HTTP 1.1 instead, and then use client-certificates there.
Bring Your Own Device is fine for ChromeOS and Mobile. You might not get the full amount of trust as a Google-issued device (for mobile/tablet).
To achieve the highest levels of access in the BeyondCorp model you need a machine with Google's management agents, so we can evaluate device state accurately and pull information from our inventory management system.
But if you don't provision the device yourself how can you be sure it hasn't been tampered with in a way that just displays "bootloader OK, everything good" but in the mean time it was rooted? Or is that a risk calculated in the "no full amount of trust"?
That protects against newbies, but we’re talking here about Google employees – modifying and cloning the ICs on the board to fake a verified boot status should be a triviality for people who design their own chips and boards for Google’s own servers, right?
That would be covered by policy controls, not technical ones—it's the same issue as someone taking pictures of the screen with their personal phone. You'd need to address the actual issue that's causing people to do that (ill-thought-out policies, employee actually working for $INTELLIGENCE_AGENCY, employee enjoys espionage,…).
A recent example would have been the data that was stolen from Google and given to Uber – the employees who were qualified enough to design their own LIDAR chips and boards would equally be qualified to circumvent any such protections.
On a Google-approved device, you can still use that device, and copy content to another, non-Google-approved device. Nothing is perfect, but at some point you trust your employees.
I suggest returning 404 Not Found instead of 422 Unprocessable Entity on failed GETs: https://jsonbin.io/b/2342342 as well as Content-Type: application/json instead of current text/html.
Looks very good and I like that they have a screenshot right on the home page. I wish there was an anonymous instance to try it out without the tedious login process...
Debian also requires OpenPGP keys and WoT for all developers.