The Decompartmentalizer

@TresFoyle

grass fed / brain poisoned

she/her

not for children.

The Decompartmentalizer @TresFoyle3/26/2024, 4:56 PM

jane, of score @janederscore

sirocyl @sirocyl3/26/2024, 8:56 AM

small implementation thought: address/3P media privacy

my thought, is to include a flag on the post, alongside CW/18+ post-hiding, for third-party media. See the UI example in the image above.

This is set by the server-side HTML analysis/sanitizer engine whenever any URL is serving content (e.g., image links in CSS, SVG or <img> tags) that doesn't originate from cohost's servers by DNS match.

If there were a way to show/list which third-party servers were in the post content before opening the post, perhaps through a button in the warning header, that'd be even better.

When a post contains third-party content, it is:

hidden by default, doesn't render, doesn't preload assets
gives the same "show post" UI as a CW/18+ post, but with succinct privacy prose about third-party content and the user connecting directly to a third-party server, addresses or whatever
has an option in user settings to expand these automatically; default disabled.

Just to be clear, I'm against the suggestions to disable third-party content outright, including:

completely disable inline content embedding, let alone 3p content (this has been used in the past for extremely cool stuff, and is a big part of what keeps cohost unique)
download and cache or re-serve images from cohost's CDN (this is, for reasons, unsustainable, and also breaks cool things done with off-server images)
require embedded content only source from cohost's CDN - uploading to it is janky and this also breaks "cool stuff"

however, I am positively for an easier way to upload normal images to Cohost to be used, embedded or referenced inline, that doesn't involve writing a dummy draft post.

from a cursory glance at the browser devtools: cohost seems to use a tool called rehype, particularly the rehype-sanitize plugin, to preprocess and sanitize HTML as part of its markdown renderer (if the server stuff is the same shape as the local Webpack assets).

rehype has a plugin called rehype-url-inspector for analyzing and/or transforming URLs in a given input.

Attribution, Icon; Incognito by marwati from Noun Project, CC-BY 3.0.

#cohost meta #feature request

You must log in to comment.

in reply to @sirocyl's post:

ira 🌷🐰@irina3/26/2024, 10:16 AM

it's a neat idea, but i don't think it quite works? any post with a warning like that on it will immediately be opened by almost everyone, so anything actually malicious would bypass it instantly.

it's the same issue as putting a generic "spoiler/nsfw" tag on everything from food to porn to disturbing images, which is common on other sites - people will assume it's benign because 99% of the time, it is, and the 1% it isn't, the warning was useless.

they also have mentioned working on a better way to do more inline images, so hopefully that solves some of the problems

sirocyl @sirocyl3/26/2024, 10:51 AM

I don't disagree, this is an important implementation detail to be worked out.

luna the deer @BappyDeerHooves3/26/2024, 1:15 PM

this is kind of a non-solution to a non-proboem; it makes "your public IP might be public" seem like a much much greater issue than it actually is, and doesn't (and couldn't) give the average user a good explanation for why half of the posts on their feed are now hidden by default

🦁 woxi @wolf-and-ghostling3/26/2024, 1:39 PM

i haven't found many posts in this discussion and don't know when it started and what has been explained. you are very knowledgeable and i am not, and i have some questions if that is okay.

what exactly is the danger of embedded third party images?

your IP is already easily accessible and anyone concerned about privacy would be running the recommended suite of browser addons against tracking and such. maybe a vpn.

would an embedded https://website.com/image.png be able to hold malware that you are automatically infected with? would your browser accessing that domain be exposed to a form of tracking not included above and that would be an actual safety concern?

i host my art separately to add to my portfolio website, so i will frequently embed it on cohost too instead of the draft method. i started interneting at the time when hosting images in a different place was the norm everywhere. i never really thought hotlinked images carried any more risks than your average internet browsing would, which the antivirus should catch and quarantine/cut off your connection to the page it detected a potential threat on. my view on dangers on this topic is probably a little outdated and might've never been complete.

no worries about explaining if it takes too much time / this is a stupid question etc. thank you for your informative post :eggbug-smile-hearts:

ira 🌷🐰@irina3/26/2024, 2:09 PM

what exactly is the danger of embedded third party images?

you cover it pretty well, really. there's not much risk more than general web browsing, and for the comparatively small number of people who need to worry, VPNs and extensions solve the problem almost entirely. (personal bugbear; VPN services have convinced far too many people they "need" a VPN...)

About the most malicious thing you can do is put a hidden "read receipt" tracking pixel to know if a specific user saw your ask, and get their IP, but that IP alone is almost certainly not enough information to track someone effectively.

a warning like this in asks makes some sense, and/or disallow embeds entirely in anonymous asks

🦁 woxi @wolf-and-ghostling3/26/2024, 4:13 PM

thank you. it helps me better understand the issue and if i should be concerned about it at all

sirocyl @sirocyl3/26/2024, 3:20 PM

on cohost, the major risk is correlation of data - having a unique pixel for certain posts, on certain pages, correlating who loads what where.

the other risks are the risks of an IP address leak - a lot of people downplay the severity, but if I was an evil website and I hated cohost users very much, I could put a pixel embed on a post that does Severals, and ban any IP address who has seen said pixel.

there's also the lack of authority cohost itself would have over third party media, which is in some cases a good thing (allows for dynamic/per-session image serving) but can have issues (e.g., serve good image to all users except a list of IP addresses you hate; or, see Referer headers for cohost, and serve evil image to only those users.)

to be clear - I checked with a recent Firefox with the default privacy settings and uBlock Origin, and the only Referer [sic] header sent, points to https://cohost.org/ only, regardless what page or post it's on.

sirocyl @sirocyl3/26/2024, 3:24 PM

this can all probably be summed up as "unintended unique per-user content serving, opportunities for user tracking and data correlation" and that is enough of a privacy risk (and probably so to some legal privacy guidelines too) to warrant a consent filter. though, for people who genuinely don't have a reason to be concerned (and that's probably most people, nowadays) the option should be there in the user settings to always-bypass the click-through.

🦁 woxi @wolf-and-ghostling3/26/2024, 4:16 PM

thank you so much for explaining so in depth. it does not feel like something that would be an issue to me personally here, but it is definitely something to look into and learn more about as a general internet user, especially going forward with how we'd like the web to look post-collapse of the biggest websites.

@vriska3/26/2024, 8:16 PM

i mean the other risk is that its a massive attack surface. like the day cohost launched i emailed them a poc that would crash or hang most browsers that viewed a post and they never did anything abt it afaik (i think chromium and gecko fixed that specific case though?)