It's worthwhile to expand on a point to @devnull that I made: "preventing the sending server from seeing the IP" is a mostly* BS justification for local caching of media.
Broadly speaking:
Inconsistency around security policies is a recipe for dramatic, consequential failures.
Users are not notified if this is a feature, and clients and servers can both override it.
For a policy of "preventing the origin server from seeing IP addresses by default" to work it requires that it be validated that they can't see it under multiple contexts and for leaks of this information to be treated as security bugs.
But it isn't baked into the protocol, it isn't an advertised feature of mastodon where I can find security issues on that information leaking, redirects aren't put into place on all links or other things that might leak that information.
This means that it is not treated as a globally important issue, it is (largely) only applied to media. Which has other threat surfaces (such as the storage and spread of CSAM and increasing hosting fees for groups by regularly sharing large media files) that need to be weighed and considered when implementing such a policy.
If this is a feature that a user desires for security or safety, it cannot be guaranteed by the ecosystem.
Clients can violate it, servers can violate it, and neither will inform the user of this.
Mastodon's behavior is different from misskey's behavior is different from honk's behavior, but the same clients (mostly) connect to them, and the details of that implementation are abstracted from the user.
Then it's not an advertised feature of clients to only use these.
Not only that, some servers (some Misskey forks) offer the ability for admins to switch this behavior without informing the user.
This is catastrophic from a security standpoint if the actual goal is to prevent leaking of this information.
So not only do we lack consistency around this (c.f., (1)) we lack the option for users to make meaningful and informed choices about what is happening
Mastodon manifests the behavior, but the ecosystem doesn't across multiple moving parts
(3) Your IP address is a (mostly) public reference already and you share it every time you load a webpage.
All it takes is for someone to hotlink an image so that a client will load it as a favor to the user (whether any do this today is not relevant, so please don't provide examples either way), and you are done. Or so that a user clicks on the link and the information is captured.
That doesn't mean it isn't important to obscure it in certain contexts or for some people, but…
…but it does mean that if this is a feature that an individual user wants they should probably be questioning whether any fediverse software is right for them (depending on their threat model, because the lack of wipeout and blind key rotation in multiple servers would be a huge problem for many who would want to obscure their IP).
They also likely need to be taking affirmative steps to obscure their IP. Minimally a VPN or an anonymizing proxy, possibly Tor.
There are some exceptions to not wanting this revealed that don't fall under the "you should use Tor," but a) I suspect these are less common than they are made out to be b) there are better solutions than "caching all media in s3"
For (a) one of the biggest ones that comes up are things like "tracking pixels" that were/are popular by some spammers. This is a legitimately difficult problem (https://en.wikipedia.org/wiki/Spy_pixel) but caching media is neither necessary nor sufficient to stop it
Another is you can provide a caching endpoint for your users, send links from the web there by default with an opt-out, and expose the endpoint for clients. Incomplete, but it lets users opt in personally and select for clients that will respect that setting.
Caches at that level are transient, not stored in S3 for long-term storage
This is not to say that there are never circumstances where you want to hide your IP.
It's just that if that's a feature we want in the fediverse, S3 media caching is a very expensive solution to 1% of the problem, with a lot of other hidden costs and considerations to deal with.
If you want that, we need to have a much deeper conversation about what it means to provide that obfuscation and you should probably be using Tor, at a minimum.
(addendum to have a post to reference for reply-guys)
This is not to say that there may not be other reasons to use media caching, but we should use those justifications (and I have arguments to make there as well, but it's a separable discussion and more about "is this the correct tool" rather than "this is not doing what you want")
We do an annoying amount of post-hoc justifications in the fediverse where an actual reason for something is obscured while another reason is presented
Add comment