Okay, I think I was unclear in my proposal. None of what you've said is related in any meaningful way to my idea, but I think that was my fault for just pointing out the "important" parts and assuming the rest would fall into place naturally for everyone else.

---

This is the system I'm suggesting Firebase implement:

* User registers client-side with a username and password; username and password are salted/hashed to an auth key, which is then sent to the server and put into a server-side key-value store with the username.

* User logs in to the client; auth key is reconstructed and stored to a cookie to be sent with each Firebase access.

* Whenever a field in Firebase is created, an associated "owner" property is set to the username of the user who created the field, and an associated "group" property is set based on an optional API parameter with a default value of null.

* Each field has pseudo-chmod-style permissions settings of the form read/modify/create for owner/group/world; everything is "777" by default, but a simple administrative Web UI allows the developer to define database schemata and assign permissions settings.

* Groups are implemented as server-side lists of usernames.

* When a client attempts to perform an operation through Firebase's API, first the "world" permissions are checked; if the operation is allowed, it completes normally.

If the operation in question is a "create" operation, only the "world" permissions can be reasonably utilised, so if the operation is not allowed and the operation is a "create" operation, then no change is made to the data and an error code is returned (or printed to logs or something).

If the operation is not allowed and not a "create" operation, then the owner's auth key is retrieved from the earlier key-value store and compared with the auth key from the client; if the keys match, the "owner" permissions are checked to determine whether the operation is allowed; if the operation is allowed, it completes normally.

If the keys don't match or the operation isn't allowed, a search is performed to determine whether the username associated with the client auth key is in the appropriate group; if so, the "group" permissions are checked to determine whether the operation is allowed; if the operation is allowed, it completes normally.

If the group is null, the user isn't in the group, or the operation isn't allowed, no change is made to the data and an error code is returned.

---

A hash (like a plain password) is just a meaningless string unless you have something to compare it to

This should be clear now.

Can my client side code change the access for other users?

No. As mentioned above, permissions are set by the developer.

Not access to someone else's account, just access to the other client via the network, browser bugs, bad proxies etc.

I haven't seen any XSS vulnerabilities inherent to the Firebase JS library. Everything else can be reasonably addressed with SSL and a secure browser.

This is a thread about Fireball, which is a new BaaS, one that promises no server-side logic.

Don't be a condescending prick, especially when you're the one who's wrong. We were specifically on the topic of adding price validation to a freemium Firebase application; you still have yet to explain what's stopping me from leaving the bulk of my code as-is and using AJAX off my server only for the price validation.