Man, permit me to tell you again: there are lots of ways at disposition of the rogue software to fingerprint you. It is plain and simple: the single way to not be fingerprinted is to not use that rogue software. Or, even better, to disconnect your computer from internet.

And anyways, I seriously doubt that Google uses that machine-id or ever used it for fingerprinting. Or by any other reasonable smart rogue program, because there are many other better ways to fingerprint people. Not that I claim that Google or any other companies do those things.

Just to say that, that Chrome (and Chromium) stores somewhere a value named "gaia_id" and I leave to the reader exercise to find where it is put, for what it is used and how it is obtained.

If you already know where/how it's being used, why aren't you sharing that knowledge?

Yes, there are lots of ways programs could put a fingerprint on your activity, but their man pages state when it does happen. You're stating that Chrome/Chromium are doing it, without being explicit in the matter. If you're going to make that allegation, it's up to you to prove it.

Yes, I wrote the same thing in my first post in this thread. Nothing needs retelling.

I did not write they did. I wrote that I am not surprised by anything they do that violates privacy.

The information is found anywhere around the web where the file is discussed:

/var/lib/dbus/machine-id
/etc/machine-id

I made no such allegation. I wrote that I am not surprised by anything the Google folks do.

I shared information and observations in response to the original post. People should form their own opinions about the file.

You didn't make the allegation, upnort. ZhaoLin1457 made it.

I don't want you to think I missed your point, but as an aside this returns 0 for me. I tried a few other things, like including the comma (since / is a filepath, that obviously didnt work) and running it as root. But it returns 0. I use stat, I guess my filesystem doesn't know when / was born.

1 members found this post helpful.

Excuse me, but anyone of you brave Americans bothered to look into "~/.config/chromium" ?

Because there's a file named "Local State" which contains that mentioned "gaia_id" with value a big number. Also there's "gaia_name" and "gaia_given_name" with values my name from my own Google Account. There's even "gaia_picture_file_name" with value "Google Profile Picture.png"

So, I think this "gaia_id" is somehow connected to my Google Account and represents probably my unique id on Google. True, I am logged in on Chromium.

Certainly, it get a special treatment and it is stored right on Chromium's main configuration file absolutely only to improve my web browsing experience...

1 members found this post helpful.

Yes the filesystem does indeed have to include birth date metadata for that specific example to work, and not all do. However, it will work on ext4, so that's going to cover the majority of users.

It doesn't work for me and I'm using ext4. If I use stat on / without arguments, I get:
Birth: -

Now what the heck does that mean? That my root directory was never created but goes back to the Big Bang?

PS just tried it on a freshly created file and a freshly created directory. Still get nothing. If this field exists, stat isn't able to read it.

Works for me.

Personally, I'm not that worried of what Google and other corporation might do with my identity (which they have, since I use an Android smartphone). I imagine that I can handle them. I reserve my tin foil hat for intrusions from various national security services. In the near future, getting a new smartphone or PC might mean hosting preinstalled spyware unbeknownst to me. And without pop-up ads.

It means that the file system you use on the / mount doesn't store the "created" or "Birth" date/time, which is true for all ext* ones (the date/time stamps stored are only last access, last change and last modified).
Out of my head I do not know which fs'es do store the creation date/time.

Perhaps your kernel or core-utils isn't recent enough. The underlying statx() call that provides this info was introduced in kernel 4.11.

update: a quick google search reveals that it is supported in the 'stat' command from coreutil 8.31 onward which came out in March.

1 members found this post helpful.

What if the former hands over the information they gather to the latter?

Ah! I've got 8.25.

I'm not convinced...

This is more of a mitigation, where deleting a file and rebooting (or manually deleting a file and restarting the daemon) is being touted as a benefit to using that distribution.

If the issue is with chromium, then every startup, newly visited website, newly opened tab - would need a unique ID, to be of any use whatsoever...

chromium uses dbus for IPC and I thought it may check /etc/machine-id, as crude means of checking for a valid the dbus installation.

It could equally use other methods to ID the host system, but it could also use various methods, to gain a better fingerprint.

Without checking the chromium source or understanding the code, it's hard to say:

https://github.com/chromium/chromium...chine-id&type=

2 members found this post helpful.

So from the links above:

browser_dm_token_storage_linux.cc
This is certainly /etc/machine-id being utilised to generate a "client ID" - i.e. it is not being used for any kind of IPC purpose but is being hashed and "transmitted outside of the machine"...

While I believe there are some concerns it is being misused here, it's google after all and entirely unsurprising.

Would be interesting to know examples of other software using the machine-id for such purposes...?

The Devuan project's concerns do seem valid, but I remain unconvinced that rebooting is any kind of "solution" to tracking - because that seems to be in effect what they're proposing...?

The Devuan project don't seem to frequent this site, but I wonder if they would like to comment?

1 members found this post helpful.