If you're using the official web installer (see http://www.google.com/chrome/?hl=en)
to get Google Chrome, in addition another program will be downloaded
and installed on your box - the Google Updater. This small tool
resides permanent in memory and stays even active if you choose to
abandon Chrome by uninstalling it (maybe fixed somehow in the future).
So lets have a small look on the Google Updater:
If you're checking for an update for Chrome (via menu) the Google
Updater gets active. It sends a HTTP(!) request to tools.google.com.
The request header looks like this:
If attributes like machineid or userid raise your eyebrows, you'll
start to investigate a little bit more. A quick look up in your
Windows Registry reveal some new stored keys (among others).
Flying through the src of chromium I couldn't locate code that is
responsible for creating these keys. Conclusion: the Google Updater
must be the culprit. Seems as the Updater is tagging your system with
a machine-id and your Windows user account with an user-id. These to
values are send with each update request to the Google servers.
What's the reason behind tagging each box and each user account with
such GUIDs? Where does Google document these features of the Google
Updater? What about users that don't want to get tagged this way?
(Yeah, I know about Mozilla doing something similar, but there are
significant differences. And I know about the Chrome EULA - not the
Updater EULA).
Why does Google use HTTP instead of a HTTPS request? Ok, first I have
to be glad about that fact, it made it easier to get the request
details. But for the future it seems to be more secure to use HTTPS
for such purposes.
Will the Google Updater be integrated with the Google Update Service
used by Google Pack? Will this Google Update Service get open sourced
too?
How to configure the Google Updater? Where you can choose the update
interval or choose to disable automatic update checks (besides
renaming the .exe or disabling the auto-start for the Google Updater)?
just use chromium nightly build rather than chrome from google.com/ chrome. Chromium nightly build is more "safe" than chrome from google side. And you'd better update chrome ur self rather than "Updater".
regards, Stellit
On Sep 5, 2008, at 11:02 AM, boardrai...@googlemail.com wrote:
> If you're using the official web installer (see http://www.google.com/chrome/?hl=en) > to get Google Chrome, in addition another program will be downloaded > and installed on your box - the Google Updater. This small tool > resides permanent in memory and stays even active if you choose to > abandon Chrome by uninstalling it (maybe fixed somehow in the future).
> So lets have a small look on the Google Updater: > If you're checking for an update for Chrome (via menu) the Google > Updater gets active. It sends a HTTP(!) request to tools.google.com. > The request header looks like this:
> If attributes like machineid or userid raise your eyebrows, you'll > start to investigate a little bit more. A quick look up in your > Windows Registry reveal some new stored keys (among others).
> Flying through the src of chromium I couldn't locate code that is > responsible for creating these keys. Conclusion: the Google Updater > must be the culprit. Seems as the Updater is tagging your system with > a machine-id and your Windows user account with an user-id. These to > values are send with each update request to the Google servers.
> This leads me to a few questions:
> Google claims Chrome respective Chromium is open source (see > http://groups.google.com/group/chromium-discuss/msg/6376a7793f3f0051). > What about the Google Updater? Where is the src code for this program? > (Please point me to the right direction if I missed that out.)
> What's the reason behind tagging each box and each user account with > such GUIDs? Where does Google document these features of the Google > Updater? What about users that don't want to get tagged this way? > (Yeah, I know about Mozilla doing something similar, but there are > significant differences. And I know about the Chrome EULA - not the > Updater EULA).
> Why does Google use HTTP instead of a HTTPS request? Ok, first I have > to be glad about that fact, it made it easier to get the request > details. But for the future it seems to be more secure to use HTTPS > for such purposes.
> Will the Google Updater be integrated with the Google Update Service > used by Google Pack? Will this Google Update Service get open sourced > too?
> How to configure the Google Updater? Where you can choose the update > interval or choose to disable automatic update checks (besides > renaming the .exe or disabling the auto-start for the Google Updater)?
> just use chromium nightly build rather than chrome from google.com/
> chrome. Chromium nightly build is more "safe" than chrome from google
> side.
> And you'd better update chrome ur self rather than "Updater".
> regards,
> Stellit
> On Sep 5, 2008, at 11:02 AM, boardrai...@googlemail.com wrote:
> > If you're using the official web installer (seehttp://www.google.com/chrome/?hl=en)
> > to get Google Chrome, in addition another program will be downloaded
> > and installed on your box - the Google Updater. This small tool
> > resides permanent in memory and stays even active if you choose to
> > abandon Chrome by uninstalling it (maybe fixed somehow in the future).
> > So lets have a small look on the Google Updater:
> > If you're checking for an update for Chrome (via menu) the Google
> > Updater gets active. It sends a HTTP(!) request to tools.google.com.
> > The request header looks like this:
> > If attributes like machineid or userid raise your eyebrows, you'll
> > start to investigate a little bit more. A quick look up in your
> > Windows Registry reveal some new stored keys (among others).
> > Flying through the src of chromium I couldn't locate code that is
> > responsible for creating these keys. Conclusion: the Google Updater
> > must be the culprit. Seems as the Updater is tagging your system with
> > a machine-id and your Windows user account with an user-id. These to
> > values are send with each update request to the Google servers.
> > This leads me to a few questions:
> > Google claims Chrome respective Chromium is open source (see
> >http://groups.google.com/group/chromium-discuss/msg/6376a7793f3f0051).
> > What about the Google Updater? Where is the src code for this program?
> > (Please point me to the right direction if I missed that out.)
> > What's the reason behind tagging each box and each user account with
> > such GUIDs? Where does Google document these features of the Google
> > Updater? What about users that don't want to get tagged this way?
> > (Yeah, I know about Mozilla doing something similar, but there are
> > significant differences. And I know about the Chrome EULA - not the
> > Updater EULA).
> > Why does Google use HTTP instead of a HTTPS request? Ok, first I have
> > to be glad about that fact, it made it easier to get the request
> > details. But for the future it seems to be more secure to use HTTPS
> > for such purposes.
> > Will the Google Updater be integrated with the Google Update Service
> > used by Google Pack? Will this Google Update Service get open sourced
> > too?
> > How to configure the Google Updater? Where you can choose the update
> > interval or choose to disable automatic update checks (besides
> > renaming the .exe or disabling the auto-start for the Google Updater)?
> On Sep 5, 10:14 am, Stellit <stellit.s...@gmail.com> wrote: >> just use chromium nightly build rather than chrome from google.com/ >> chrome. Chromium nightly build is more "safe" than chrome from google >> side. >> And you'd better update chrome ur self rather than "Updater".
>> regards, >> Stellit
>> On Sep 5, 2008, at 11:02 AM, boardrai...@googlemail.com wrote:
>>> If you're using the official web installer (seehttp://www.google.com/chrome/?hl=en) >>> to get Google Chrome, in addition another program will be downloaded >>> and installed on your box - the Google Updater. This small tool >>> resides permanent in memory and stays even active if you choose to >>> abandon Chrome by uninstalling it (maybe fixed somehow in the >>> future).
>>> So lets have a small look on the Google Updater: >>> If you're checking for an update for Chrome (via menu) the Google >>> Updater gets active. It sends a HTTP(!) request to tools.google.com. >>> The request header looks like this:
>>> If attributes like machineid or userid raise your eyebrows, you'll >>> start to investigate a little bit more. A quick look up in your >>> Windows Registry reveal some new stored keys (among others).
>>> Flying through the src of chromium I couldn't locate code that is >>> responsible for creating these keys. Conclusion: the Google Updater >>> must be the culprit. Seems as the Updater is tagging your system >>> with >>> a machine-id and your Windows user account with an user-id. These to >>> values are send with each update request to the Google servers.
>>> This leads me to a few questions:
>>> Google claims Chrome respective Chromium is open source (see >>> http://groups.google.com/group/chromium-discuss/msg/6376a7793f3f0051) >>> . >>> What about the Google Updater? Where is the src code for this >>> program? >>> (Please point me to the right direction if I missed that out.)
>>> What's the reason behind tagging each box and each user account with >>> such GUIDs? Where does Google document these features of the Google >>> Updater? What about users that don't want to get tagged this way? >>> (Yeah, I know about Mozilla doing something similar, but there are >>> significant differences. And I know about the Chrome EULA - not the >>> Updater EULA).
>>> Why does Google use HTTP instead of a HTTPS request? Ok, first I >>> have >>> to be glad about that fact, it made it easier to get the request >>> details. But for the future it seems to be more secure to use HTTPS >>> for such purposes.
>>> Will the Google Updater be integrated with the Google Update Service >>> used by Google Pack? Will this Google Update Service get open >>> sourced >>> too?
>>> How to configure the Google Updater? Where you can choose the update >>> interval or choose to disable automatic update checks (besides >>> renaming the .exe or disabling the auto-start for the Google >>> Updater)?
> On Sep 5, 2008, at 12:36 PM, s...@stewartabel.co.uk wrote:
> > Where can I find the nightly builds?
> > On Sep 5, 10:14 am, Stellit <stellit.s...@gmail.com> wrote:
> >> just use chromium nightly build rather than chrome from google.com/
> >> chrome. Chromium nightly build is more "safe" than chrome from google
> >> side.
> >> And you'd better update chrome ur self rather than "Updater".
> >> regards,
> >> Stellit
> >> On Sep 5, 2008, at 11:02 AM, boardrai...@googlemail.com wrote:
> >>> If you're using the official web installer (seehttp://www.google.com/chrome/?hl=en)
> >>> to get Google Chrome, in addition another program will be downloaded
> >>> and installed on your box - the Google Updater. This small tool
> >>> resides permanent in memory and stays even active if you choose to
> >>> abandon Chrome by uninstalling it (maybe fixed somehow in the
> >>> future).
> >>> So lets have a small look on the Google Updater:
> >>> If you're checking for an update for Chrome (via menu) the Google
> >>> Updater gets active. It sends a HTTP(!) request to tools.google.com.
> >>> The request header looks like this:
> >>> If attributes like machineid or userid raise your eyebrows, you'll
> >>> start to investigate a little bit more. A quick look up in your
> >>> Windows Registry reveal some new stored keys (among others).
> >>> Flying through the src of chromium I couldn't locate code that is
> >>> responsible for creating these keys. Conclusion: the Google Updater
> >>> must be the culprit. Seems as the Updater is tagging your system
> >>> with
> >>> a machine-id and your Windows user account with an user-id. These to
> >>> values are send with each update request to the Google servers.
> >>> This leads me to a few questions:
> >>> Google claims Chrome respective Chromium is open source (see
> >>>http://groups.google.com/group/chromium-discuss/msg/6376a7793f3f0051)
> >>> .
> >>> What about the Google Updater? Where is the src code for this
> >>> program?
> >>> (Please point me to the right direction if I missed that out.)
> >>> What's the reason behind tagging each box and each user account with
> >>> such GUIDs? Where does Google document these features of the Google
> >>> Updater? What about users that don't want to get tagged this way?
> >>> (Yeah, I know about Mozilla doing something similar, but there are
> >>> significant differences. And I know about the Chrome EULA - not the
> >>> Updater EULA).
> >>> Why does Google use HTTP instead of a HTTPS request? Ok, first I
> >>> have
> >>> to be glad about that fact, it made it easier to get the request
> >>> details. But for the future it seems to be more secure to use HTTPS
> >>> for such purposes.
> >>> Will the Google Updater be integrated with the Google Update Service
> >>> used by Google Pack? Will this Google Update Service get open
> >>> sourced
> >>> too?
> >>> How to configure the Google Updater? Where you can choose the update
> >>> interval or choose to disable automatic update checks (besides
> >>> renaming the .exe or disabling the auto-start for the Google
> >>> Updater)?
On Sep 5, 5:14 am, Stellit <stellit.s...@gmail.com> wrote:
> just use chromium nightly build rather than chrome from google.com/
> chrome. Chromium nightly build is more "safe" than chrome from google
> side.
> And you'd better update chrome ur self rather than "Updater".
You're right! Currently it seems hypocritical to me that Google Chrome
is publicly reputed to be open source. As long as it is bundled with
closed source components like Google Update. Especially when these
closed source components start tagging your box and your Windows user
accounts with GUIDs. So it's recommended to use Chromium directly.
But what about the vast majority of users getting their copy of Chrome
from the Google frontpage? They aren't tech-savvy enough to do this
and they have no choice to allow or prevent this form of tagging. They
even have no possibility to configure the updater.
On Sep 8, 5:47 am, boardrai...@googlemail.com wrote:
> You're right! Currently it seems hypocritical to me that Google Chrome
> is publicly reputed to be open source. As long as it is bundled with
> closed source components like Google Update. Especially when these
> closed source components start tagging your box and your Windows user
> accounts with GUIDs. So it's recommended to use Chromium directly.
It may be worse than that.
When I went to install Google Chrome, as soon as I clicked on the
download button in Firefox the Google Update engine started
downloading Google Chrome. Examining the source code for the page, it
looks like Google could have kicked off the download without clicking
ANYTHING on the page, using "_GU_*()" calls.
This means that the security of the Google Update service is pretty
important. If it can install a component without user intervention,
then they need to be DAMNED sure that nobody else can convince Google
Update that they're "google enough" to download and install their
malware.
I've sent mail to Google asking for some information about the
security model used by Google Update, but in the meantime I've removed
it and the software that included it... and I'm going to hold off on
checking out Chrome until this is resolved.
On Sep 8, 5:47 am, boardrai...@googlemail.com wrote:
> You're right! Currently it seems hypocritical to me that Google Chrome
> is publicly reputed to be open source. As long as it is bundled with
> closed source components like Google Update. Especially when these
> closed source components start tagging your box and your Windows user
> accounts with GUIDs. So it's recommended to use Chromium directly.
It may be worse than that.
When I went to install Google Chrome, as soon as I clicked on the
download button in Firefox the Google Update engine started
downloading Google Chrome. Examining the source code for the page, it
looks like Google could have kicked off the download without clicking
ANYTHING on the page, using "_GU_*()" calls.
This means that the security of the Google Update service is pretty
important. If it can install a component without user intervention,
then they need to be DAMNED sure that nobody else can convince Google
Update that they're "google enough" to download and install their
malware.
I've sent mail to Google asking for some information about the
security model used by Google Update, but in the meantime I've removed
it and the software that included it... and I'm going to hold off on
checking out Chrome until this is resolved.
On Sep 9, 1:33 pm, Peter da Silva <res...@gmail.com> wrote:
> When I went to install Google Chrome, as soon as I clicked on the
> download button in Firefox the Google Update engine started
> downloading Google Chrome.
Then you had the GoogleOneClick plugin installed before. Maybe through
Google Gears. The culprit is called npgoogleoneclick5.dll for Firefox
and other browsers, except Internet Explorer which gets some nasty
ActiveX component instead [1][2][3][4][5][6].
> Examining the source code for the page, it
> looks like Google could have kicked off the download without clicking
> ANYTHING on the page, using "_GU_*()" calls.
The _GU_*() calls are not that important. These are just JavaScript
functions which wrap up the whole process and create the necessary
query parameters. The plugin API (maybe just a subset) is shown here:
--snip--
window.google.update.oneclick = {
getOneClickVersion: function() {
try {
return
window.google.update.oneclickPlugin_.GetOneClickVersion()
} catch(f) {
return -1
}
},
install: function(f,h,j,i,k) {
var l="http://tools.google.com";
l+="/service/update2/installping";
var o=GU_buildGlobalExtra(h,j),p='"'+GU_BuildTag(f,o)+'"';
for (a=0; a<f.length; ++a) {
var m=l;
m+="?appid="+encodeURIComponent(f[a].c);
m+="&lang="+encodeURIComponent(h);
m+="&iid="+encodeURIComponent(_GU_getIid());
m+="&installsource=oneclick";
var q=new Image;
q.src=m
}
var r="/install "+p;
try {
window.google.update.oneclickPlugin_.Install(r,i,k)
} catch(s) {
var n = s.g;
n||(n = -2);
k(n)
}
}
}
--/snip--
The two plugin functions are GetOneClickVersion() and Install(r,i,k).
The first call returns the version number ("5"), the second one
triggers the automatic install process. The parameter r locates the
program that will be installed, i and k seem to be callback functions
- i in case of success and k as fallback in case of an error [7][8].
> This means that the security of the Google Update service is pretty
> important
I think we have to separate a bit the Google Update background task
that I've mentioned from this plugin. But yes, definitely you're right
about the security. It's important in both cases.
The plugin needs internal security checks to prevent evil sites from
abusing it. Since there is no source code for the plugin we have a
black box situation - security through obscurity. Same as for the
Google Updater attached to Chrome for his update checks.
> I've sent mail to Google asking for some information about the
> security model used by Google Update
Hopefully you get some illuminating feedback beyond "we aren't evil"
*eg*
> and I'm going to hold off on checking out Chrome until this is resolved
I don't trust Chrome as long as it's bundled with closed source
components and silently installs some backdoor services like the
Google Updater (which tags you and your box) and plugins (which allow
Google and others? to automatically install software). Maybe I'll
check out Chromium or a fork, when it hits a stable Linux version.
That function install is called with some parameters.
var f = getApps(); //an Array with 2 items: Chrome and Gears
var h = 'sv'; // language code
var j = areStatsEnabled(); //?
i = function; //this one is called on install success
k = function; //called on fail
A service "update2/installping" gets one HTTP GET requests for each of
the two products, and the result is not used or verified:
> var q=new Image;
> q.src=m
It's just a "ping" that someone wanted to install them, along with
"_GU_getlid()". This iid should come from a cookie. If missing, it
uses "{11112222-3333-4444-5555-666677778888}" -- looks like a GUID.
Iid might be a tracking cookie? Someone could want to investigate what
info is tied to it and how it is used.
Then it finally activates Install() in the oneclick plugin.
var r = '/install "appguid={8A69D345-D564-463C-AFF1-
A69D9E530F96}&iid={aaaa1AF2-bbA0-B7cc-dd1D-
eeeeECD7eeee}&lang=sv&browser=0&usagestats=1&appname=Google
%20Chrome&needsadmin=false&appguid={00058422-BABE-4310-9B8B-
B8DEB5D0B68A}&appname=ChromeGears&needsadmin=false"';
(I covered parts of my iid, just for good measure :-).
With urlsnooper from donationcoder, I got to know what that oneclick
does with my network.
Next maybe google update gets involved (xml says "gupdate" instead of
"OneClick") and machineid, userid, and the stuff we know from above.
Next comes download links, hashes and file sizes for
chrome_installer.exe and gears-chrome-opt.msi. Presumably those
installers are hash- and size-checked before they are run. The
oneclick/gupdate code should need to verify this whole message though,
and I don't see HTTPS or hashes that it would be done. Maybe all those
are locked to only run with google.com, which together with rigorous
testing for normal software bugs (MSXML?) would be almost enough.
On 12 Sep., 17:12, "Simon B." <simon.boh...@gmail.com> wrote:
> var j = areStatsEnabled(); //?
Tells the function if the user agreed to send usage statistics and
crash reports to Google.
See:
<input name="checkbox" id="statcb" type="checkbox"> <label
for="statcb"><b>Optional:</b> Help make Google Chrome better by
automatically sending usage statistics and crash reports to Google.
> Iid might be a tracking cookie?
It's not adequate as tracking cookie because it's only valid for the
current session. But you don't need tracking cookies, tagging the user
persistently and without notice is even better.
On Sep 10, 5:48 am, boardraider <boardrai...@googlemail.com> wrote:
> On Sep 9, 1:33 pm, Peter da Silva <res...@gmail.com> wrote:
> > I've sent mail to Google asking for some information about the
> > security model used by Google Update
> Hopefully you get some illuminating feedback beyond "we aren't evil"
> *eg*
Don't know if you've heard back from them yet, but GoogleUpdater.exe
gets installed as a Microsoft ClickOnce application, about which more
details can be found here (including notes on the security model):
http://en.wikipedia.org/wiki/ClickOnce
|
