4 ms·
I will make a controversial comment: My experience is that security is a function of simplicity and individuals having a complete understanding of the code and
by frognumber 2y ago
I will make a controversial comment:
My experience is that security is a function of simplicity and individuals having a complete understanding of the code and implications of changes.
Implications:
- A smaller team will generally lead to more secure software than a larger team.
- Many security layers are counterproductive.
In studies, bugs per KLOC are relatively consistent. A 100-line program can be fully auditable. One with a JIT in a virtual machine in a sandbox looks, on paper, more secure. In practice:
- There are many more places to introduce bugs.
- Beyond some level of complexity, it's impossible to understand the security model holistically.
- Bugs often cut across layers
- Layers are often used as an excuse ("We'll leave this, since that other layer will catch it).
Layers can be okay if they're well-understood, analyzed, and well-documented (e.g. postfix). However, the vast majority of the time, they're not. People pointing to bigger workforce or sandboxes in Chrome aren't selling me. It only takes one idiot.... And for sandboxes? I've never seen a clean block diagram of the Chrome security model.
To be clear: I'm not arguing which browser is more secure -- simply that the arguments in this thread don't sell me.
- pmontra 2y ago> My experience is that security is a function of simplicity I don't think this is controversial at all. For example: I keep using uMatrix to block (by default) or allow scripts, frames and XHR because it's orders of magnitudes simpler to use than the way the same developer added that functionality to uBlock Origin. I still use uBO to block ads and hide unwanted elements from the DOM. It's the difference between writing [pick your favorite high level language] and machine code. If all I had was uBO I would let those scripts run.
- maverick74 2y agonot sure why you say it's a "controversial comment"... What you say is well documented and you made a reasonable comment! The bigger the software, the more likely it is to be exploited...
- frognumber 2y agoThis is actually completely contrary to documented best practices. Best practices involve a lot of layers and processes. Defense-in-depth is best practice. My experience is that only helps if each layer is carefully designed and analyzed at a level impractical for most real-world systems. In most cases, unless you're designing Unix from the ground up, the better approach is KISS.
- gardenhedge 2y ago> Many security layers are counterproductive Where is this part documented? I've read that security is best done as a layered approach
- chha 2y agoI was about to ask for the same thing. All best practices within the security domain point towards multiple layers of security, simply to have some fallback if one mechanism is compromised.
- maverick74 2y ago> Where is this part documented? i don't have any example over this part. Maybe the OP has... Still, a layered approach is great "on paper" (and probably the best actual solution we have atm), but it is only great in practice if it's well coded and the op is right that in lots of cases there are numerous flaws. yes, you have failsafes on the layer bellow, but then again... it's just another "challenge" to find the flaw... If we have a simple and effective code (à lá unix: do one thing, do it well), that has the possibility of becoming more effective that "flawed layers". yeah... we can have multiple - simple - layers... but again... that will also raise the possibility of unforeseen flaws... all in all: it's always a double-edged sword... you're right and the op is right XP (unless the layered approach is actually really really well coded!!! That's the ideal... but not many can do it!!! - i surely can't ahahah)