3 ms·

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 securi

by jamroom 14y 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.

kogir 14y 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.
- maratd 14y ago
  > 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 14y ago
    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 14y ago
      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.

by jamroom 14y ago

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

maratd 14y ago
> 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 14y ago
  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 14y ago
    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.