Item — HN Reader

Security for the data in Firebase is one issue - and as I've mentioned above we're taking that very seriously, and we're working on it.

The business implications of having client-side software are a different issue, and I think its been demonstrated many times that businesses can do very well even with most or all of their code running client-side. Any desktop / mobile software works like this, as I mentioned.

Relying on a compiler for security is a bad idea, just as you shouldn't rely on people not messing with your javascript. Clients today can access and change MS Office if they know what they are doing.

2 comments

Yes, but virtually the only business logic in traditional Office is in the licensing, which has been repeatedly cracked.

You're not really comparing like with like here, unless you're saying that Firebase will solely be used for making non-networked "tool" apps.

If you're talking about networked apps, then, no, they havent always been client side. They started as tty/3270-esque apps and grew from there, with the business logic staying on the server and the clients growing in capability and power.

Boil it down: there are rules that say only managers can change vacation days, or that govern where and when discounts are applied, or who can upvote a comment, or what the power up bonus is, or whether even to check for any of these things. If these things live in the client, how are they secured from interference?

If these things live in the client, how are they secured from interference?

It doesn't sound like he's implied that this could be manipulated by the client at all; in fact, he's explicitly implied the opposite. Why would ACL definitions have to live in code (as opposed to, say, a simple Web interface)?

I'd think something as simple as a graphical UI to define database schemata with read/create/modify permissions for owner/world on each field would be enough to cover 82% of use cases effectively. Beyond that (e.g. complex group management), I can't think of a secure client-side solution off the top of my head, but I suppose that would be what the Node.js plugin could be used for.

Edit: Actually, for a lot of use cases group management could be handled by the client as well. For example, if a group is defined by a table, then the creator/owner is de facto the first member and administrator. If any administrative actions require an admin auth key and adding new members or admins is an administrative action, then there really isn't any way to hack the system. (I assume a user's auth key could just be something like a client-side hash of their username and password.)

Security needs less implications and more explicit answers.

Besides, there is more to business logic than simple (or complex) access control. More than one Facebook game has discovered to their cost the problems of trusting the score the client is sending to you. Or take discounts: if I want to give 10% off for orders over £20, where does that rule live?

If it's on the client, well, what stops the client changing that to 90% off?

Perhaps you ACL the order table and only allow access to a non-client facing instance. The client sends an order to that, which verifies it and sends it on if approved?

Well, fine, but that's a server, and one of the main pitches here is "No servers! No server code."

Sure, those are fine examples of use cases that fall outside the general category of applications which don't require server-side data validation.

You're using "security" to mean something totally different now (protection of your data from other users v. prevention of you modifying your own data in unexpected ways). My point before was that most applications just don't have that concern of limiting what users can do to their own data, at least for the MVP, because in most applications that will only affect the user herself.

It all amounts to the same thing: no server means putting your trust in the client. Which you should never do. You don't trust who the client says they are (authentication), you don't trust what the client says they can do (authorisation), you don't trust what they're giving you (validation),

It's not something you bolt on later. You have to bake this in from the start, because even the simplest operations depend on it. Posting a comment? Great: are you allowed to post? Who are you posting as? Is there HTML in your post?

You don't trust who the client says they are

I shouldn't trust a hashed username and password? How are server-based systems more secure?

you don't trust what the client says they can do

That's a non-issue if it's handled by ACLs on the server.

you don't trust what they're giving you

Like I mentioned before, though, for most applications you can trust what they're giving you. Sure, Amazon isn't going to ask the client how much an iPad costs and WoW isn't going to ask the client for the player's stats, but why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request / wall post / whatever? If you attempt to perform an unexpected action (say, post to the wall of someone who's blocked you), the other user's client application logic (which is beyond your control) can still handle the junk data gracefully and simply.

Also, later on (when you have more developer time to spare), if you want to for whatever reason, you can easily just deploy a server-side "garbage collector" of sorts to regularly clean up the database without disrupting client-side flow.

It's not something you bolt on later.

It can be, provided that it's only in the form of new features rather than fixing something which was insecurely implemented to start with. (For example, maybe the MVP is free but the next iteration is freemium and requires server-side price validation.)

I shouldn't trust a hashed username and password? How are server-based systems more secure?

How are you going to verify the password without a server? Passwords are a server-based system.

That's a non-issue if it's handled by ACLs on the server.

ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. Any non-trivial sites are quickly going to get way more complex than just doing it the old-fashioned way. So why bother?

why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request?

Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having.

It can be, provided that it's only in the form of new features

And those new features are going to be written in what? Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off.

That's not one of the good problems to have, it's one of the stupid problems you should have avoided by laying the right foundations at the start.

It's the age of Google Docs, not Microsoft Office.

As soon as more than one user is involved, there must be some logic on the server side.