Media on a prim and tracking pixels as a method to acquire IP addresses.

[nu11value]

I think most people are aware that Media in SL when it connects to servers outside SL can give away your IP address as the foreign server needs to know your IP address in order to stream you the content. This is a trade off in security we accept when we wish to enjoy this content. In preferences -> sound and media -> Media autoplay can be set to disabled, which then allows us to use the media controls in the top right of the viewer to turn on media when we want and are in a region we trust.

With media autoplay set to disabled, I was experimenting with the media tab in the texture section of a prim - Media on a prim. I added a url to a youtube video, took the prim into inventory and then rezzed it out. Confirmed it didn't autoplay. I had to touch the face I configured for media for it to play. I repeated this with a url to a mp3 file. Same result. So far so good.

But then I wanted to see how it would work with a url to a PNG file. This time when I rezzed out the prim, the media configured face displayed the PNG. I then decided to take it a step further. I changed the url to a tracking pixel png file. Again, worked as I rezzed out of my inventory. Checking the tracking pixel website, I did get the IP info for myself and the other avatars in the region. The tracking pixel also gives you web client and system info. So which web browser is configured with your second life viewer and the operating system.

I have submitted the information to security@lindenlab.com and was told this how media on a prim works. I tried a support ticket after I discovered an attack hud on marketplace that claims to be able to get IP address / system information of other users. I was told this wasn't something concierge handled - it was a security matter. So, they couldn't help look into the product available on marketplace.

So now I'm trying to submit this as a bug to Canny. I'm making this post to spread awareness of what I think is a security risk for other users who would not be able to stop a person from getting their IP address if they are in the same region. Also hoping people will upvote the canny if they agree this could be a bug. I think the expected behaviour of disabling media autoplay is that it would be consistent with disabling autoplay to any url - it would not render a static image (a png file) in the same way it won't autoplay a youtube link or link to an mp3 file.

https://feedback.secondlife.com/bug-reports/p/disabling-media-autoplay-doesnt-stop-static-images-allows-for-tracking-pixels-an

Edit: Just want to make it extra clear. The canny is trying to highlight that even with Media autoplay disabled, it will still load the static image. Unchecking Allow inworld scripts to play media, unchecking play media attached to other avatars, and enabling media filter - all still do not stop the prim from loading the url with the static image. However, these settings do prevent a youtube url or a url to a mp3 from auto playing. The purpose of the canny is to fix the behaviour to make it consistent - to have Media autoplay when disabled, disable ANY media type from being autoplayed/load that is referenced in the url in the texture/media settings.

--------------------------------

 

Final update:

Created another tracking pixel on Paste Pixel. This time I paid more attention to timing. I created a new prim, and configured the url in Texture/media on the top face of the prim. Checked the Paste Pixel console - confirmed it logged connections. Took the prim into inventory. Dragged it to the ground. Checked the console and did not get any new logged connections.

Media autoplay = disabled does not apply when you're creating the prim. You'll do a connection as it previews the url in the edit menu. Then when you close the edit menu, I think it creates a second connection as in my log for this new pixel I created for this test I see multiple connections that all occurred during the time I was creating the prim. All these connections are my own IP as I'd expect.

So at least now I cannot reproduce the MOAP autoplaying on rez with Media autoplay set to disabled.

I had created several tracking pixels over time to test this, and they are full of connection logs. For my own IP in those logs, I'm now thinking these are connections created during the creation of the prim as I saw in my last test. For the IP entries of other people, I'm now not confident that when I asked the other users to confirm if they had Media autoplay disabled, that it was actually disabled for the test.

I will update the canny with this information so it can be closed by LL.

I appreciate everyone who took time to consider the issue I was presenting. I did do this in good faith, but I now see I made mistakes testing this and came to the wrong conclusion about what was happening. 

 

Edited August 16 by nu11value
Trying to make it clearer that Media autoplay is already disabled.

[Midnoot]

16 minutes ago, nu11value said:

I think most people are aware that Media in SL when it connects to servers outside SL can give away your IP address as the foreign server needs to know your IP address in order to stream you the content. This is a trade off in security we accept when we wish to enjoy this content. In preferences -> sound and media -> Media autoplay can be set to disabled, which then allows us to use the media controls in the top right of the viewer to turn on media when we want and are in a region we trust.

With media autoplay set to disabled, I was experimenting with the media tab in the texture section of a prim - Media on a prim. I added a url to a youtube video, took the prim into inventory and then rezzed it out. Confirmed it didn't autoplay. I had to touch the face I configured for media for it to play. I repeated this with a url to a mp3 file. Same result. So far so good.

But then I wanted to see how it would work with a url to a PNG file. This time when I rezzed out the prim, the media configured face displayed the PNG. I then decided to take it a step further. I changed the url to a tracking pixel png file. Again, worked as I rezzed out of my inventory. Checking the tracking pixel website, I did get the IP info for myself and the other avatars in the region. The tracking pixel also gives you web client and system info. So which web browser is configured with your second life viewer and the operating system.

I have submitted the information to security@lindenlab.com and was told this how media on a prim works. I tried a support ticket after I discovered an attack hud on marketplace that claims to be able to get IP address / system information of other users. I was told this not this wasn't something concierge handled - it was a security matter. So, they couldn't help look into the product available on marketplace.

So now I'm trying to submit this as a bug to Canny. I'm making this post to spread awareness of what I think is a security risk for other users who would not be able to stop a person from getting their IP address if they are in the same region. Also hoping people will upvote the canny if they agree this could be a bug. I think the expected behaviour of disabling media autoplay is that it would be consistent with disabling autoplay to any url - it would not render a static image (a png file) in the same way it won't autoplay a youtube link or link to an mp3 file.

https://feedback.secondlife.com/bug-reports/p/disabling-media-autoplay-doesnt-stop-static-images-allows-for-tracking-pixels-an

This is why many people don't enable media in second life . I hate when someone says " enable media to watch my prim . ". Sus af. 🧐

 

It's the same for voice chat btw. Sadly .

Edited August 15 by Midnoot

[belindacarson]

14 years too late.

 

Google redzone

[Kalegthepsionicist]

and ..so what if they track your ip ?

this funny,

LL can track your ip, and they operate by human too that possibly the staff play sl also 😅

Edited August 15 by Kalegthepsionicist

[Ceka Cianci]

This is why some viewers have media filters for music streaming and media.

[Kalegthepsionicist]

 

best place not to get tracked

[AmeliaJ08]

It's unavoidable, media on a prim is just a stripped back web browser that can render on the face of a prim.

It's no big deal, an IP address isn't of much use to any third party.

[Gabriele Graves]

I think this is avoidable.  I voted for the issue because the viewer should not even fetch the web page unless the user clicked the object when autoplay is off.  Obviously you can turn off MOAP completely but for people who want to selectively choose what they allow, this would be a good thing and probably expected behaviour from most users.  The feature is called "Media On A Prim" and the autoplay feature is called "Media Autoplay" so it does suggest it would cover all the media (or website) on the prim, not just things like video.

Edited August 15 by Gabriele Graves

[PheebyKatz]

11 hours ago, Kalegthepsionicist said:

 

best place not to get tracked

Not if YOU found it so easy, eh?

Seriously though, everything we access online accesses/records IP addresses. It's how we connect to the internet. I used to run an image hosting site (sort of like Photobucket), and if people had any idea how much of their personal information I was able to access via their records of using the site, well, let's just say they'd have been way more careful about what they were uploading to it. It's easy to harvest data, even from their clipboard. Legally, no less.

For what it's worth, I myself only ever used said information in "bad" ways if they were a doosh to me online first. These days, I just tell them I think they're an idiot and let it go.

 

Edited August 15 by PheebyKatz

[Qie Niangao]

1 hour ago, Gabriele Graves said:

the viewer should not even fetch the web page unless the user clicked the object when autoplay is off

I wonder if you might try it yourself if you haven't. I cannot get it to do what that Canny feedback report says it does. I tried it this morning (based on an earlier version of the OP) with just a regular random png, and after setting the MoaP image URL, taking the object, and re-rezzing it from Inventory, it did not load in my (Alchemy) viewer nor my alt's (Linden) viewer, both with media auto-load disabled.

So I just now tried it again with a tracking pixel site (iplogger.org rather than the pastepixel in the Canny report which seems to disable registrations now) so I could monitor all loading events, and again it loaded only during setup, not after rezzing from Inventory. To make sure it was updating after a few minutes I had my alt touch the MoaP surface to manually load it, and indeed that specific delayed loading appeared in the tracking record, not before.

This seems to be the way it should work, unless I'm missing something. I might be convinced to try it with Firestorm but it might work better if somebody accustomed to that viewer's media settings tried to replicate there.

[Gabriele Graves]

2 hours ago, Qie Niangao said:

I wonder if you might try it yourself if you haven't. I cannot get it to do what that Canny feedback report says it does. I tried it this morning (based on an earlier version of the OP) with just a regular random png, and after setting the MoaP image URL, taking the object, and re-rezzing it from Inventory, it did not load in my (Alchemy) viewer nor my alt's (Linden) viewer, both with media auto-load disabled.

So I just now tried it again with a tracking pixel site (iplogger.org rather than the pastepixel in the Canny report which seems to disable registrations now) so I could monitor all loading events, and again it loaded only during setup, not after rezzing from Inventory. To make sure it was updating after a few minutes I had my alt touch the MoaP surface to manually load it, and indeed that specific delayed loading appeared in the tracking record, not before.

This seems to be the way it should work, unless I'm missing something. I might be convinced to try it with Firestorm but it might work better if somebody accustomed to that viewer's media settings tried to replicate there.

Admittedly, I haven't had opportunity today and I did trust that the reporting was accurate.  I will try later when I am able and report back here with my findings.  I'll only be able to check with FS though.

Update: No need to try this out now.

Edited August 15 by Gabriele Graves

[nu11value]

31 minutes ago, Qie Niangao said:

I wonder if you might try it yourself if you haven't. I cannot get it to do what that Canny feedback report says it does. I tried it this morning (based on an earlier version of the OP) with just a regular random png, and after setting the MoaP image URL, taking the object, and re-rezzing it from Inventory, it did not load in my (Alchemy) viewer nor my alt's (Linden) viewer, both with media auto-load disabled.

So I just now tried it again with a tracking pixel site (iplogger.org rather than the pastepixel in the Canny report which seems to disable registrations now) so I could monitor all loading events, and again it loaded only during setup, not after rezzing from Inventory. To make sure it was updating after a few minutes I had my alt touch the MoaP surface to manually load it, and indeed that specific delayed loading appeared in the tracking record, not before.

This seems to be the way it should work, unless I'm missing something. I might be convinced to try it with Firestorm but it might work better if somebody accustomed to that viewer's media settings tried to replicate there.

I appreciate you trying to reproduce this in Alchemy and the official viewer. I'm on Linux so I couldn't try this in the official viewer, but I can try Alchemy, so i'll try that.

I originally tested this in Weapons Test sandbox, and noticed that after a few tries (rezzing the object from inventory) it stopped working. So, I moved sandboxes and it would work intermittently. I find it worked most reliably at my Linden home. 

So, I agree I have seen it not happen on rez, but my experience has been that it works more than it doesn't work, which was why I am trying to bring some attention to it.

I'll screen record my next attempt to at least help to be clearer about the steps I'm doing to help others test/try to reproduce this for themselves.

 

[nu11value]

2 Updates:

Security@lindenlab.com emailed me that QA is trying to reproduce this on the official viewer.

I am trying this again at my Linden home where I've seen it work the most. I now cannot reproduce it with a Pastepixel url. This is on Linux with latest version of Firestorm and repeated the test with Alchemy.  

I mistakenly blacklisted my own IP in the Pastepixel console, so when I cleared the blacklist, my multiple tries showed up in the console. It's a trial account, so I've gone over the amount I can do today. So, I'll test this again later.

Edited August 15 by nu11value
Update: Blacklist

[Gabriele Graves]

I've removed my vote as there is clearly inconsistency of behaviour about this.  Seems like it could just be a plain bug rather than how it's supposed to work.  If QA are on it, then that's good enough for me.

Edited August 15 by Gabriele Graves

[lovestofu]

11 hours ago, AmeliaJ08 said:

It's no big deal, an IP address isn't of much use to any third party.

An IP address, linked with other data points about an individual, can reveal significantly more information about that individual than one might think.  For most users of Second Life, who are normal people who live ordinary lives, this is not an issue as the volume of users makes them unlikely targets.  To individuals who might be interesting to motivated attackers due to social or political influence, access to information, or substantial means, this potentially becomes a serious risk.

It is false to say "any" third-party would not find IP address information to be useful.

[Kore Jardberg]

18 hours ago, nu11value said:

I think most people are aware that Media in SL when it connects to servers outside SL can give away your IP address as the foreign server needs to know your IP address in order to stream you the content. This is a trade off in security we accept when we wish to enjoy this content. In preferences -> sound and media -> Media autoplay can be set to disabled, which then allows us to use the media controls in the top right of the viewer to turn on media when we want and are in a region we trust.

With media autoplay set to disabled, I was experimenting with the media tab in the texture section of a prim - Media on a prim. I added a url to a youtube video, took the prim into inventory and then rezzed it out. Confirmed it didn't autoplay. I had to touch the face I configured for media for it to play. I repeated this with a url to a mp3 file. Same result. So far so good.

But then I wanted to see how it would work with a url to a PNG file. This time when I rezzed out the prim, the media configured face displayed the PNG. I then decided to take it a step further. I changed the url to a tracking pixel png file. Again, worked as I rezzed out of my inventory. Checking the tracking pixel website, I did get the IP info for myself and the other avatars in the region. The tracking pixel also gives you web client and system info. So which web browser is configured with your second life viewer and the operating system.

I have submitted the information to security@lindenlab.com and was told this how media on a prim works. I tried a support ticket after I discovered an attack hud on marketplace that claims to be able to get IP address / system information of other users. I was told this wasn't something concierge handled - it was a security matter. So, they couldn't help look into the product available on marketplace.

So now I'm trying to submit this as a bug to Canny. I'm making this post to spread awareness of what I think is a security risk for other users who would not be able to stop a person from getting their IP address if they are in the same region. Also hoping people will upvote the canny if they agree this could be a bug. I think the expected behaviour of disabling media autoplay is that it would be consistent with disabling autoplay to any url - it would not render a static image (a png file) in the same way it won't autoplay a youtube link or link to an mp3 file.

https://feedback.secondlife.com/bug-reports/p/disabling-media-autoplay-doesnt-stop-static-images-allows-for-tracking-pixels-an

Edit: Just want to make it extra clear. The canny is trying to highlight that even with Media autoplay disabled, it will still load the static image. Unchecking Allow inworld scripts to play media, unchecking play media attached to other avatars, and enabling media filter - all still do not stop the prim from loading the url with the static image. However, these settings do prevent a youtube url or a url to a mp3 from auto playing. The purpose of the canny is to fix the behaviour to make it consistent - to have Media autoplay when disabled, disable ANY media type from being autoplayed/load that is referenced in the url in the texture/media settings.

 

Thanks for mentioning this, this is indeed a serious concern. Upvoting this on Canny.

[nu11value]

Final update:

Created another tracking pixel on Paste Pixel. This time I paid more attention to timing. I created a new prim, and configured the url in Texture/media on the top face of the prim. Checked the Paste Pixel console - confirmed it logged connections. Took the prim into inventory. Dragged it to the ground. Checked the console and did not get any new logged connections.

Media autoplay = disabled does not apply when you're creating the prim. You'll do a connection as it previews the url in the edit menu. Then when you close the edit menu, I think it creates a second connection as in my log for this new pixel I created for this test I see multiple connections that all occurred during the time I was creating the prim. All these connections are my own IP as I'd expect.

So at least now I cannot reproduce the MOAP autoplaying on rez with Media autoplay set to disabled.

I had created several tracking pixels over time to test this, and they are full of connection logs. For my own IP in those logs, I'm now thinking these are connections created during the creation of the prim as I saw in my last test. For the IP entries of other people, I'm now not confident that when I asked the other users to confirm if they had Media autoplay disabled, that it was actually disabled for the test.

I will update the canny with this information so it can be closed by LL.

I appreciate everyone who took time to consider the issue I was presenting. I did do this in good faith, but I now see I made mistakes testing this and came to the wrong conclusion about what was happening. 

[Starberry Passion]

Sorry, I'm not understand this.

Second life is one big social multimedia platform. If you are using the built in browser, you're connected to the browser you use, mostly, but inside of second life. If you are playing a movie, you're watching youtube or something you're using Flash and or Javascript. Not to mention, you need wifi or a landline to even log into second life. You're, also, on a website from Second life, Linden Lab and this site uses cookies.

You're connected to a server while on a network

If you click a link, you're clicking outside of second life, you just used Media still, so you're still using Media

but it is up to the company or place of business to protect your info. How do you think you get IP banned?

Basically, your IP address is already gotten but isn't shared, as long as the companies are protecting your info, as long as you are using their product.

[Scylla Rhiadra]

18 minutes ago, Starberry Passion said:

Sorry, I'm not understand this.

Second life is one big social multimedia platform. If you are using the built in browser, you're connected to the browser you use, mostly, but inside of second life. If you are playing a movie, you're watching youtube or something you're using Flash and or Javascript. Not to mention, you need wifi or a landline to even log into second life. You're, also, on a website from Second life, Linden Lab and this site uses cookies.

You're connected to a server while on a network

If you click a link, you're clicking outside of second life, you just used Media still, so you're still using Media

but it is up to the company or place of business to protect your info. How do you think you get IP banned?

Basically, your IP address is already gotten but isn't shared, as long as the companies are protecting your info, as long as you are using their product.

It appears that the OP's concerns (that a tracking pixel could evade disabling media) are unfounded, but in SL, your IP address is and always has been vulnerable if you enable media. In the simplest case, when you listen to a stream in-world, whoever is running the stream has access to your IP, and not just LL.

That, as many people will insist, is not necessarily a big deal, but it has been used in the past (most notably by a security and alt-identifying system called RedZone) for rather sinister purposes. That's why many people disable media by default, and only turn it on (if at all) if they want it for some reason.

[Gabriele Graves]

It's the association between the IP address and the account id that's mainly the issue for so called "alt" detection.  For parcel radio, it can be hit and miss for the owner to associate these correctly due to multiple avatars turning up at the same time and some not playing the stream for example.  However, it can be 100% reliable for MOAP if the person setting it up makes it send your account id along to the server as it plays.

Edited August 16 by Gabriele Graves

[Prokofy Neva]

On 8/15/2024 at 2:08 AM, nu11value said:

I think most people are aware that Media in SL when it connects to servers outside SL can give away your IP address as the foreign server needs to know your IP address in order to stream you the content. This is a trade off in security we accept when we wish to enjoy this content. In preferences -> sound and media -> Media autoplay can be set to disabled, which then allows us to use the media controls in the top right of the viewer to turn on media when we want and are in a region we trust.

With media autoplay set to disabled, I was experimenting with the media tab in the texture section of a prim - Media on a prim. I added a url to a youtube video, took the prim into inventory and then rezzed it out. Confirmed it didn't autoplay. I had to touch the face I configured for media for it to play. I repeated this with a url to a mp3 file. Same result. So far so good.

But then I wanted to see how it would work with a url to a PNG file. This time when I rezzed out the prim, the media configured face displayed the PNG. I then decided to take it a step further. I changed the url to a tracking pixel png file. Again, worked as I rezzed out of my inventory. Checking the tracking pixel website, I did get the IP info for myself and the other avatars in the region. The tracking pixel also gives you web client and system info. So which web browser is configured with your second life viewer and the operating system.

I have submitted the information to security@lindenlab.com and was told this how media on a prim works. I tried a support ticket after I discovered an attack hud on marketplace that claims to be able to get IP address / system information of other users. I was told this wasn't something concierge handled - it was a security matter. So, they couldn't help look into the product available on marketplace.

So now I'm trying to submit this as a bug to Canny. I'm making this post to spread awareness of what I think is a security risk for other users who would not be able to stop a person from getting their IP address if they are in the same region. Also hoping people will upvote the canny if they agree this could be a bug. I think the expected behaviour of disabling media autoplay is that it would be consistent with disabling autoplay to any url - it would not render a static image (a png file) in the same way it won't autoplay a youtube link or link to an mp3 file.

https://feedback.secondlife.com/bug-reports/p/disabling-media-autoplay-doesnt-stop-static-images-allows-for-tracking-pixels-an

Edit: Just want to make it extra clear. The canny is trying to highlight that even with Media autoplay disabled, it will still load the static image. Unchecking Allow inworld scripts to play media, unchecking play media attached to other avatars, and enabling media filter - all still do not stop the prim from loading the url with the static image. However, these settings do prevent a youtube url or a url to a mp3 from auto playing. The purpose of the canny is to fix the behaviour to make it consistent - to have Media autoplay when disabled, disable ANY media type from being autoplayed/load that is referenced in the url in the texture/media settings.

--------------------------------

 

Final update:

Created another tracking pixel on Paste Pixel. This time I paid more attention to timing. I created a new prim, and configured the url in Texture/media on the top face of the prim. Checked the Paste Pixel console - confirmed it logged connections. Took the prim into inventory. Dragged it to the ground. Checked the console and did not get any new logged connections.

Media autoplay = disabled does not apply when you're creating the prim. You'll do a connection as it previews the url in the edit menu. Then when you close the edit menu, I think it creates a second connection as in my log for this new pixel I created for this test I see multiple connections that all occurred during the time I was creating the prim. All these connections are my own IP as I'd expect.

So at least now I cannot reproduce the MOAP autoplaying on rez with Media autoplay set to disabled.

I had created several tracking pixels over time to test this, and they are full of connection logs. For my own IP in those logs, I'm now thinking these are connections created during the creation of the prim as I saw in my last test. For the IP entries of other people, I'm now not confident that when I asked the other users to confirm if they had Media autoplay disabled, that it was actually disabled for the test.

I will update the canny with this information so it can be closed by LL.

I appreciate everyone who took time to consider the issue I was presenting. I did do this in good faith, but I now see I made mistakes testing this and came to the wrong conclusion about what was happening. 

 

This is an old story, and good luck with getting LL to do anything.

To be sure, they did add a feature on the regular SL viewer -- not sure if it is on the FS viewer -- that lets you enable  MOAP for your parcel only. This is chiefly useful for preventing the sound of media carrying to other parcels, which it will do with MOAP until you figure out how to find and block it.

I don't think it cures the privacy issue. MOAP can't grab your URL per se.

But anyone flying/walking over your parcel, if you have a Shoutcast server on, is giving their URL to the Shoutcast server renter/host. Indeed, this is an old trick to get people to expose their alts, invite them to a parcel using your shoutcast. Shoutcast is legal and is not Red Zone. 

I think the autoplay issue -- also an old story which I personally have tried to get Moles/Lindens to look at -- has more to do with YouTube itself and its tendency not to obey your selection of "turn off autoplay" than LL per se. That is, they may be stuck with YouTube's code.

Edited August 16 by Prokofy Neva

[Love Zhaoying]

I wonder what percentage of users both: 

a) Do not use a VPN b) AND use STATIC IP addresses?

The IP address reported would only be "potentially" accurate if both are true. 

With a VPN, nobody can see your "actual" IP address.

With non-static IP addresses, your "actual" IP address can change at any time.  

 

Edited August 16 by Love Zhaoying

[Ceka Cianci]

5 hours ago, Scylla Rhiadra said:

It appears that the OP's concerns (that a tracking pixel could evade disabling media) are unfounded, but in SL, your IP address is and always has been vulnerable if you enable media. In the simplest case, when you listen to a stream in-world, whoever is running the stream has access to your IP, and not just LL.

That, as many people will insist, is not necessarily a big deal, but it has been used in the past (most notably by a security and alt-identifying system called RedZone) for rather sinister purposes. That's why many people disable media by default, and only turn it on (if at all) if they want it for some reason.

How redzone worked was..

When you entered a region with redzone, it detected a new users entering.. Then redzone had you load a media texture on a prim, which would lead your connection to a couple of websites.

Then it logged you accessing those sites, just like anytime we access anything outside of SL, through our viewer.. Then through scripts and so on it would match  the connection up with the avatar/connection making the request.

So they would log your IP, your viewer and account name. But only if media was turned on.  Then that information was in the database..

Then if it seen the same information show up again from a different avatar, anywhere on the grid that there was a redzone being used.. It made a match.

Once you were in the database, the system could just use your name/names, even if media was turned off, to keep you out of any sims with redzome if you were network banned.

But never having media on and being on an alt that was never detected, they couldn't get your alt if they had your main already in the system.

The scary thing was, they were working on a mobile version that someone could wear a hud or even have a bot or an object use to comb the grid.. But fortunately for the grid, Redzone  got busted after enough pressure from the user base.

Edited August 16 by Ceka Cianci

[Gabriele Graves]

7 hours ago, Love Zhaoying said:

I wonder what percentage of users both: 

a) Do not use a VPN b) AND use STATIC IP addresses?

The IP address reported would only be "potentially" accurate if both are true. 

With a VPN, nobody can see your "actual" IP address.

With non-static IP addresses, your "actual" IP address can change at any time.  

 

Yes correct, you even forgot one, CGNAT where everyone from that ISP has the same IP address (it's currently popular here in NZ from the lower cost ISPs).

However, in my post, I wasn't referring to correctly identifying your home connection IP Address but to the ability of the region owner to reliably associate your currently exposed IP Address to your account id at that time.  Whether or not that IP address was useful for identifying your account id later is a different discussion.

[Love Zhaoying]

32 minutes ago, Gabriele Graves said:

Yes correct, you even forgot one, CGNAT where everyone from that ISP has the same IP address (it's currently popular here in NZ from the lower cost ISPs).

TIL!

32 minutes ago, Gabriele Graves said:

However, in my post, I wasn't referring to correctly identifying your home connection IP Address but to the ability of the region owner to reliably associate your currently exposed IP Address to your account id at that time.  Whether or not that IP address was useful for identifying your account id later is a different discussion.

Point taken, I think you get my point also that "IP Addresses are much more irrelevant than they used to be" for the reasons I gave plus, for example, your "CGNAT" addition.