> I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed.
That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.
If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.
edit: s/Google Chrome/Chromium/g
> This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android
Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.
> In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.
Did you do a write up of this study? I'd be interested to read it :)
It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]
> and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.
No, Google Play Services was first released in 2012, whereas Google's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning.
> It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]
Fair point, but AFAIK Android was never released as an open source project until it was Google owned.
No, Google Play Services was first released in 2012, whereas Google's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning.
You were emphasising the wrong part of my sentence. Many proprietary components that are now part of Google Play Services have existed seperately for longer than the "Play" brand had: https://en.wikipedia.org/wiki/Google_Mobile_Services
> Fair point, but AFAIK Android was never released as an open source project until it was Google owned.
Since we're both being pedantic here, I never said that it was. :) I believe the GP did though (the person you were initially replying to, that is).
> Many proprietary components that are now part of Google Play Services have existed seperately for longer than the "Play" brand had
You're right, and that's one of the things that bothers me about Android's reputation for being an "open" or "open source friendly" OS. Yes, AOSP is open source software (if you leave out the binary blobs necessary for the radios and GPU to work), but even plain vanilla Android as shipped by Google is far from open source. Google has steadily been moving towards a closed/locked down model in many of their projects.
>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.
The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".
There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany). Konquorer was still kHTML last time I checked, but there are with webkit ports as well if that's really what you want. Then there's Opera, which on some platforms (eg Linux) is still using it's older renderer rather than Blink (see footnote); and Otter as well. There's quite a few Firefox forks too (eg Palemoon)....and if all else fails, you can always run lynx or elinks :p
So there are definitely quite a few alternatives (the last two were obviously a joke though). Granted many are not as feature rich, but they'll still be HTML5 compliant.
Thank you for the correction on the Google Chrome/Chromium point though. Updated my post to reflect that.
Footnote: has anyone checked if this is a Blink issue or just Chromium? Because Opera, Vivaldi and other browsers use Blink but likely wouldn't have hotword. So that would be even more alternatives available.
>Granted many are not as feature rich, but they'll still be HTML5 compliant.
This is a meaningless statement. HTML5 is a moving target. And on top of that, webpage design has deteriorated to the levels we saw around 2000 again: to be usable, your browser has to mirror the most popular engines well enough that sites work.
Most of the browsers I exampled used popular engines (Blink, webKit, Gecko).
And if you want to get pedantic about HTML5 being a moving target, technically it's not. People often lump the other web front end components (CSS, SVG, EMCAScript, etc) under the HTML5 heading - those components will obviously have their own specification enumerations. Furthermore, a lot of the tertiary technologies that are a moving target are either experimental features / proposed drafts (ie not part of the final specification) or browser specific extensions. Most sites tend to avoid using these without fallback code for non-supporting browsers (demo sites being the obvious exception).
>There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany).
What about Midori (LGPL 2.1)? For some reason it's not available for jessie, but 0.4.3 is available for wheezy, stretch, and sid: https://packages.debian.org/stretch/midori
Firefox does auto-download an OpenH264 binary on systems without a supported H.264 decoder library (if this feature is enabled, which it isn't currently in Debian's iceweasel packages). But note that OpenH264 is free software available under the BSD license:
Firefox downloads binaries from Cisco because Cisco can legally distribute this software in binary form in countries where H.264 patents apply, while Mozilla can't do so directly.
There was also a plan discussed to make it easy to automatically verify that the binary corresponds with the published source code, but as far as I know that work hasn't been done yet:
> That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.
Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code.
It's highly suggestive.
> If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.
Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up?
> Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code. It's highly suggestive.
Indeed. But that doesn't change my statement.
> Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up?
Because you'd still have the same browser choices if you did move :p
In all seriousness though, what are your options:
1. fork Chromium and remove the closed components
2. use another browser
3. moan on the internet
You've got 3 nailed but that doesn't seem to be helping the situation. So maybe you should start a fork instead? Or perhaps go with my suggestion of boycotting Chromium since it actually turns out to be the easiest practical solution despite your exaggerative remark.
> An obvious one, getting an explanation from the vendor / upstream before we proceed to any decision.
I'd already addressed that. In fact you quoted it when you posted your condescending reply. An explanation is worthless if the code cannot be reviewed. Such a feature should either be opt-in and/or open source.
I couldn't care less what explanation Google give, I just don't want this built into my browser.
> It's normal to have a collection of patches in the package file / port.
It is, but then you're relying on your package maintainers to patch Chromium (or compile the software yourself). Thus personally I think it's easier just to use another browser which doesn't need to be patched to remove an unwanted feature.
That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.
If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.
edit: s/Google Chrome/Chromium/g
> This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android
Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.
> In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.
Did you do a write up of this study? I'd be interested to read it :)