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 "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 > 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. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
