Start a new topic
Discussions Cohost Cohost Feature Requests

Prevent external image embeds

This is kinda a feature removal request, but I think it can be done without it creating problems.

Right now, a post can contain images hosted on cohost, but it can also include arbitrary images from external sites via use of custom HTML.

There's three problems with this:

  • Privacy: external sites learn the reader's IP address and a handful of details about their web browser. For most people that's no big deal but in rare circumstances that could be used to doxx people, and I'm sure that at least some segment of the site's users would be upset if they found out others are learning their IP address.
  • Bad netiquette! I'm old enough to remember when this was called "hotlinking". If a post on cohost that used external media got really popular, it might cause high bandwidth costs for that external site, which might not have asked for this extra traffic.
  • Mutability, dynamic content, and expiration. The external server is under no obligation to serve the same version of the image to everyone. Though there's undoubtedly cool things you could do with this, it's also ripe for abuse: with some effort, you could craft a post that has a horrible message for a select few people, but completely innocuous content if you're a cohost moderator. You can also use this to change a post after it's been posted (mind you, cohost does have an edit button). The final risk is that the external server goes down and the cohost post becomes unviewable.

Existing posts could either be left alone, or cohost could systematically mirror all external images in existing posts and update the URLs.

For new posts, I suggest only letting images be embeeded from attachments to the same post, or from data: URIs.
3 people like this idea
11 CommentsSorted by Oldest First

While I would love it if Cohost was willing to mirror anything I link, the big problem with this proposal at present is that it means there would be no way whatsoever to display an image larger than 10MB. 

2 people like this

"a post can contain images hosted on cohost"


A post can, but I don't think a comment can? Whereas you show an external image in a comment.

There'd be no way to display it in-line, yeah, but you could link to an external site. Considering the typical size of a cohost post, that doesn't feel very restrictive to me? It only has to be roughly 600x600 pixels, or for high-DPI 1200x1200. I think 10MB is more than enough to get a beautiful image within that space.

you can do in-line images in comments, example: https://cohost.org/dialacina/post/206910-hard-to-top-big-natu#comment-b01e7023-4d9d-48fc-b7c0-b45812e7c756

there have been a number of posts in months past that used dynamic content to create "cohost plays" and widely editable shared boards, so i don't think disabling the ability entirely to source images from off site is a good idea


perhaps a warning when posting, to let people know there's a better way for static images?

3 people like this
Maybe the external media prompt you get for YouTube embeds could be used here too.

Disagree with this because it would prevent people from reposting/linking to images on their own websites, and because cohost's upload limits are (understandably) quite small.

2 people like this

It would also force everyone to only use Cohost's fixed layout and limit of four images or else use the very goofy workaround method to grab the URLs and add them.


That will be ameliorated later when the image UI is improved, but I would still strongly prefer to have the option to embed my photos from flickr when I want to. Not every embed is an illicit hotlink.

This would disable anyone's ability to build anything along the lines of "Cohost Plays Pokemon" again.

4 people like this
Addressing OP's concerns, which I think are all valid but are less grievous than they sound, in order:
  • Privacy: I think this should be easily dealt with by making external embeds be something you have to manually click to load. This goes for all HTML which would cause external assets to be loaded. There's already the option to load content previews with iframely in our user settings, so I don't see why we can't extend that concept to all external content. Also, FWIW, while modern web browsers are definitely not set up for user privacy, most of them can be configured to not load content from third-party domains using something like uBlock Origin.
  • Bad netiquette: site owners can disable requests that are not loaded as part of a request for their own page, so while this might be bad for hobbyists with enough free time to run a site (with user-uploaded content or otherwise) but not enough time to implement such a check, I think in general the web has moved past the era where this was a major problem, even photobucket. In fact, external hosting is critical for people seeking to embed large files without imposing on cohost's own servers. If it's a real problem, then restrict people to only using embeds from well-known domains that definitely will never have the bandwidth issues, as well as from ipfs gateways and the like.
  • Mutability, dynamic content, and expiration: these are kind of two concerns at once, but the first one is something that, in order to avoid detection from cohost moderators, would have to be extremely targeted. It mostly would fall under the realm of harmless pranks (like making an image that's normal art for everyone except for anyone accessing the image from, say, the British Parliament's IP address space, in which case it would show a list of war crimes committed by Britain in Ireland), with the occasional case of true malice, like someone trying to exploit a zero-day vulnerability in a browser loading PNG metadata or something and avoiding immediate mass detection by only serving the malicious payload to a small percent of users (which I guess is actually a good reason to be wary, but would be solved by the same solution as I outlined when talking about privacy concerns.) As for expiration... well, that's the tradeoff that you have to take. If a file is too big to fit on cohost's servers, you have to link to it anyway, so you might as well link it in a way that lets it be part of the content.

One cool thing Github does with its markdown viewer for Readme files and the like is let you embed images from wherever you want, but it silently reuploads them to its CDN and serves those instead. Such a behavior could also be bypassable by not doing that to images that include a question mark serving as a delimiter for parameters (adding a question mark to a static URL is generally supported by all http servers)

Login or Signup to post a comment
More topics in Cohost Feature Requests
See all 728 topics