Great question! The key to our security model is our Security Rules system. Security rules are authored by the developer and stored as part of their Firebase. Firebase then executes them automatically to validate all reads and writes of data.

You can check out the rules for Firefeed here: https://github.com/firebase/firefeed/blob/master/rules.json

And be sure to check out our Security Quickstart Screencast, walking you through the system: https://www.firebase.com/docs/security-quickstart.html

For anyone who isn't clear on what exactly this entails, but have some experience with AWS: it's a bit [a lot] like S3 bucket policies.

The Security Quickstart Screencast is superb, thanks!

Few more questions if I may:

1) indexing, didn't see any options, I assume it's planned in the future along with more complex query language?

2) self register as a RequireJS / AMD module, is this planned?

Again, this is great. thanks

1. The API was designed pretty carefully to ensure we wouldn't box ourselves into any corners that would limit our real-time or scalability capabilities. So we've intentionally avoided advanced querying for now. You may see features along these lines in the future, but right now we recommend denormalizing your data during writes to match how you want to consume the data (which is a pretty common nosql practice). Firefeed is a good example of this, actually.

2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)

Regarding #2, to register as a module you just need something like this:

https://github.com/umdjs/umd/blob/master/amdWeb.js

On the denormalization front, is it possible to do transactions without locking / syncing the entire tree. I'm thinking friendship modeling like:

  user1.friends = ['user2']
  user2.friends = ['user1']

Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention.

If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.

I had this exact same question when I saw it. This is handled by Security Rules [1]. You define these rules using JSON - basically read/write access to objects on a per-user basis. Seems like a good solution, depending on how flexible the validation style rules are (seem to be very flexible at a glance).

I'm pretty impressed by the product, looks like it may even be a game changer for doing quick web apps.

[1] https://www.firebase.com/docs/security/security-rules.html