Hacker News Reader

Comment by leggetter | Hacker News Reader

I love the technology, I've had a play with building a mini-app in their interactive tutorial, but I really want to see their security model. How is it possible to stop a user opening up the JavaScript console of the web browser and writing code? There are authentication mechanisms you can use, tokens etc. but that just authenticates that user. They can still start hacking.

Maybe the thought is to let a user hack with their own data?

What's the solution when it comes to shared application data?

Will they ultimately need to let app developers deploy server logic on their infrastructure for the security solution?

Also, amazing job by their PR contacts for getting so much coverage and creating such an amazing buzz.

View on HN

This is the model I suggested to one of the Firebase guys:

* 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.

---

He said that their current security model is influenced by Unix and somewhat similar to mine, but currently it requires a server, and they aren't yet sure how the client-side security will turn out.

You have to think of it as writing a P2P app with no "trusted" server. Each client needs to be suspicious of all content created by other clients, and handle it accordingly. There are many services where a trusted server doesn't really add any value.

Consider for instance Facebook and Twitter. What if each user had full control over their own data:

Search: Each user would register a link to their data in a shared namespace so users could find each other. A single user could add/remove/edit their link, but only enumerate/search others.

Follow: The consumer traverses the link from the registry to the data and consumes it.

Friend: A asks to be B's friend by writing a request into a write-only namespace unique to B. B grants or denies access to protected data.

You get the idea. Nearly everything can be made to work with multiple clients that cooperate but don't trust each other. A trusted server isn't really required.

Nearly anything can be made to work, but in many cases it means jumping through a lot of hoops to get there.

Without a trusted party you have to be much more suspicious of everything coming in, as you say, and that means coding additional verification, everywhere.

For instance, with that model of friend requesting, there has to be some method of proving that A made the request to B. I can think of various ways of doing this (A signs their request, or A adds a duplicate outgoing request to a queue only they can write to, etc), but the point is that they're all much more overheard than doing it the traditional way. And that's just for a friend request.

The big concern is that all this overheard will mount up enough to offset any of the other gains Firebase brings.

>Will they ultimately need to let app developers deploy server logic on their infrastructure for the security solution?

Right now you can write a client in node.js on your own infrastructure if you need server logic.

Otherwise, you could have one of the clients "act" as a server, and have another client take over if the first one leaves. For example, if you are making a game and you have a non-player element (such as a ball in pong or if you would add actual asteroids to MMO Asteroids), you need just a single client to update data for it.

Reply on news.ycombinator.com