▲ 76 points
back
22 comments
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.
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.
I really dislike how the term "real-time" has been distorted into something entirely different. Just call it "live" apps or something.
Firebase is true realtime. No polling. No waiting for disk I/O. We are trying to produce the absolute lowest latency possible.
Traditionally "real-time" in the context of computing means responding to events within a guaranteed time interval, usually milliseconds or microseconds.
Firebase is nothing like a real-time [1] system! That's precisely the kind of stupid dilution my comment was complaining about.
I've been lucky enough to get to play with Firebase from the beginning, and am really impressed with how it's come together. The team knows the security issues are real, and have a viable plan to address them for most use cases.
I can't wait until the security features are implemented and I can use Firebase in my apps!
I too am impressed with Firebase, but am I the only one that thinks details like "security" should be baked in from the beginning? I've never considered security to be a bolt on you do at a later time, as often it requires core level changes that could have unforeseen consequences in other areas of your system.
They're not bolting it on as an afterthought. They looked for feedback from the very beginning on how people wanted to use it and what security features would enable those uses. Then they ensured that in designing the core product adding those features later would still be possible and efficient.
I commend this approach. Security before there's anything to secure is a little silly. Having it in mind when designing your product and making intelligent compromises is essential.
> Security before there's anything to secure is a little silly.
Cute, but falls flat in the face of reality. If you just bought an expensive diamond ring, you already have the safe at your apartment waiting for it.
The same with software. You can't add security later.
You will need to rewrite everything, because with software, every action needs to be secure. So every action would have to be re-written. Every database write and read, every file write and read, etc. etc.
You want to know the real reason Firebase and Meteor didn't have security baked in from the start? Because security is 90% of the work in any real software suite. They started off with the 10% that's a low hanging fruit.
That's totally fine! But that also means neither one has a viable product and they won't have a viable product until they do the other 90% of the work.
I think we'll need to agree to disagree.
Some examples come to mind: Is it impossible to build the internals of a filesystem first, and add ACLs as a layer on top? What about the internals of a database? Should you start with users, schemas and permissions; or b*-trees, join logic, and the query parser?
You can't really add security from buffer overflows or SQL injection to an app after the fact. You can add well-reasoned access controls.
All of the things you mention have flat or very simplistic security systems. In other words, access is predefined. X can do Y.
That's not how high-level software design works. You're at the top of the chain. The security that you engineer will vary based on the very content that's being accessed! Just because you're a user with the right password doesn't mean squat.
Facebook is a fine example. Just because you can view the profile of one of your friends, doesn't mean I should be able to as well. I'm not his friend.
How do you define that in Firebase? if(you_are_friend) allow_access? What the hell is a friend? How does Firebase know what a friend is? Now you're setting up complex rules that access multiple databases/tables/rows just to make a decision.
That mountain of code that manages the core operations of your software can't be wished away by happy thoughts.
The technology provides an impressive first impression. With that said, I would appreciate it if somebody can help me understand how this doesn't lead to "two-dimensional" vendor lock-in (hosting and proprietary framework). From my first glance, this appears to be a combination of hosted service and web framework all rolled into one, where code portability is not possible. Am I missing something?
From where I sit you are correct - which makes it a non-starter.
They'll have to bite and open source their backend (ala OpenStack) or this is going nowhere beyond toy apps.
Otherwise, if their platform is viable, a third-party OSS clone will pop up and eat their lunch.
I'm not sure if it's a non-starter. As a total code newb, I would find it very enticing to have to learn fewer things--like just their front end--rather than server-side too. If they are truly awesome, I'd probably be willing to pay through the nose to have that simplicity. If they can effectively reduce complexity so that all you really need to learn is JavaScript, it's going to make it easier for non-software engineers to build services. Of course most of the market isn't new to programming, but flattening the learning curve of would-be programmers is a pretty important comparative advantage.
If you're just learning how to code then what could you possibly build yourself that you'd be willing to pay through the nose for?
My point here is that the only consumers that will pay are ones who have an actual business (model) in place and those people are rarely going to be total code newbs.
I can see this as an interesting playground but it also seems overkill to me for a playground.
I agree that in order for this to take off the data needs to be made portable which means they need to opensource all or part of it and rely on their expertise for the business model. That, I could get behind.
Firebase is a great, especially if you want to rapidly develop or test new things. It's saved us days/weeks of time not having to worry about structuring/restructuring our backend and allowing us to focus on getting the UX/design of our app down first.
This has been extremely valuable for our small team -- we've been using Firebase since the beginning and are a big fan of the technology. By abstracting this part of our product away for the short term while we build and iterate, it's probably doubled our productivity - just in the short term, of course (and assuming it would take half of my time/focus to be building/maintaining backend code).
Plus, James and Andrew are always super responsive whenever we bug them for stuff.. they know how to keep their users happy.
If there's anyone from Firebase here, I have a few questions that should interest everyone:
1. will you support mobile platforms (especially interested in Android and iOS) ? The TC article says Tamplin says it has also partnered with a yet-to-be-announced company who can package those websites for mobile app stores. , but that sounds weird and vague.
2. do you have a release schedule available? This looks like it would match my needs perfectly! When should we expect to have a stable release?
3. pricing ?
We're using it for our text chat modules at TokBox. Looking forward to releasing that code in our plug'n'play apps very soon!