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.
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. :-)
Yeah. That bugs us too. :-) We might support a non-JSON format for easier authoring at some point, but we thought JSON was the right starting point since people are familiar with it and it has a lot of good tooling and interoperability advantages.
