search

mastodon / mastodon

Your self-hosted, globally interconnected microblogging community
https://joinmastodon.org
GNU Affero General Public License v3.0
47.04k stars 6.96k forks source link

There are a lot of ways for new or naive users to accidentally leak their IP address to other instances #20545

Open afontenot opened 1 year ago

afontenot commented 1 year ago

Pitch

Mastodon should either improve documentation and give new accounts an active warning before clicking through to other instances, or else change the behavior so that users have to signal an explicit wish to navigate to remote content before we take them there.

Some of the many ways I've managed to leak my IP address in the last week:

  1. When viewing an image in a media post, Mastodon helpfully does all the things I expect. I can view the image. I can click it and view it at full size. I can right click and save the image. All of these things happen without leaking my IP address thanks to Mastodon's proxying. But then, if I right click the image, the first option instead of being "open image in new tab" (what I normally expect for images) is "open link in new tab". That's right, images are inexplicably linked to the image file on the source instance. As far as I know, this isn't even surfaced anywhere in the UI other than creating this footgun. If I click the "open link in new tab", I've leaked my IP to another instance.

  2. When trying to view a user's followers, I see the message "Follows from other servers are not displayed. Browse more on the original profile." I know now why this happens this way. But it's led to a bunch of complaints from users. https://github.com/mastodon/mastodon/issues/20533 I think it would help in onboarding new users if there was some explanation for why this was done. The first time the user clicks on a "browse more", pop up a modal explaining that this will take them to an external site that might have a different privacy policy, might not be trustworthy, won't know about their Mastodon profile, etc.

  3. When a post contains an oembed, the user has to click once to get it to load. This protects the user from sending any data to potentially untrusted sites, and is a great feature of Mastodon (IMO). But it's also led to some user confusion in several issues. https://github.com/mastodon/mastodon/issues/20178#issuecomment-1308053229 Users are not really used to the idea of leaking data via embeds, and I think it would be a good idea to explain to them what will happen when they click the "play" button on an embed - again by presenting them with a modal the first time they click one.

  4. When the home instance isn't able (maybe because of admin policy?) to fetch and cache a remote image, a little notification is placed in the center of the blurhash image preview that says "Not available". If you just take in the UX and don't actively read the text it looks exactly like the "sensitive content" notice that many of us have gotten used to clicking through. However, if you click on this image, you get taken to the original domain in a new tab.

There are probably more ways to leak your IP on Mastodon that I've forgotten. Feel free to add examples in the comments.

Motivation

IP leaking is something Mastodon explicitly tries to guard against through a careful approach to federation. For instance, one reason you can't automatically see all the followers a user on a remote instance has is that fetching the list (in the browser) would require the user to directly connect to the federated server, compromising their privacy.

I think that the intent here is a good one, but this concern for the user's privacy is undermined by the footguns indicated above. If preventing IP leaks is really so important, some steps need to be taken to improve the status quo here. Mastodon shouldn't only protect users who know exactly how Mastodon will handle links to remote instances.

Edit (2022-11-14):

I've added (5), above, a new IP leak method I discovered. I also removed (1), which was fixed. See the linked issue for that.

~1. If you hover over the user name in a post or the permalink (the date / time in the top right corner), you will see that the link element claims it will take you to the user's profile on the original instance, or the post on the original instance (respectively). However, if you click either of these links, you will be redirected to a portal for viewing the page in question through your local instance instead. This is arguably sort of bizarre; probably this the link should show the instance portal page instead. https://github.com/mastodon/mastodon/issues/19967 Instead, the fact that clicking on a post takes you to your instance page creates an important user expectation. This expectation is then violated when they do something like copy the link, or right click --> open in new tab. Without warning, they've leaked their IP to another instance. More discussion here: https://github.com/mastodon/mastodon/issues/19652~

SamStephens commented 1 year ago

Also, because of how federation works, it's not possible to see all replies to a post on a federated instance from your local instance. You can only see them if you got to the home instance of the post, leaking your IP in the process.

SamStephens commented 1 year ago

IP leaking is something Mastodon explicitly tries to guard against through a careful approach to federation.

Is there a reference for this anywhere? A list of Mastodon security principles? Some reasoning behind this position? A thread model? I've failed to find an official position anywhere.

I'm willing to believe that IP leak protection is something worth doing, but IMO it should be justified. Especially since the Federation model already places high levels of trust in remote servers, are users really being put at more risk when they leak their IPs to a remote instance?

mohe2015 commented 1 year ago

I don't know if its useful to advertise this anywhere. then people may actually rely on it and its not only minimizing ip leakage. there will always be bugs so I think something like using Tor is the only safe option.

afontenot commented 1 year ago

Is there a reference for this anywhere? A list of Mastodon security principles? Some reasoning behind this position? A thread model? I've failed to find an official position anywhere.

I'm basing this mostly off comments by Mastodon members and employees and other high profile contributors. I agree that it may not rise to an official position, but the effect is very obvious if you use privacy protecting browser plugins like uMatrix. On Mastodon instances, in contrast to virtually every other site on the Internet, you never see connections to third party servers without signalling the intent to do so. I think that's reflective of the attitude Mastodon contributors have on the subject. Quotes:

It would definitely not be safe, secure, privacy-preserving, or promote a robust, standards-based version of interoperability to directly assume every remote server implements the Mastodon API and then make requests directly to them to expose the user's IP address. If we did choose to implement this, we would need to proxy the request through the local instance server to hide the user's IP, and then have the local instance server transform the ActivityPub-formatted payload into a standard REST format.

Source: https://github.com/mastodon/mastodon/issues/20529#issuecomment-1312589717

Hotlinking would be a privacy risk

Source: https://github.com/mastodon/mastodon/issues/18237#issuecomment-1114418903

as an end-user, when using Mastodon, you don't ever load anything that is not explicitly approved by the instance admin (except for embedded previews, but they are behind a click-through)

Source: https://github.com/mastodon/mastodon/issues/14349#issuecomment-660487529

Especially since the Federation model already places high levels of trust in remote servers, are users really being put at more risk when they leak their IPs to a remote instance?

Does it really? I see the federation model as an attempt to strictly limit the extent to which instances have to trust each other, and Mastodon's attempt to protect user privacy builds on that. What's an example you have in mind?

there will always be bugs so I think something like using Tor is the only safe option.

Advertising this as a blanket feature of Mastodon would be a bad idea, to be sure. Tor is appropriate for anyone who needs to keep their IP concealed no matter what, especially if they need privacy from their own instance admin. This is more about having a consistent attitude towards a best practice, and providing users with some insight into why Mastodon is making the decisions it makes. For example, knowing why I have to click to see embedded media, or why I can't see the full list of followers for a remote account. You can explain that without giving the (false) impression that Mastodon will keep your activity 100% private.

SamStephens commented 1 year ago

@afontenot

I'm basing this mostly off comments by Mastodon members and employees and other high profile contributors. I agree that it may not rise to an official position

My thinking here is that we'd all be better off if it was an official position. Understanding the principles, reasoning and motivation behind Mastodon's privacy and security posture helps us as users to understand the consequences of using the application, and it helps us as contributors to ensure our suggestions for bug fixes, features, and implementations align with said posture.

Especially since the Federation model already places high levels of trust in remote servers, are users really being put at more risk when they leak their IPs to a remote instance? Does it really? I see the federation model as an attempt to strictly limit the extent to which instances have to trust each other, and Mastodon's attempt to protect user privacy builds on that. What's an example you have in mind?

My thinking is that we completely trust remote instances in terms of content they control; we place complete trust in them to be honest about who their users are and what they do.

This is why I like the idea of an official position. Because that's how we understand what kinds of privacy goals Mastodon considers important, why we trust remote servers in some ways, but not others.