Hacker News new | ask | show | jobs
by sleevi 2023 days ago
Happy to be up front here: as we call out in https://g.co/chrome/root-policy , the goal is to support the things the user installed and authorized.

The priority of constituencies for the Web is a little different than on Android. Android gives a lot of deference to app developers, even against user wishes (think things like screenshot detection or making it hard to intercept traffic without rooting). This gives it a more “secure” reputation for some purposes, but certainly isn’t always what users want. The web has a different set of priorities, as spelled out in https://www.w3.org/TR/html-design-principles/#priority-of-co...

I’m not going to argue which is better, but I will acknowledge there are tradeoffs in both. Chrome, the browser, tries to be the user’s agent to the Web.

Sometimes, however, being the users agent isn’t always cut and dry obvious. Extensions are a great way to empower users to mix the Web as they want, but they can also be a really harmful abuse vector. Finding the balance is tricky, and I know folks aren’t always happy with how that balance is struck, but a lot of thought and community engagement definitely goes in to it.

Now, how does this relate to what you were speculating about? Well, installing roots is similarly one of those things that’s dual-use. I love tools like Fiddler and CharlesProxy, and have fought hard to make sure they work well (see the token binding discussions, which would have totally broke these tools). These tools use locally installed certs to really empower developers and users, and I don’t want to break that! But there’s also stuff like https://security.googleblog.com/2019/08/protecting-chrome-us... , which can completely destroy users’ privacy and security, using locally installed roots. So, like with extensions, there’s a balance to be had, between enabling great use cases, while also protecting users from abusive things.

Obviously, as you note, problems like this could be “solved” by not allowing locally installed roots at all. When Kazakhstan required a root to be installed to compromise traffic, for example, Android and iOS users were largely protected precisely because “install this root” doesn’t really work as KZ intended. That’s great! But it’s also got downsides, like breaking Fiddler and Charles.

I can absolutely say that the reason for this new root program is exactly what is said on the policy, and similar to Mozilla’s explanation at https://blog.mozilla.org/security/2019/02/14/why-does-mozill... . This isn’t about trying to block all locally installed certs, like Android, but about providing good, safe, cross-platform and interoperable defaults.

But I also will acknowledge that there totally are concerns about abusive roots, whether from Unwanted Software, device compromise, or the like, and this will give better tools to help communicate, explain, and warn users as appropriate, so they have a chance to make an informed decision. For example, this can close off quite a few abuse vectors for malware, today, and that’s already a win. However, any big changes to how locally installed roots work are quite a while away, and, like so many of the changes that involve complex tradeoffs, will involve a lot of research to understand users’ needs and desires and use cases. So no, this isn’t some secret plot to prevent users from managing their device as they see fit, or from choosing the CAs they trust.

1 comments

> Android gives a lot of deference to app developers, even against user wishes

The idea that software should act against user wishes isn't inspiring to me if I am the user in question, not to mention the one who purchased the hardware and software.

> When Kazakhstan required a root to be installed to compromise traffic, for example, Android and iOS users were largely protected

On the other hand, this is aligned with what I want.