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.
Conversation
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
(or at least somewhere strictly monotonous with code amount), and I don't see that being the case with mitigations, because you literally reduced the amount of attacks by a number >= 1, and didn't introduce any *known* vulnerabilities, so you net gained measurable security. 2/2
1
There were no enhancements made to the privacy or security of Chromium. It has more attack surface and maintenance burden than before. That's not an improvement to security. I don't see how you can portray it otherwise. You could trivially detect Incognito, and you still can now.
1
But *quite a few* can't now, after the mitigation was rolled out.
You're trying to compare potential losses in maintainability and things still being possible to do with the fact that yes, privacy was enhanced because a certain abuse, for a certain amount of time, was stopped.
1
Chromium already has a system for enumerating badness (Safe Browsing) and any additional code added to break specific malicious sites is redundant. If you believe in enumerating badness, that code is already implemented, and there's no need for anything like this to be added.
I don't specifically believe in enumerating badness (and afaiu, you don't either). I'll be honest: you're losing me here; I don't understand the implication that "any additional code to break specific sites is redundant". Redundant to which functionality, that breaks those sites?
2
(NB: I'm _really_ no expert in mitigations. Most things I ask here are purely from an engineering curiosity! I've learned quite a bit through this exchange.)