Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[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