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] Satori - distributed tamper-resistant circumvention tools

Andrew Cady andy at
Mon May 5 01:57:19 PDT 2014

On Sun, May 04, 2014 at 10:51:40AM -0400, Nick wrote:
> Quoth Andrew Cady:
> > On Sat, May 03, 2014 at 12:35:39PM -0400, Nick wrote:
> > > if you're worried about an evil google, hey, they control the
> > > browser, so you've already lost.
> >
> > I use Chromium and update it through my distro, so no, Google does
> > not control the browser (/usr/bin/chromium).
> Me too, but I was thinking that if they were evil they could slip in a
> subtle vulnerability that would be really hard to find [...] This is
> an inherant problem of large, fast-moving, complex software developed
> primarily by one close-knit and corporate-bound team.

Yes... although so could several other people outside Google.  So I
guess that means it's OK ;)

> > But they do, still, control the extensions installed through user
> > accounts (~/.config/chromium/Default/Extensions/).  Google's control
> > is hard-coded into the source.
> What do you mean, they control the extensions through user accounts?
> That they auto-update? Or that Google are the primary source of
> extensions? What is hardcoded into the source?

Appparently what is hard-coded into the source is the default value
of "".  (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:

> 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.

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).

The only real purpose of keeping the actual code distribution
centralized is to extract a portion of money paid for extensions.  If
you want to sell an extension, there's no way around giving to Google
whatever percentage of your gross income that they demand (because
requiring users to configure ExtensionInstallSources is going to kill
your business).

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.

More information about the liberationtech mailing list