> Microsoft provided the FBI with the history of IP addresses tied to that specific GDID.
This article, and most articles about this, doesn't explain where FBI got that GDID from. Ok, Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place, and then try to bind that to a person.
I found another article that explains the process a bit better:
> Stokes got caught because he used the same Windows device for everything, and the GDID stitched all of it back together after the fact.
> Scattered Spider members phoned the jewelry retailer’s IT help desk from Google Voice numbers, posed as locked out employees, and talked support staff into resetting three accounts, two with administrator privileges. From there they installed a tunneling tool called ngrok to get past the retailer’s network defenses, moved roughly 77 gigabytes of data to Amazon cloud storage using ngrok [...]
> Investigators later subpoenaed ngrok and found the account used in the attack had been created on May 12, 2025, at 19:21 UTC from a VPN proxy IP address run by Tzulo, a hosting provider. The IP was a dead end. VPN proxies do that. But the GDID is built different.
> Microsoft’s records showed that at that exact same minute, a Windows device carrying GDID g:6755467234350028 had visited the ngrok signup page. Three hours later, the same GDID visited the retailer’s own website, through the same Tzulo proxy address used to set up the ngrok account. It gave the FBI a device, that don’t rotate the way VPN exit nodes do.
> Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place
What they did was the opposite: ask Microsoft for GDIDs used by attacker-associated IPs within several 24-hour time periods during which attack-related activity took place. Windows pings Microsoft regularly with the GDID, establishing links between your GDID and any IP addresses you use. The IP logs from Microsoft and the VPS provider showed at least 10 instances where a single VPN IP accessed the attacker's VPS and also pinged Microsoft with at least one GDID within a 24-hour period. They found a constant GDID that all instances shared. This seems to have been the most damning GDID-related evidence in the DOJ complaint [1] and yet it wasn't mentioned in the article you linked (or any other articles about this I've seen pop up on HN). It includes the diagram from the complaint (page 18) that outlines this, but devoid of context. The ngrok stuff that the article focuses on was just the cherry on top and was discussed later in the complaint.
What also becomes clear when you read the complaint is that the GDID was just one piece of the puzzle and that they had plenty of other evidence. Attacker-associated IPs were used to access the suspect's Apple, Snapchat, and Facebook accounts, at least one of which was his actual residential IP, not a VPN IP. Once they had revealed the identity of the person who owned these accounts, they were able to all-but-confirm that this was in fact the attacker.
What remains unclear even after reading the complaint is how they were so sure that the GDID they obtained visited specific websites, but honestly, at that point, they were already drowning in evidence, so I don't know if it matters that much. It could be as simple as "he was signed into Edge with his Microsoft account and had sync enabled".
Wait, so it would have, ironically, been safer to allow microsoft telemetry to bypass the VPN entirely and remain associated only with their home network, because it's the phone home to microsoft tunneled through the VPN that tied together all their IP addresses to a single microsoft account. The GDID itself is almost a red herring, as it could have been a session id or username or something only long lived enough to appear comming from several ip addresses to windows update request?
This seems like something that should be easy to confirm, but I haven't seen anyone do it. Do they keep a database of every website visit all Edge users make?
Speculation: if you turn on browser sync so you can have your open tabs and history on different computers, that stuff will be on MS' cloud with your consent, with whatever E2EE they have or claim to have.
But it would be very foolish for a blackhat to turn on browser sync...
I got banned from all computers in my secondary school and from taking the IT GCSE; final school exam in the UK.
Using the school news paper shared account, I copied the bullies coursework in to the public share, made changes to the coursework on my own user account and then copied it back to their work folder using the school news papers account.
MS Office keeps an "Last edited by" field so I got caught. If I had used the school newspaper account to make the edit I wouldn't of been caught. Rookie error. I too discovered a DCOM in the Windows 98 help file that revealed all the hidden shares on the network which scared the school. This was 2004 and I was 15.
Oh and the time, I bought a BB gun off someone at school. I was a librarian in the schools library and showed it off someone of the older grade year. The head librarian confiscated it and reported it to the headmaster. The guy then gave me a copy of Q3A and I stuck with violence the video-game way.
They didn’t. They went to ngrok and asked for all the data at the point of signup. They then looked to find the any of that data at the second site. In this case they had two identical data points - the GDID and the IP address.
What do you mean? The FBI could know that this VPN ip visited ngrok and then the retailer website, but how would it know that that ip was associated with the specific GDID unless microsoft was tracking (timestamp,website,gdid) tuples?
Data Description for Browsing History data type
Microsoft browser data subtype: Information about Address bar and Search box performance on the device
* Text typed in Address bar and Search box
* Service response time
* Autocompleted text, if there was an autocomplete
* Navigation suggestions provided based on local history and favorites
* Browser ID
* URLs (may include search terms)
* Page title and notification text
This criminal mastermind got caught because he did everything but sign his name to the crimes while holding two pieces of government identification in presence of a notary.
The FBI did the bare minimum in terms of old-fashioned detective work, and correlated evidence from various sources.
The obsession with GDID is a complete nothing-burger and I'm tired of seeing it on the front page every other day.
They claim it was an ngrok account that was used to host an endpoint used in the compromise, tied to a microsoft account / gdid that was passed when ngrok software was downloaded from the "microsoft store".
I think it's likely that Microsoft is running a process to correlate "new" GDIDs to old ones, ex:
"Oh look, this one has almost all the serial numbers of components and attached-devices as that other one, it's probably the same computer with a fresh install, let's make a note of that..."
They do not need this, they require you to create a Microsoft account to use your own computer (currently without a phone number, passport and selfie but that will probably change in the future).
Interesting, generally Microsoft bypasses the hosts file name resolution for various MSFT domains. Curious that these were not included (if it works, which I assume the mitigation does).
It's not one homogeneous people reacting to different OSes. It's different people, and they react differently when somebody else's OS does something vs when their OS does something. Windows users don't care or feel locked in because it's the only OS they've known and they depend on it. Linux users expect this type of behavior from Windows, but they can't do more than switching themselves which they already have. Were Linux to do something similar, you remove the offending piece of software.
The performative outrage about the GDID is quite comical in the context that everyone continues to be mum about Google Chrome, a browser explicitly designed to hoover up as much data as possible about you, even having been caught doing it in Incognito Mode [1], all while touting "privacy" features; which means no one besides Google is allowed to do it.
Do you have substantive content to contribute to this discussion, or do you plan to continue telling others what commenting styles you are and aren't a fan of? You've done it twice already.
What Google was "caught" doing was exactly what it was doing in non-incognito mode already. Anyone expecting the websites you visit to know you're in private mode and to not log data is just lacking basic tech knowledge.
It is silly that Google had to explicitly state that in the disclaimer.
But you don't have a service uploading it along with the URLs you visit, which is the creepy part. The ID itself can be useful for your own administration. And if such a service were to appear, it could easily be removed. Everything in Linux is optional, especially as long as you stick to open source.
How do we know? Does anyone check for things like this?
Many, many apps read /etc/machine-id if you do a quick github search.
Apps may have been silently correlating our activity for years without us knowing.
We know DHCP, EFI, GNOME, popularity-contest and many other apps already use it. There are countless ways it could be used already that are hard to detect.
Basically all source is open. Eyes are plenty. Somebody would raise a stink. People can also notice things while monitoring their network via a number of tools like Wireshark, etc. All it takes is one person to notice and share their findings.
It also helps that "Linux" isn't a monolith. One person's installation can be very different from another in terms of the software used. If one piece of software collects, that collection isn't as valuable as Microsoft's because the userbase is much smaller.
It's not perfect, but it's a hell of a lot better. A lot more resistant to abuse. Security in a lot of contexts tends to be relative like that. One's house isn't impenetrable; it's just better than another, in part because the neighborhood is better.
It should be noted that the "correct" usage of /etc/machine-id is that you use it in a way that doesn't allow cross-correlation between different applications by using a HMAC of the machine-id with an application-specific UUID instead of using it directly. systemd-id128 has a command line flag to do this for you.
Whether everyone does that correctly, that's a different question. On the other hand, while developers should be more careful about how they use identifiers like this, if an application on your machine wants to track you they don't need /etc/machine-id.
Mobile's came at the cost of composability between programs and the imposition of policy, which are against the Unix Philosophy. I wouldn't make that trade. Mobile's a sad state of affairs, inferior to desktop in many ways.
You can most likely get better security than mobile's, you just need to e.g. learn to write your own SELinux policies, etc. Facilities are there; they just have a learning curve.
How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /proc emulation. The facilities are there, but it feels like writing your own OS.
What kind of use-case do you have for that? I suppose whatever it is, you could also e.g. write a privileged service that checks those files with whatever security policy you need. Your client wouldn't have direct access to /proc.
Another option may be to set up a container or PID namespace and give your tool direct access to that /proc.
Indeed. One can regenerate it on each shutdown / reboot. The process is a little different depending on whether one has systemd or not. It's a dbus thing but systemd ingests it and there is a specific process around updating that in systemd.
There is also the NetworkID in Firefox about:networking#networkid
Another trackable piece of information on most systems is the creation time of / which just about any application can query unless it is properly isolated. This can be turned into a short unique hash. There are hacky ways to change the Birth time on unmounted filesystems using debugfs which may result in corruption. Some overlay filesystems do not support Birth time but that is not going to help most people unless the general populous expect all applications to be isolated in name spaces and overlay filesystems but this would have to be an expected pattern across all applications universally.
stat / | grep irth
Birth: 2023-04-17 20:27:01.000000000 +0000
stat / | grep irth | md5sum
8b5e849954373f8f3c2a625847e4e858
I agree, tracking data via unique identifiers is evil incarnate, unless it's Google or VC-backed adtech doing it, because how else will they make money having architected their entire businesses around it.
>Every finding here was reproduced on a real Windows 11 Pro VM (build 26200). Nothing is theoretical. See docs/technical-writeup.md for the evidence, tagged by confidence level.
That's sounds nice and all, but everything about it, from "Nothing is theoretical" to "evidence, tagged by confidence level" goes out the window when you find claude as one of the commit authors, and the content is clearly copy pasted output from claude with very little editing. Worse yet, one of the sources he cites is also clearly AI output.
I'm not even against the use of AI here. I would rather see it clearly say either "this is what claude found after I told it to investigate" or "yes this is generated by claude, but I independently verified each of the points myself".
Windows 10 LTSC IOT will be the last Windows I ever use.
As I grow older, I simply do not have the patience or the will to do all these workarounds and tweaks to my OS to turn it from a piece of barely-working corporate spyware into something that I can call a productive tool.
It also seems like interacting with the OS is on its way out anyway, as most people essentially interact with computers via the browser (essentially a different sandboxed OS altogether), whether on desktop or mobile device.
I won't be surprised if MS patches workarounds quickly and won't shed a word on the whole situation. Or worse, pulls the "this helps fighting evil hackers" reasoning.
But it is regenerated by reinstalling. So I suspect that its less fingerprint based and more of an in disk IDs thing. Which goes back to if you clear the right things while the system is not running you might be able to change it
If you care about privacy, you simply cannot use Windows. Microsoft has made it clear over the last decade (if not longer) that they have a vested interest in compromising your ability to use software without exploiting and monetizing data about your usage.
Microsoft is a post-privacy corporation. Eventually, we really have to stop acting so shocked about this sort of thing from them.
I think the difference is that, on Windows, there are background services that constantly ping Microsoft with the device ID. A device ID on its own is not really harmful if it's not exposed to the internet.
Right, the danger here isn't stable unique data itself--there's already plenty of that--but the OS "telemetry" which steals [0] it and reports to Big-Brother along with too much other betraying information. Every site you visit, every program you run, the serial numbers of all your hardware, etc. Even if the GDID were totally absent, it would still be a correlate-able privacy nightmare.
Ultimately there's no informed consent here: The average consumer is disbelieving and surprised if you tell them what kinds of stuff Microsoft has/can put into a dossier. Nobody thinks: "Ah, Edge on a fresh Windows install, I'm glad Microsoft knows every site I visit, and can tell I'm a friend with someone because we use the same bluetooth speaker."
[0] It seems wrong to use the verb "leaks" when it's so obviously intentional.
I mean, there's a ton of unique identifiers on machines already tied to hardware and disks, but that must be a systemd thing since my Devuan machine does not have it.
But given there's no cloud accounts on linux I would imagine it's trivially changed just like a NIC's MAC
Also, seems unlikely it would be used for any single-signon with cloud services.
You're right. I have no idea what it's for, but I'm guessing for distinguishing between deployment images. I'm certainly not going to get too concerned about it.
The issue with the microsoft account was not unique IDs - tons of unique things on a machine.... it was a unique thing tied to an account and shipped to remote places.
There are _some_ cloud accounts for linux such as Ubuntu One, which I would fear could have similar identification capabilities if ever forced by to do so by a 3-letter agency
Any sort of online service you're logged into is going to have your IP and account correlated with a timestamp. Dropbox, GDrive, and even your e-mail provider. While a device identifier might be more useful it's not like the lack a device ID will keep you from being tracked.
> Microsoft provided the FBI with the history of IP addresses tied to that specific GDID.
This article, and most articles about this, doesn't explain where FBI got that GDID from. Ok, Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place, and then try to bind that to a person.
I found another article that explains the process a bit better:
> Stokes got caught because he used the same Windows device for everything, and the GDID stitched all of it back together after the fact.
> Scattered Spider members phoned the jewelry retailer’s IT help desk from Google Voice numbers, posed as locked out employees, and talked support staff into resetting three accounts, two with administrator privileges. From there they installed a tunneling tool called ngrok to get past the retailer’s network defenses, moved roughly 77 gigabytes of data to Amazon cloud storage using ngrok [...]
> Investigators later subpoenaed ngrok and found the account used in the attack had been created on May 12, 2025, at 19:21 UTC from a VPN proxy IP address run by Tzulo, a hosting provider. The IP was a dead end. VPN proxies do that. But the GDID is built different.
> Microsoft’s records showed that at that exact same minute, a Windows device carrying GDID g:6755467234350028 had visited the ngrok signup page. Three hours later, the same GDID visited the retailer’s own website, through the same Tzulo proxy address used to set up the ngrok account. It gave the FBI a device, that don’t rotate the way VPN exit nodes do.
https://www.windowslatest.com/2026/07/10/you-cant-fully-disa...
Although this doesn't explain where Microsoft got that traffic data from. How do Microsoft know which sites a computer visit?
> Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place
What they did was the opposite: ask Microsoft for GDIDs used by attacker-associated IPs within several 24-hour time periods during which attack-related activity took place. Windows pings Microsoft regularly with the GDID, establishing links between your GDID and any IP addresses you use. The IP logs from Microsoft and the VPS provider showed at least 10 instances where a single VPN IP accessed the attacker's VPS and also pinged Microsoft with at least one GDID within a 24-hour period. They found a constant GDID that all instances shared. This seems to have been the most damning GDID-related evidence in the DOJ complaint [1] and yet it wasn't mentioned in the article you linked (or any other articles about this I've seen pop up on HN). It includes the diagram from the complaint (page 18) that outlines this, but devoid of context. The ngrok stuff that the article focuses on was just the cherry on top and was discussed later in the complaint.
What also becomes clear when you read the complaint is that the GDID was just one piece of the puzzle and that they had plenty of other evidence. Attacker-associated IPs were used to access the suspect's Apple, Snapchat, and Facebook accounts, at least one of which was his actual residential IP, not a VPN IP. Once they had revealed the identity of the person who owned these accounts, they were able to all-but-confirm that this was in fact the attacker.
What remains unclear even after reading the complaint is how they were so sure that the GDID they obtained visited specific websites, but honestly, at that point, they were already drowning in evidence, so I don't know if it matters that much. It could be as simple as "he was signed into Edge with his Microsoft account and had sync enabled".
[1] https://www.justice.gov/usao-ndil/media/1450651/dl?inline
Wait, so it would have, ironically, been safer to allow microsoft telemetry to bypass the VPN entirely and remain associated only with their home network, because it's the phone home to microsoft tunneled through the VPN that tied together all their IP addresses to a single microsoft account. The GDID itself is almost a red herring, as it could have been a session id or username or something only long lived enough to appear comming from several ip addresses to windows update request?
They make the default web browser on Windows, and that sends your browsing data if you don't disable its telemetry.
See https://news.ycombinator.com/item?id=48921595
This seems like something that should be easy to confirm, but I haven't seen anyone do it. Do they keep a database of every website visit all Edge users make?
Speculation: if you turn on browser sync so you can have your open tabs and history on different computers, that stuff will be on MS' cloud with your consent, with whatever E2EE they have or claim to have.
But it would be very foolish for a blackhat to turn on browser sync...
I got banned from all computers in my secondary school and from taking the IT GCSE; final school exam in the UK.
Using the school news paper shared account, I copied the bullies coursework in to the public share, made changes to the coursework on my own user account and then copied it back to their work folder using the school news papers account.
MS Office keeps an "Last edited by" field so I got caught. If I had used the school newspaper account to make the edit I wouldn't of been caught. Rookie error. I too discovered a DCOM in the Windows 98 help file that revealed all the hidden shares on the network which scared the school. This was 2004 and I was 15.
Oh and the time, I bought a BB gun off someone at school. I was a librarian in the schools library and showed it off someone of the older grade year. The head librarian confiscated it and reported it to the headmaster. The guy then gave me a copy of Q3A and I stuck with violence the video-game way.
The question you should be asking is: why would Microsoft not do this?
I’m a fan of technical facts coming from technical analysis, not armchair speculation about motives.
Well for one it is illegal in the EU at least, not that Microsoft or other U.S tech giants care about laws.
GDPR compliance.
Not in the US, of course.
They didn’t. They went to ngrok and asked for all the data at the point of signup. They then looked to find the any of that data at the second site. In this case they had two identical data points - the GDID and the IP address.
What do you mean? The FBI could know that this VPN ip visited ngrok and then the retailer website, but how would it know that that ip was associated with the specific GDID unless microsoft was tracking (timestamp,website,gdid) tuples?
Probably Windows constantly pings the MS server and they record those tuples.
It's called telemetry. It means Windows sends data back to Microsoft about what you're doing.
Have some light reading:
"required" spyware: https://learn.microsoft.com/en-us/windows/privacy/required-d...
"optional" (but on by default) spyware: https://learn.microsoft.com/en-us/windows/privacy/optional-d...
This is my favorite:
None of this matters really.
This criminal mastermind got caught because he did everything but sign his name to the crimes while holding two pieces of government identification in presence of a notary.
The FBI did the bare minimum in terms of old-fashioned detective work, and correlated evidence from various sources.
The obsession with GDID is a complete nothing-burger and I'm tired of seeing it on the front page every other day.
I'd take all of this with a cup of salt due to law enforcement's use of parallel construction in tech cases.
Wouldn't the evidence need to be presented to the defense for scrutiny, and if it turned out to be bunk, that would strongly hurt the state's case?
They claim it was an ngrok account that was used to host an endpoint used in the compromise, tied to a microsoft account / gdid that was passed when ngrok software was downloaded from the "microsoft store".
That wouldn't explain how they connected the GDID to the visit to the retailers website
> Three hours later, the same GDID visited the retailer’s own website, through the same Tzulo proxy address used to set up the ngrok account.
I think it's likely that Microsoft is running a process to correlate "new" GDIDs to old ones, ex:
"Oh look, this one has almost all the serial numbers of components and attached-devices as that other one, it's probably the same computer with a fresh install, let's make a note of that..."
They do not need this, they require you to create a Microsoft account to use your own computer (currently without a phone number, passport and selfie but that will probably change in the future).
But I've got nothing to hide
Interesting, generally Microsoft bypasses the hosts file name resolution for various MSFT domains. Curious that these were not included (if it works, which I assume the mitigation does).
https://petri.com/windows-10-ignoring-hosts-file-specific-na...
I cannot believe people tolerate this kind of behavior from such a large company with a huge market.
It does make me wonder if people would react differently if Linux or Apple did the same thing.
Better start believing it; Google Chrome has a 71% market share.
It's not one homogeneous people reacting to different OSes. It's different people, and they react differently when somebody else's OS does something vs when their OS does something. Windows users don't care or feel locked in because it's the only OS they've known and they depend on it. Linux users expect this type of behavior from Windows, but they can't do more than switching themselves which they already have. Were Linux to do something similar, you remove the offending piece of software.
The performative outrage about the GDID is quite comical in the context that everyone continues to be mum about Google Chrome, a browser explicitly designed to hoover up as much data as possible about you, even having been caught doing it in Incognito Mode [1], all while touting "privacy" features; which means no one besides Google is allowed to do it.
[1] https://www.intego.com/mac-security-blog/google-forced-to-de...
Not a fan of whaddaboutism.
It’s much easier to switch browsers than operating systems, especially if you have apps that require windows.
Besides, there is no obligation to be equally outraged about all things.
Do you have substantive content to contribute to this discussion, or do you plan to continue telling others what commenting styles you are and aren't a fan of? You've done it twice already.
What Google was "caught" doing was exactly what it was doing in non-incognito mode already. Anyone expecting the websites you visit to know you're in private mode and to not log data is just lacking basic tech knowledge.
It is silly that Google had to explicitly state that in the disclaimer.
Stopped using Windows in Windows 7 era, never regretted.
Or just use Linux.
/etc/machine-id also exists
But you don't have a service uploading it along with the URLs you visit, which is the creepy part. The ID itself can be useful for your own administration. And if such a service were to appear, it could easily be removed. Everything in Linux is optional, especially as long as you stick to open source.
How do we know? Does anyone check for things like this?
Many, many apps read /etc/machine-id if you do a quick github search.
Apps may have been silently correlating our activity for years without us knowing.
We know DHCP, EFI, GNOME, popularity-contest and many other apps already use it. There are countless ways it could be used already that are hard to detect.
Basically all source is open. Eyes are plenty. Somebody would raise a stink. People can also notice things while monitoring their network via a number of tools like Wireshark, etc. All it takes is one person to notice and share their findings.
It also helps that "Linux" isn't a monolith. One person's installation can be very different from another in terms of the software used. If one piece of software collects, that collection isn't as valuable as Microsoft's because the userbase is much smaller.
It's not perfect, but it's a hell of a lot better. A lot more resistant to abuse. Security in a lot of contexts tends to be relative like that. One's house isn't impenetrable; it's just better than another, in part because the neighborhood is better.
It should be noted that the "correct" usage of /etc/machine-id is that you use it in a way that doesn't allow cross-correlation between different applications by using a HMAC of the machine-id with an application-specific UUID instead of using it directly. systemd-id128 has a command line flag to do this for you.
Whether everyone does that correctly, that's a different question. On the other hand, while developers should be more careful about how they use identifiers like this, if an application on your machine wants to track you they don't need /etc/machine-id.
Yes I think privacy and security on the desktop has fallen way behind mobile and we need much stronger protection these days.
Mobile has no privacy, devs slap in any old SDK that promises them money. Way worse than desktop. Spyware is the basis for mobile apps.
Mobile's came at the cost of composability between programs and the imposition of policy, which are against the Unix Philosophy. I wouldn't make that trade. Mobile's a sad state of affairs, inferior to desktop in many ways.
You can most likely get better security than mobile's, you just need to e.g. learn to write your own SELinux policies, etc. Facilities are there; they just have a learning curve.
How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /proc emulation. The facilities are there, but it feels like writing your own OS.
What kind of use-case do you have for that? I suppose whatever it is, you could also e.g. write a privileged service that checks those files with whatever security policy you need. Your client wouldn't have direct access to /proc.
Another option may be to set up a container or PID namespace and give your tool direct access to that /proc.
Regarding SELinux, looking at https://unix.stackexchange.com/questions/767564/selinux-deni...
> the entries under /proc/<pidnr>/ are running under the respective pid's domain
it seems doable, since you can differentiate which PID belongs to what.
/etc/machine-id also exists
Indeed. One can regenerate it on each shutdown / reboot. The process is a little different depending on whether one has systemd or not. It's a dbus thing but systemd ingests it and there is a specific process around updating that in systemd.
There is also the NetworkID in Firefox about:networking#networkid
Another trackable piece of information on most systems is the creation time of / which just about any application can query unless it is properly isolated. This can be turned into a short unique hash. There are hacky ways to change the Birth time on unmounted filesystems using debugfs which may result in corruption. Some overlay filesystems do not support Birth time but that is not going to help most people unless the general populous expect all applications to be isolated in name spaces and overlay filesystems but this would have to be an expected pattern across all applications universally.
And it’s easily altered.
It can still be correlated with past IDs by countless other methods in order to keep tracking you further.
But then you're using other methods, you're not using the ID as tracker. In fact if you just remove it, it eliminates this entire discussion.
Exactly , windows should be used for gaming. :D
That's exactly the advice at the end.
I agree, tracking data via unique identifiers is evil incarnate, unless it's Google or VC-backed adtech doing it, because how else will they make money having architected their entire businesses around it.
>Every finding here was reproduced on a real Windows 11 Pro VM (build 26200). Nothing is theoretical. See docs/technical-writeup.md for the evidence, tagged by confidence level.
That's sounds nice and all, but everything about it, from "Nothing is theoretical" to "evidence, tagged by confidence level" goes out the window when you find claude as one of the commit authors, and the content is clearly copy pasted output from claude with very little editing. Worse yet, one of the sources he cites is also clearly AI output.
I'm not even against the use of AI here. I would rather see it clearly say either "this is what claude found after I told it to investigate" or "yes this is generated by claude, but I independently verified each of the points myself".
Valid points, not sure why you were down-voted.
Windows 10 LTSC IOT will be the last Windows I ever use.
As I grow older, I simply do not have the patience or the will to do all these workarounds and tweaks to my OS to turn it from a piece of barely-working corporate spyware into something that I can call a productive tool.
It also seems like interacting with the OS is on its way out anyway, as most people essentially interact with computers via the browser (essentially a different sandboxed OS altogether), whether on desktop or mobile device.
I have a sneaking suspicion that that ID can be deleted either with a specific service not running or with Windows powered off.
I won't be surprised if MS patches workarounds quickly and won't shed a word on the whole situation. Or worse, pulls the "this helps fighting evil hackers" reasoning.
it is generated from identifiers on device by a remote microsoft system where it is stored ..
But it is regenerated by reinstalling. So I suspect that its less fingerprint based and more of an in disk IDs thing. Which goes back to if you clear the right things while the system is not running you might be able to change it
If you care about privacy, you simply cannot use Windows. Microsoft has made it clear over the last decade (if not longer) that they have a vested interest in compromising your ability to use software without exploiting and monetizing data about your usage.
Microsoft is a post-privacy corporation. Eventually, we really have to stop acting so shocked about this sort of thing from them.
wow.. How is this not a bigger deal
Obvious workaround to get off windows and use Linux…
But do any popular linux distributions use an identifier? Ubuntu, Kali, Mint, Arch, etc?
It seems an attractive way for devs to work out telemetry. Awful in reality; but I imagine attractive.
At least Debian and Ubuntu have /etc/machine-id, presumably easily changed - but it’s there.
I think the difference is that, on Windows, there are background services that constantly ping Microsoft with the device ID. A device ID on its own is not really harmful if it's not exposed to the internet.
Right, the danger here isn't stable unique data itself--there's already plenty of that--but the OS "telemetry" which steals [0] it and reports to Big-Brother along with too much other betraying information. Every site you visit, every program you run, the serial numbers of all your hardware, etc. Even if the GDID were totally absent, it would still be a correlate-able privacy nightmare.
Ultimately there's no informed consent here: The average consumer is disbelieving and surprised if you tell them what kinds of stuff Microsoft has/can put into a dossier. Nobody thinks: "Ah, Edge on a fresh Windows install, I'm glad Microsoft knows every site I visit, and can tell I'm a friend with someone because we use the same bluetooth speaker."
[0] It seems wrong to use the verb "leaks" when it's so obviously intentional.
I mean, there's a ton of unique identifiers on machines already tied to hardware and disks, but that must be a systemd thing since my Devuan machine does not have it.
But given there's no cloud accounts on linux I would imagine it's trivially changed just like a NIC's MAC
Also, seems unlikely it would be used for any single-signon with cloud services.
I'm guessing Devuan still has /var/lib/dbus/machine-id.
You're right. I have no idea what it's for, but I'm guessing for distinguishing between deployment images. I'm certainly not going to get too concerned about it.
The issue with the microsoft account was not unique IDs - tons of unique things on a machine.... it was a unique thing tied to an account and shipped to remote places.
TIL.
Exists on Slackware64 15.0 but Does not.There are _some_ cloud accounts for linux such as Ubuntu One, which I would fear could have similar identification capabilities if ever forced by to do so by a 3-letter agency
Any sort of online service you're logged into is going to have your IP and account correlated with a timestamp. Dropbox, GDrive, and even your e-mail provider. While a device identifier might be more useful it's not like the lack a device ID will keep you from being tracked.
this is a Windows 11 thing only?
when LTSC exists why are people using W11 ?
It's present on one of my windows 10 LTSC VMs but not the other, so not sure how it got there.
windows 11 and LTSC aren't mutually exclusive.
So, uhh, fuck windows and use Linux if you value your security and privacy?