Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devuan considers machine IDs

distrowatch.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: Devuan considers machine IDs

#31

Post by koolba »

amelius wrote: post #24

Doesn't a MAC address lookup or disk UUID lookup provide similar fingerprinting capabilities? Even the contents of one's .bashrc file could be used for fingerprinting. I mean, if you start blocking one thing, where do you stop?

Ideally you work in reverse and only need to grant access to things to which you want to allow access. Start from zero and let an application provide a manifest of what it wants to access. Ex:

* Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id

It's not a new concept at all and there are multiple approaches for implementing things like this. Getting mass market adoption is sadly next to impossible.

Re: Devuan considers machine IDs

#32

Post by ChristianBundy »

pantalaimon wrote: post #28
mirimir wrote: post #22

Earlier quoted context omitted.

Huh? Even if you do $ sudo apt-get -y purge chrome [or whatever its package name is]? And if necessary, find and delete everything that it created.

apt doesn't know about any file the application might have ever created in your home directory.

> And if necessary, find and delete everything that it created.

Re: Devuan considers machine IDs

#33

Post by morganvachon »

Bad title (and I know that fault lies with the source site). At first glance it reads as if the Devuan team is considering embracing/adopting machine IDs, which is counter to their philosophy, when in fact they are against unique identifiers.

Re: Devuan considers machine IDs

#34

Post by amelius »

koolba wrote: post #31
amelius wrote: post #24

Doesn't a MAC address lookup or disk UUID lookup provide similar fingerprinting capabilities? Even the contents of one's .bashrc file could be used for fingerprinting. I mean, if you start blocking one thing, where do you stop?

Ideally you work in reverse and only need to grant access to things to which you want to allow access. Start from zero and let an application provide a manifest of what it wants to access. Ex: * Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id It's not a new concept at all and there are multiple approaches for implementing things like this. Getting mass market adoption is sadly…

That's basically how smartphones do it.

The problem is still that the granularity is not right (except for users who simply want to trust the application). For example, when uploading a photo, I don't want to give Facebook access to my entire filesystem, just the photo that I click. And I don't want to give Facebook access to my camera indefinitely, just now.

It will require a lot of design to get security right without deteriorating the UX too much.

But I agree, it's better than simply blocking everything.

Re: Devuan considers machine IDs

#35

Post by jlgaddis »

mirimir wrote: post #4
nickysielicki wrote: post #2

If a file on your computer is being used by a program to send information to someone, the answer isn't to destroy/randomize the file and break other applications, the answer is to not use the program that is sending your information somewhere.

Sure, but how do you know what programs are misusing it?

  auditd(8)

Re: Devuan considers machine IDs

#36

Post by jolmg »

koolba wrote: post #29
ez7r6i wrote: post #11

Earlier quoted context omitted.

Chromium reads it, but are we sure it's sending it somewhere? Maybe it uses it for bookkeeping of local sessions or something like that.

I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. Interestingly for Windows they pull the machine id from the registry[1] and (at first glance) it doesn't seem like they're doing any hashing. The raw value gets used. Haven't checked if the value gets sent externally but based upon the comment…

> I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value.

/etc/machine-id seems to be a random value. What purpose does hashing it before sending it do? The hash should still uniquely identify a machine. Am I missing something? Kind of makes me think that it's just done so people say "it's ok, because they're hashing it first, so it's secure!", while in reality hashing doesn't do anything to alleviate any concern.

Re: Devuan considers machine IDs

#38

Post by qmarchi »

amelius wrote: post #34
koolba wrote: post #31

Earlier quoted context omitted.

Ideally you work in reverse and only need to grant access to things to which you want to allow access. Start from zero and let an application provide a manifest of what it wants to access. Ex: * Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id It's not a new concept at all and there are multiple approaches for implementing things like this. Getting mass market adoption is sadly…

That's basically how smartphones do it. The problem is still that the granularity is not right (except for users who simply want to trust the application). For example, when uploading a photo, I don't want to give Facebook access to my entire filesystem, just the photo that I click. And I don't want to give Facebook access to my camera indefinitely, just now. It will require a lot of design to get security right with…

> I don't want to give Facebook access to my entire filesystem,

Android's systems of intents and changing how storage security works in Android Q will help with this somewhat. They start expressly prohibiting access to the full filesystem and images and other intent extras must be passed through the intent call, rather than a reference to it on the filesystem.

Re: Devuan considers machine IDs

#39

Post by mirimir »

pantalaimon wrote: post #28
mirimir wrote: post #22

Earlier quoted context omitted.

Huh? Even if you do $ sudo apt-get -y purge chrome [or whatever its package name is]? And if necessary, find and delete everything that it created.

apt doesn't know about any file the application might have ever created in your home directory.

Actually, apt does a pretty good job at finding stuff. Sometimes it can't delete, but it warns you about that.
Post reply on HN