how is this different than meteor's security model?
Not all apps need this stuff right away, of course, and some never do. But it's hard to do these things w/o a secure server environment for privileged code.
And then of course there's the usual tradeoffs between having control over your hosting environment (a la Meteor) and outsourced backends as a service (a la Firebase).
We're big fans of Firebase, BTW. We think more databases will move to a realtime model. Excited to check this out.
We're big fans of Meteor as well. Firebase is just a data layer -- we do high-performance, scalable real-time data sync -- but we aren't a complete Framework for building an app. Generally devs will want to use something like Meteor (or Ember, or Backbone, or Spine, etc) to help them organize their code and manipulate the DOM.
In the future we hope to have a Meteor integration, so you can power your Meteor app without running any of your own servers (and do it on a super-low-latency, highly scalable backend).
The model is reversed in this case though, where instead of clients talking to your application server, clients talk to your database (Firebase), and your application server only ever talk to your database (Firebase). It's a bit of a conceptual shift, but we have many customers doing this in production and it works quite well.
Our rules are expression-based, so they have fast and predictable execution times, meaning we can run these on our own servers and scale your app for you with guaranteed performance.
Our rules also let you specify all of your security logic in one place, rather than sprinkling it around your code, meaning it's easier to review and reason about (and avoid holes).