

Firebase (YC S11) aims to reinvent real-time apps and already has 4,000 sign-ups - mayop100
http://techcrunch.com/2012/04/19/firebase-post-launch/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
zrgiu_
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
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!

