Readit NewsIt seems to take the durable workflow idea and lock you into a specific language, operating system, and database, when other projects in the same space give you choice over those components.
I assume "candidates" was supposed to be "caveats" - and as an author of a "standard" macaroon implementation, I completely agree that this is the biggest downfall of Macaroons. With no common caveat language (and no independent "dischargers") it really limits their use to within a single org. And at that point you're basically asking everyone to invent their own token format anyway.
Though I don't personally use them much anymore - I think the use-cases for Macaroons are much more limited if you have a Zanzibar! - I appreciate seeing Macaroon discussions pop up and this post and the related discussions it linked out to were a great read.
Macaroon: https://en.wikipedia.org/wiki/Macaroon Macaron: https://en.wikipedia.org/wiki/Macaron
The paper calls them Macaroons as a play on (browser) Cookies with layers (of caveats) - so clearly they meant macarons as well, since a macaroon doesn't have layers. Or at least, that's always been my interpretation of the name. It's possible it was just an arbitrary play on hMAC cookies and not the layers?
For internal applications, it's in an awkward place of being both too complex and too simple, and in a lot of cases what you really want to do is just write your own operator for the complex cases and use kustomize for the simple cases.
Most of the problems with updating and installing helm charts go away if you manage it with something like argocd to automatically keep everything up to date.
Internal applications don't have this problem, so you can easily keep your chart interface simple and scoped to the different ways you need to deploy your own stack.
With Kustomize, you just publish the base manifests and users can override whatever they want. Not that Kustomize doesn't have its own set of problems.
Literally nobody involved in the entire chain of providers had any idea how much it would cost. The best advice anybody could give me was to get the treatment, then look at the bill afterwards. (Oh, and nobody had any idea when I might get a bill either-- my wife is still receiving bills from the birth of our most recent child, 18 months ago.)
I've been dealing with this as well, and the uncertainty has been the most frustrating thing.
Medical bills from the same institution should be required to be high watermarks - i.e. if you give me a bill in March, you can't send me a bill in April that has charges from February that _weren't on the bill from March_. It feels like fraud (and maybe it is, but who has time to figure that out?)
There is a line of lutron switches that are dead simple, no smarts, no hub … and a cute little remote that everyone in my family uses to “all off” the interior lights.
We have a no smart devices policy in the house and these make the cut …
EDIT: From my notes ... the specific product line is "maestro wireless" and I have MRF2-6CL switches paired with "pico" remotes. This is as opposed to the caseta line from Lutron which is quite a bit "smarter".
One thing that stands out with Lutron products is their use of a unique spectrum[0], unlike almost all other smarthome products that share the same noisy bands.
[0]: https://assets.lutron.com/a/documents/clear_connect_technolo...
Wirecutter articles are essentially long, well-researched ads for the products they (affiliate) link to.
I always found these ads useful, at least as a starting point. But putting a paywall in front of the ads rubs me the wrong way, like an unwritten contract was broken.
If you are looking at OPA or Cedar as a standalone engine, this is the correct assumption. To avoid this hassle, there is an open-source tool called OPAL[1] that will let you run the policy engines with all the sync work without any investment in custom solutions. OPAL has a ready mechanism for data fetching and synchronization, so you can plug it into your application's data and not worry about the data.
Disclaimer: I'm one of the OPA maintainers.
- Authz data is kept in memory, so what you can authorize over is limited by the memory of the box you run OPAL/OPA. The docs also mention sharding, but I'm not clear on how you actually do that with OPA. [0] Maybe there's another doc that I missed.
- You can get a token representing the last time data was synced to the cache in an OPAL health check, but I'm not clear on how you'd use it to ensure consistency in your application since hydrating the cache is asynchronous. [1]
Anyway, those are the types of things Zanzibar is concerned with, so that comparison (instead of Cedar) would've made more sense to me. Without spending more time on it, I'm not sure if I've represented OPAL correctly above, that's just what I found when I went looking.
[0]: https://docs.opal.ac/faq/#handling-a-lot-of-data-in-opa
[1]: https://docs.opal.ac/faq/#how-does-opal-guarantee-that-the-p...
One big "con" to using it is that it's an internal Google system! If you're going to compare it to open-source policy engines, the sane thing to do would be to pick one of the open-source Zanzibar-inspired systems, and compare that.
But policy engines are only really fast and simple if they already have all of the data they need at evaluation time.
If you look at the examples in the Cedar playground[0], they require you to provide a list of "entities" to Cedar at eval-time. These entities are some (potentially large) chunk of your application's data. And while the policy evaluation over that data may be fast, the round trip to your database is probably not. And then you start to think about caching, data consistency, and so on, and suddenly you're thinking about a lot of the problems that Zanzibar was designed to address (but you're on your own to build it out).
IMO policy engines are best suited for ambient request data: things you already know about a request because of a session, a route, or a network path, and policies that make sense to manage on the same lifecycle as your application.
Disclaimer: I work on SpiceDB[1], a Zanzibar implementation, but I do also like policy engines.
https://www.youtube.com/watch?v=nxKkuDduYLk
He is opposed to this but expects it to pass. His best argument is that it would effectively outlaw affordable low end "contractor" portable job-site style table saws. I have one of those, a cheap $150 Ryobi. It would be more like $450 with the SawStop feature and I would not have been able to afford it.
I'd be using a circular saw instead. Maybe that is a bit safer, and at least it's more affordable until they require the same tech in circular saws. But shouldn't I be the one to weigh the value of a risk to only myself against the value of my fingers?
Not sure I agree with his conclusion though - once all manufacturers are required to include the technology, surely they will still compete on price and find ways to get cheaper models to market? They will be unencumbered by the risk of patent violation to innovate on cheaper approaches to the same problem.
He also argues for riving knives and blade guards as an alternative, which are great, but not all cuts can be made with them in place.
As a hobby woodworker that sometimes makes mistakes, I've wanted a SawStop for a long time but have been stymied by the cost, so maybe I'm just being optimistic.