Firebase (YC S11) aims to reinvent real-time apps and already has 4,000 sign-ups

http://techcrunch.com/2012/04/19/firebase-post-launch/

by mayop100 • 14 years ago

76 22 14 years ago

leggetter• 14 years ago

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.

buu700• 14 years ago

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.

jaredsohn• 14 years ago

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

kogir4• 14 years ago

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.

marbletiles• 14 years ago

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.

kogir4• 14 years ago

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!

jamroom• 14 years ago

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.

kogir4• 14 years ago

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.

ryanhuff• 14 years ago

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?

moe• 14 years ago

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.

meisterbrendan• 14 years ago

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.

lucian19002• 14 years ago

I really dislike how the term "real-time" has been distorted into something entirely different. Just call it "live" apps or something.

mayop100• 14 years ago

Firebase is true realtime. No polling. No waiting for disk I/O. We are trying to produce the absolute lowest latency possible.

defen• 14 years ago

Traditionally "real-time" in the context of computing means responding to events within a guaranteed time interval, usually milliseconds or microseconds.

lucian19002• 14 years ago

Firebase is nothing like a real-time [1] system! That's precisely the kind of stupid dilution my comment was complaining about.

[1] https://en.wikipedia.org/wiki/Real-time_computing

zrgiu_• 14 years ago

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 ?

monvural• 14 years ago

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!

andien10• 14 years ago

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.

Firebase (YC S11) aims to reinvent real-time apps and already has 4,000 sign-ups

Related Stories