Hm, I'm clearly not an expert in computer security, but as far as I can see that model needs to incorporate a lot of stochastic aspects, in which case all but very few mitigations (e.g. air-gapping) are mostly barriers, just with varying likelihood of getting surmounted.
Conversation
If the benefits of a mitigation cannot be quantified, that doesn't sound useful. Privacy and security features need to be designed with a clear threat model and goals from the start. If they simply break existing malicious code the burden being created is really on the defenders.
1
Chromium added substantial complexity to try to remove one of the widely used methods to detect Incognito mode. It doesn't work and the goals are unclear. The only thing that has been accomplished is forcing the adversaries to update their library for detecting Incognito mode.
1
If they commit to making this a property of Incognito mode and actually come up with a plan, that would be a different story. It wouldn't look like this. It doesn't make sense to take action without having a threat model and a plan to address it. It's harmful rather than helpful.
2
I'd argue that "we've got this specific exploit, and it's being used to harm users" is a clear threat model.
Building a workaround for that single threat is a goal-oriented solution to that, no?
1/2
1
Not following on the harmfulness part: sure, it's work, but in reality not every solution generalizes, so at times (and even usually):
particular problems require particular solutions, no matter how much we wish we could solve "the bigger picture". Engineering :( ! 2/2
1
Chromium now has more attack surface and maintenance burden than before. It doesn't have improved privacy or security. It has weaker security due to this change. The defenders have more code to defend and more complexity to wrap their heads around. It had an opportunity cost too.
2
let me get opportunity cost out of the way: exploit is found, mitigation known. Vendor doesn't fix it, says "waiting for the big solution". Good situation?
re: weaker security: could you elaborate on that? That sounds like the usual "attack surface is proportional to code" 1/2
2
Chromium didn't prevent detecting Incognito mode, and it still doesn't do that. They didn't fix anything, and they haven't committed to changing this. There is no increase to privacy or security. There is more attack surface, and users are less informed about Incognito provides.
1
how can you first state that it required abusers to rewrite their attacks (so, it was effective against the attack that was actively deployed), and then state it has no effect? That's a contradiction.
2
That's a complete misrepresentation of what I've been saying. I never said that it has no effect. I said Chromium privacy and security is no better than before, and it now has additional complexity and maintenance burden. You don't seem to disagree, and need a strawman instead.
hey, sorry if I came across like that.
It's just that I feel you're proposing better metrics, and I feel that metrically, that mitigation seems like the thing to do (one problem down, only a potential problem appears).
Could you explain your metric? How's not doing that better?
1
I'm stating the obvious, which is that if a feature does not provide quantifiable privacy or security benefits it isn't actually a real privacy or security improvement. Breaking very specific legacy code is a much different thing than fundamentally improving privacy or security.
1
Show replies