[liberationtech] Chrome & Chromium forbidding extensions from outside their store
Nick
liberationtech at njw.me.uk
Mon May 5 06:04:12 PDT 2014
Quoth Andrew Cady:
> Appparently what is hard-coded into the source is the default value
> of "com.google.Chrome.ExtensionInstallSources". (Also hard-coded, I
> presume, is the SSL certificate for the domain.)
>
> You can override the defaults, though, so maybe I've overstated it.
> Here is how:
>
> http://superuser.com/questions/450893/how-to-install-a-private-user-script-in-chrome-21
Gosh, I had no idea Chrome / Chromium had changed to force you to
install from Google Store. That makes old little extension unusable;
I distributed it on my website because:
- I didn't have a Google account
- I don't like their TOS
- I like decentralisation
- I liked building and signing the extension myself, and it enabled
me to use almost all the same code for Firefox and Chromium, with
a little help from a Makefile (though I didn't realise it was
impossible to do that through the Google infrastructure)
> > I would like more diversity than 99.9% of extensions distributed
> > through Google's infrastructure, but (like the 'app stores') it does
> > provide a useful service; basic malware checking, that keeps most
> > people safe from bad actors most of the time. At the expense of a
> > single point of failure that can be compelled to fail by state action.
>
> I don't think of it as a useful service. If they were accepting any
> liability for letting malware through, it would be a real service, but
> they are not.
Mmm. I agree with the sentiment. But in practise, it will be good
enough to catch most malware, which means people won't hear many
horror stories, and will keep trusting it. That's what Google care
about.
> The centralized server isn't even necessary (or a good way) to provide
> the "protection" of requiring Google approval. They could simply sign
> the code after they "certify" it as malware-free (which, again, they
> don't actually do; read the TOS).
That is a very good point. Given that the sole stated reasoning
behind forbidding code from other places being run is malware - see
https://support.google.com/chrome_webstore/answer/2664769?hl=en -
someone should open a bug asking them to have a signing process,
where extensions not distributed by Google can be installed without
any warning if they've been signed by Google as malware-free, and
just have a large very scary warning otherwise.
Now as you say, in actuality the fear of malware is a convenient way
of further consolidating their control and power, so I doubt they'd
go for that. The revenue collection is just a knock-on effect of
that. Do many people actually pay for proprietary browser extensions
now?
> Debian would not distribute an application whose internal code refused
> to install software without a verified transaction in which money was
> sent to Google -- that "feature" would be removed right away. So Google
> has organized things to ensure the rent-seeking business logic (i.e.,
> the piece of code that verifies payment has been received by Google)
> runs on Google servers. Apparently then nobody notices.
That is an interesting point. An application that was just a "app
store" that facilitated the distribution proprietary programs to
users would never in a million years be allowed in the main section
of Debian's repository. But Chromium have managed by stealth to put
themselves in a somewhat similar position, by changing their policy
after being in the repository for some time. Someone should open a
bug in Debian about it, asking to change the defaults.
I'm aware there are a couple of "someone should open a bug"s in this
email. I'll be that someone, if nobody else does, I just don't have
the time right now ;)
More information about the liberationtech
mailing list