
Google’s Plans for Chrome Extensions Won’t Help Security - gildas
https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security
======
SpicyLemonZest
I'm not convinced that Google can actually solve this problem by just
reviewing apps more closely. It sounds like it took a lot of work for Jadali
to identify a smoking gun, a lot more than Google could reasonably do
preemptively or even as a response to every abuse report. And if Google had
shut down three very popular accessibility apps with anything less than a
smoking gun, I expect that would have been just as controversial as Manifest
V3.

~~~
ghostwords
I suggest that the gulf between perfect foolproof detection and what Google
actually does now is vast. They can start by banning remote code, and follow
up by setting up automated flagging with manual review for popular extensions
to start with. Just getting clarification from developers regarding anything
suspicious would be great.

------
Kalium
Dear EFF,

I love you. I love you lots. Which is why this post rather bothers me for its
dishonest arguments. This bit stood out:

> That’s because a central part of Manifest V3 is the removal of a set of
> powerful capabilities that uMatrix, NoScript, and other extensions rely on
> to protect users (for developers, we’re talking about request modification
> using chrome.webRequest).

Whatever tools are available to a friendly extension are also available to an
unfriendly one. With this in mind, it should be relatively easy to figure out
that this sort of modification might, just might, be subject to some amount of
possible abuse.

Please, EFF. I do love so much of the work you do. Is it too much to ask for
some intellectual honesty?

~~~
ghostwords
Hi, coauthor here. Our argument is not that extensions can't abuse
chrome.webRequest. What exactly is dishonest here?

~~~
Kalium
Request modification using chrome.webRequest is pretty clearly something
potentially abusable. Yet it's _never mentioned_ in the rather long section
about changes that may affect security concerns. It's only mentioned as
something ad blockers find useful.

This is, at the very least, a significant editorial oversight.

~~~
ghostwords
Just because something is abusable doesn't mean it should be removed. The
argument we _are_ making is that the trafeoff proposed by Manifest V3 is bad.
There are clear actions Google could have taken a long time ago to protect
Chrome users. Banning remote code is one of them. Responding to abuse reports
is another. These would directly mitigate abuse in Chrome Web Store. Banning
chrome.webRequest is not one of these clear actions.

~~~
Kalium
I do not disagree on any of your points in any way, shape, or form.

If something is abusable but on balance worth keeping, then it should be
publicly positioned as such and the balancing factors dicussed. Ignoring the
abusability of something and focusing solely on the upsides is one of the
classic moves from Ye Olde Bag Of Dirty PR Tricks.

~~~
danShumway
I don't necessarily disagree with you on principle, but in this specific case
it's important to note that the security benefits of blocking extension
modification via a dedicated API are _very_ minor -- especially since
extensions will still be able to inject JS into the page and read client
information. Is it really important for me as an attacker to be able to modify
your request when I can just edit the page directly, insert custom data, or
steal your login credentials instead?

With respect, I would suggest that the cost-benefit analysis here is more one-
sided than you think it is -- one-sided enough that an exploration of the
security benefits would need to come with a lot of caveats, and would be a net
decrease in the readability of the article.

It's not clear to me that deprecating a dedicated request modification API
improves security in any meaningful, practical way for most users, and I think
there's some benefit to occasionally skipping details that are irrelevant to
the main story, so that ordinary people will find it easier to wade through.

I would compare this to the way that Google bundles wifi access and location
access on Android. People complain about it, but it's a sensible decision --
there's no point in restricting just one of them. Similarly, I don't see any
point to restricting request modification without also restricting access to
request content/headers/cookies and removing the ability to inject arbitrary
JS into the page. I think Google is engaging in security theater here.

