2 ms·
Michael from Firebase here. By using declarative rules instead of arbitrary code to enforce Security, we can do lots of optimization and guarantee predictable
by mikelehen 14y ago
Michael from Firebase here. By using declarative rules instead of arbitrary code to enforce Security, we can do lots of optimization and guarantee predictable execution time (arbitrary code can take an arbitrarily long time to execute). It also lets us do various static analysis on your rules to catch common mistakes.
Having rule expressions attached directly to data locations also ends up being much more concise (which means less boilerplate code and less opportunities for mistakes), which we think is important for a security API.
- batgaijin 14y agoWhat are you using for static analysis? What are your thoughts on Fay?
- mikelehen 14y agoFay looks neat! I'll have to play with it. Since the whole rules language is custom, we're not using any off-the-shelf projects presently, and to be honest, we've only scratched the surface of what's possible. Most of what we have in place right now is at the level of type-checking and other expression-correctness checks (we're intentionally more strict about a number of things than JavaScript). But given the nature of the rules we can do a lot of cooler analysis, like detect redundant or conflicting rules. We should also be able to do interesting analysis for the developer like answer questions like "What parts of my Firebase data can an unauthenticated client read or write?", "What parts can a user authenticated as 'joe' read or write?" This sort of analysis should help developers reason about their rules and verify their correctness. Honestly, I'm pretty excited about the possibilities. :-)