dward

Spanner and Dremel/BigQuery are both SQL database in that you interact with them by sending them SQL. Maybe I don't understand the terminology.

Just run apt install billion-$$$-arr regulated-institution and write a systemd unit file, then run apt upgrade occasionally. What’s the problem?

GKE can't offer financial backed SLOs without charging for the service. This is something that, I assume, significant customers want and that competitors already have:

https://aws.amazon.com/eks/sla/

https://cloud.google.com/armor/

GCP Network has built in DoS mitigation as well (e.g. in the load balancing layer) so you get some protection from that for free.

HMACs do not require collision resistance from the underlying hash to provide secure message authentication. HMAC-MD5 is still considered "secure", although that doesn't mean you should use it.

http://cseweb.ucsd.edu/~mihir/papers/hmac-new.pdf

Identity aware proxy supports SSH tunneling which means you don't need to manage a bastion.

https://cloud.google.com/iap/docs/using-tcp-forwarding#tunne...

For connecting VMs without public IPs to the outside world, Cloud NAT is the easiest answer. You could set one up yourself if you were so inclined (e.g. some forwarding rules and iptables rules on the bastion).

For ssh key distribution, there's a few options. You can store the key in Secret Manager and run your GCE VMs as a service account that has access to the key, then fetch it when pulling.

https://cloud.google.com/secret-manager/docs/

Something like:

$ ssh-add <(gcloud beta secrets versions access latest --secret=github-ssh-key)

On startup. I haven't actually tried out secret manager yet.

If you have too much time on your hands, you could rig something up with GCE vTPMs as well :)

https://cloud.google.com/blog/products/gcp/virtual-trusted-p...

See also std::embed.

An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubernetes targeted this customer, Borg has a significant head start. At this point the Borg ecosystem is almost old enough to by cigarettes in Mountain View.

A zero-day is an interesting label to put on a bug disclosed "after the company failed to fix the issue within 90 days". I guess, you learn something new every zero-day.

The policy seems sane.

* They know when they can serve 0RTT from their cache safely because they can be reasonably certain if handling a cached request is side effect free.

* If connections to backend origins are reasonably persistent, there's not much latency reduction benefit from 0RTT compared to connections from consumer user agents.

Oomd reminds me of userspace OOM handling mechanism proposed by David Reintjes of Google:

https://lwn.net/Articles/590960/

Use go for what? DNS resolution? The default behavior is to use the system DNS resolver. The Go resolver will be used if the system is resolver is not avaialble (e.g. if the binary is compiled as pure go) or if the net.Resolver has the PreferGo flag set (which is false by default).

https://github.com/golang/go/blob/541f9c0345d4ec52d9f4be5913...

By default, go compiles binaries linked to libc to use the system DNS resolver. It does re-implement a DNS resolver but it's only used if CGO is disabled at compilation time.

Jerk is the derivative of acceleration. I haven't heard jank used in that context.

Albeit this was years ago but I was referring to the construction linked from the original paper proposed in:

https://cs.nyu.edu/media/publications/TR2013-962.pdf

It’s pretty unweildy compared to HMAC construction because:

* each caveat addition requires local generation of a new asymmetric key pair

* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.

* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.

It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.

The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).

Token binding changed a few things as it evolved from origin bound certificates, notably:

* moving from using client certs to signing exported keying material[0] to prove key possession

* adding support for RSA keys

* adding support for multiple token bindings on a single connection (see referred token binding)

Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.

In neither case do I anticipate widespread use

For the browser case:

* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).

* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.

* Many compromises happen in the browser so token binding only marginally improves the security of cookies.

I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.

[0] https://tools.ietf.org/html/rfc5705

A couple corrections to the section on token binding:

1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn't advise forgoing server authentication). That's the beauty of key binding the token. It's useless without the key.

2. It's unclear what the tokbind noun refers to in this paragraph. I'm going to assume that you are just referring to the token binding. A token binding lasts for the duration of a TLS connection (sans renegotiation and resumption which complicate things) and is derived from the [clientrandom,serverrandom,mastersecret] of the connection. The token binding secret is just an RSA or ECDSA keypair, independent of client or server certificates, that is generated when the token is issued. The token is bound to the keypair (e.g. by a hash of the public key that's stored in a JWT claim or stored in a database table keyed by an opaque oauth token).

3. Anyone can use token binding, not just members of the IETF TLS working group :)

You can map ingress/egress channels of a network device directly into a processes memory inuserspace. These are just memory pages in what's known as the DMA region that the device can write to without interacting with the CPU.

Package ptrace provides a ptrace-based implementation of the platform interface. This is useful for development and testing purposes primarily, and runs on stock kernels without special permissions.

From:

https://godoc.org/github.com/google/gvisor/pkg/sentry/platfo...

It's been used in production to sandbox specific workloads for years.

I don't think ingress filtering on Google's edge would have helped if the rerouting happened in any of the transit ASs between AWS and Google.

Allo supported e2e encryption in incognito mode.

https://signal.org/blog/allo/

I’d say that’s the how. Why do you look at it when you do not wish too? Habit? I’d suggest trying to be mindful of your body/subconscious/emotional feedback next time you have the urge to look. Try to figure out what feelings cue the urge. This is a meditation technic called a body scan which I find useful in figuring out why I have and how I can break a habit.

Why does it distract you?

These services offer hardware bound keys, are maintained by O(hundreds) person security orgs (read managed auth[n/z], audit, intrusion/tamper detection, backup, etc...), stored in data centers with strict physical security. For the majority of private sector, the benefits of these services outweigh the cost of trusting the key holders.

I was speaking of the "odd workaround", not about using cpu isolation.

This wouldn't even work with the completely fair scheduler, which is the Linux default scheduler.

https://en.m.wikipedia.org/wiki/Completely_Fair_Scheduler

Google has been experimenting with and deploying blockchain technology since before 2013. Certificate Transparency[0], designed at Google, stores certificates in a distributed merkle tree. Any certificate that Chrome accepts as valid is stored in the certificate transparency merkle tree.

[0]https://tools.ietf.org/html/rfc6962

The people that work on upstream k8s in Google (Tim et al) have a pretty limited overlap with the Google Cloud people that run GKE. Upstream k8s is a full time job so they are most certainly not spending their time also writing internal GKE code.

This statement is absolutely false. There is no upstream team separate from Google Cloud team. There is only the GKE team.