jakemoshenko

Sort of, except instead of free time it was full time. After reading the Zanzibar paper, we had a strong conviction that this solution could address many of the authorization challenges we've had in our past products and roles.

Jake, Authzed co-founder here.

Zanzibar is a global highly available distributed permissions system used within Google to power application permissions for things like Maps, YouTube, Calendar, Doc/Drive, etc. They wrote about it in a paper[0] that was widely discussed on HN at the time[1].

The service stores relationships between people, other people, and data, in a giant directed graph. There are primitives for querying and processing that graph to make permissions decisions. The majority of the rest of the engineering effort is spent on replicating the data globally and caching permissions decisions regionally and locally, since permissions don't lend themselves very well to sharding or siloing along service boundaries.

For the 5+ explanation, I wrote a little bit about my digestion of the paper and what the important parts are here[2].

[0] https://research.google/pubs/pub48190/

[1] https://news.ycombinator.com/item?id=20132520

[2] https://authzed.com/blog/what-is-zanzibar/

Hi HN! Jake, Joey, and Jimmy here, founders of Authzed (W21). Today we’re open sourcing our production-ready Zanzibar paper[0] implementation for the world to use. Zanzibar is a centralized relationship based authorization system that Google uses to manage permissions for most of their core cloud products (Docs, YouTube, Calendar, Maps, etc). It is an incredibly flexible, robust, and performant service, with 99.999% uptime and 20ms 99th %ile latency for permissions checks.

We’re the core team behind Red Hat’s (nee-CoreOS, nee-Quay) Quay[1] image registry, and while building out that product as well as a number of others at CoreOS and Red Hat, we continually ran into challenges with authorization systems that were either inflexible, slow, or wouldn’t scale. We have actually had to cancel features in the past due the limitations in the permissions system.

That’s why we set out to build Authzed.com[2], a hosted, managed permissions platform to put an end to this madness! SpiceDB, the fundamental permissions database and access computation platform, is the central component of that platform. Today, we’re making it available under the permissive Apache 2 license for you to integrate with your own projects! We’re already using SpiceDB to power Authzed.com, but are still looking for feedback about our APIs and service.

As of today, the software already has: Expressive APIs[3] for checking permissions, listing access[4], and powering devtools An architecture faithful to Google's Zanzibar paper[5], including resistance to the New Enemy Problem[6] An intuitive and expressive schema language[7] complete with a playground[8] dev environment A powerful graph engine that supports distributed, parallel evaluation Pluggable storage that supports in-memory, PostgreSQL, and CockroachDB Deep observability with Prometheus metrics, structured logging, and distributed tracing

We will be hanging out in the comments section today, so please leave your feedback, criticisms, or just say hi!

[0]: https://research.google/pubs/pub48190/

[1]: https://www.projectquay.io/

[2]: https://authzed.com/

[3]: https://buf.build/authzed/api

[4]: https://docs.authzed.com/concepts/authz#what-is-acl-filterin...

[5]: https://authzed.com/blog/what-is-zanzibar/

[6]: https://authzed.com/blog/new-enemies/

[7]: https://docs.authzed.com/guides/schema

[8]: https://play.authzed.com/

Where do you expect rental housing stock to come from in this scenario?

Slight correction: vaccines are still not available to children under 12.

> The fact that cars depreciate seems like the best reason to "rent" them. The manufacturer ends up dealing with the now less valuable asset.

Except that they charge you for all of the depreciation plus a rental fee. The dealer/manufacturer ends up with an asset that is more valuable than the price they paid for it less the money they've received for it through the terms of the lease.

Good point, then you are the bad actor!

I imagine that NASA trains its astronauts in orbital mechanics.

This seems impossible to me without a bad actor being involved. How did you get stuck there in the first place? In one scenario you departed from a wall or hand hold somewhere and air resistance slowed you to a stop in the middle. In that case, you should be able to swim through the air given enough time.

In the other scenario there is no air in the space station, and as far as I can imagine, the only way to have gotten there with zero velocity would be for someone or something to place you there. Then presumably you could ask that same someone or something for help getting back.

There are some nightmare scenarios involving malevolent robots or rooms so large and velocities so slow that you would die before you made it to the other side that are pretty terrifying to consider.

We don't have a white paper. I wrote about my particular interpretation of the Zanzibar paper[1].

As far as the differences due to cockroach vs spanner. There are only a few minor ones. Without TrueTime cockroachdb relies on their hybrid logical clocks[2] which at the very least require more storage. The Zanzibar paper talks about separating tuples into separate databases by namespace, and shards [3§3.1.1]. We haven't had to do that yet, but we are far from operating at Google's scale. Finally, cockroachdb's CHANGEFEED API[4] combined with our single tuple table have allowed us to skip storing a separate changelog table (for now).

[1]: https://authzed.com/blog/what-is-zanzibar/

[2]: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

[3]: https://research.google/pubs/pub48190/

[4]: https://www.cockroachlabs.com/docs/v20.2/changefeed-for.html

At Authzed, our implementation builds on top of CockroachDB (inspired by spanner) to get those same latency and consistency guarantees. As you are someone else who has read the paper, we would love to get your feedback on how well we've captured the spirit.

We're working on just that at Authzed! After being bitten by inflexible authZ in the past, we decided to build a company to solve it. Take a look, we would love any feedback: critical or otherwise.

I always have this conundrum when cooking a steak on a hot pan: Is the thermometer still settling down or is the internal temperature actually just rising quickly?

Thankfully gravity is also lower.

It's a really well designed distributed system for calculating access control decisions at scale. It makes a specific authorization CAP tradeoff that allows for consistency around access checks to different "versions" of a piece of content, allowing older content to be protected by checks served from read replicas and cache.

Full disclosure: I am a co-founder of a company building and hosting a Zanzibar implementation as a service: https://authzed.com

Surely then there is a watercraft that leans neither? What do we call that!?

In the ShareWith app we have support for different roles that can mutate access, e.g. resource/group manager or viewer, where managers can grant additional access.

Because we layer in access at the authentication provider layer, we don't really have any impact on the downstream application. It's possible we could do some smart things with oauth scopes in the future!

When you say policy relations, do you mean specifically the policies that we've written to drive ShareWith? Or do you mean the ability for developers to write their own policies for their own apps?

For the former, I can see that it might be important and informative to show how the various roles and their relationships relate to access, and we should write a blog post soon explaining how we interact with the platform to create ShareWith!

For the latter, we plan to open up the platform to developers as quickly as we can, so stay tuned!

Similar! We're focusing much more on the seamless sharing side of the experience vs upfront policy configuration. ZTNA supports more protocols out of the box; we have plans to expand the the variety of services we can protect based on user priority.

Seems really annoying to have to define that standard and keep the schemas up to date vs. just having the same thing behind an API in the cloud.

I would honestly just prefer to throw the click away if the thing it's going to send it to wasn't there when my brain decided to click.

You didn't address, and I don't know: what is the relative environmental impact of growing human-grade soy vs. livestock-grade soy? Is there even necessarily a distinction?

I read an article recently that made it seem as if VPN wasn't the panacea for GFW that westerner's think it is. Apparently the GFW throttles encrypted connections heavily outside of normal business hours.

Throwing a failed currency out of a currency basket is like the proverbial tree falling in the proverbial forest. It would not change the value of the Libra at all. The value would already be gone as the value of each stablecoin is computed roughly by taking the entire value of the currency reserves, and dividing it by the number of coins. A good analogy is what happens to the value of a mutual fund when an underlying security becomes valueless.

What an absurd way to say it too. So bad, in fact, it may be intentionally dishonest.

Until you're forced to start publishing quarterlies, or until the employees all unwittingly sell to the same would-be hostile takeover buyer.

I think that's literally the point they were trying to make. You're not the target market so you didn't buy them.

Genuinely curious: for what? Under what context can the bank push for you to have more money? Debt-to-income? More down payment? Assets after closing? Why should they care?

I feel like the author is making a huge omission by not talking about the properties of multi-raft sharded DBs coupled with the TrueTime-like APIs from cloud providers in 2018. He links to a post from the CEO of CockroachDB written in early 2016, and Amazon launched their TimeSync service in 2017.

It's likely that Spencer would have something different to say about the matter today.