ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
Considerations for loading client-provided URLs (such as images)
Every time a new client feature comes up that involves automatically loading images/URLs supplied by other clients, we get into this discussion about privacy/security vs convenience. As a result of that, whatever spec it is has to go through lots of back-and-forth that gets repeated for every similar sort of spec that gets suggested.
Maybe having a short considerations document we can link to that goes over some of the privacy/security/convenience arguments and some options for client authors on how to handle it would be useful in preventing those arguments going forward? Things like, if you're implementing a feature that automatically loads image URLs supplied by other clients, you may wish to provide the ability to enable/disable this feature, or only loading the given URL when users <click on it, do something else to trigger the loading of it, etc>.
This might, strictly speaking, be a bit outside the scope of the WG but it relates pretty directly to us actually getting specs written. If there was some document like that we could point to as basically implementation/security considerations concerning loading client-provided URLs then I'd feel more okay about going forward with those specs that involve them.
Just gonna summarize some strategies here. Note that this isn't exhaustive, just that it covers everything I can think of.
Arbitrary URLs
- Pros:
- Network doesn't have to host files
- No extra storage necessary
- GDPR (and similar) compliant
- Doesn't have to be static content
- No extra message processing necessary
- Network doesn't have to host files
- Cons:
- Hosting server will have user's IP address, possibly other info
- Users need to rely on another host for their files
Proxied URLs
For example, https://example.com/?url=http://original.url
- Pros:
- Doesn't REQUIRE storage
- Same pros as unaltered URLs in this case
- Network could cache data if desired
- User's info won't leak to random servers
- URLs are automatically trustworthy for most applications
- Doesn't REQUIRE storage
- Cons:
- May require additional scrutiny for GDPR (and similar) compliance
- Requires additional software installed on servers (httpd, etc)
- Users still require their own hosts
- Requires additional message processing by servers
Network file hosting
Expose some endpoint to clients to enable users to upload files directly to network servers.
- Pros:
- User info doesn't leak to third parties
- URLs are automatically trustworthy for most applications
- Clients could support this automatically
- Cons:
- Requires more work for GDPR (and similar) compliance
- Requires additional software installed on servers (httpd, etc)
- Servers must filter out all other URLs where appropriate
Domain Whitelisting/Blacklisting
Only allow URLs with specific domains.
- Pros:
- Minimal processing in many cases
- Doesn't have to be static content
- Easy GDPR (and similar) compliance
- Cons:
- May require extra client support, as the contents of whitelists would need to be passed to clients
- Users still require their own hosts
In my opinion, none of these strategies will be a one-size-fits-all solution and support for most of them may need to exist in software. The safer options require much more work that may be unnecessary for small community networks, while the simpler options would be unreasonable for large networks.
I am strongly against loading images on IRC. Part of the giant interest in IRC is lightweight, scalable, even with old or weak hardware. It also makes doing flood and abuse protection harder. It also introduces new vectors for attack, such as against a jpg or PNG library.
It's worth noting that images are already loaded on IRC, in most of the web-based graphical clients out there and in some non-web ones. This is more about creating a standard set of considerations so that clients who consider doing so in the future (or implementing features that would require loading client-provided URLs) are aware of the risks, how they weigh up, and the best ways to mitigate any potential risks.
No, most people don't want that [removed] on their IRC experience. Most IRC clients don't support images. Nor should they.
Unfortunately that doesn't change the fact that clients do support images and certain optional features would require this sort of URL loading. Use more professional language on here in future or we may prevent you from contributing.
@GIJack excluding older formats such as KVIrc's avatar support, modern clients such as IRCCloud or Quasseldroid already support avatars, and we're now trying to standardize it to avoid a situation where the clients define the standards and become potentially incompatible.
Ignoring the network aspect, decoding images is unsafe and to be safe has to be done in a sandboxed process (ideally isolated as its own process). Web apps get this for "free" but I am confident not a single desktop client does this safely.
Ignoring the network aspect, decoding images is unsafe and to be safe has to be done in a sandboxed process (ideally isolated as its own process). Web apps get this for "free" but I am confident not a single desktop client does this safely.
though true, this problem isn't unique to this feature. it's an inherent risk to all kinds of new code.
There are a lot of ideas in this repository that essentially boil down to the same sort of discussion, I state this to show the importance of taking a stance on this, and to give my own proposition; Whitelisting arbitrary URLs as discussed earlier is probably the best general solution.
While users will require their own external hosts, I would think there is a way to standardise first-party-support to upload to given hosts (maybe in form of an UPLOAD command with some sub-commands to do this) to make it as seamless as possible (which kind of allows things like network file hosting as well if the network prefers).
I would also suggest handling {white,black}lists by exposing a command such as URL-ALLOWED, or even better, having the server process things by itself and sending something to the client to tell it whether it's allowed or not - with the server having the possibility to not respond, and the clients could interpret it as the default, based on whether its whitelist or blacklist.
An issue I can see with this is that it requires some fairly complex functionality to be put into a real specification, and that it possibly could be too intensive on the servers, if it's decided to move the loading of URLs to the server. But, it is the widest supporting option without many issues (at least, as far as I can see).
