316
PSA: We're back, here's a post-mortem!
(beehaw.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Jul 2023
316 points (100.0% liked)
Beehaw Support
2796 readers
6 users here now
Support and meta community for Beehaw. Ask your questions about the community, technical issues, and other such things here.
A brief FAQ for lurkers and new users can be found here.
Our September 2024 financial update is here.
For a refresher on our philosophy, see also What is Beehaw?, The spirit of the rules, and Beehaw is a Community
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
ย
founded 2 years ago
MODERATORS
This is interesting. I actually commented about the use of emojis/emotes a couple days ago on a post on !foss@beehaw.org made by a federated user from lemmy.one, that has since been removed (๐), but I still have the bookmarked comment in which I copied the raw embed for the remote emote image in the federated comment I was responding to.
Do I understand it correctly, that the latest fixes to stop the code injection, will still allow remote image embedding, so something like an "emote picker extension to embed animated GIFs from a remote server and/or remote instance's emoji list" would still be doable and wouldn't pose any risk?
Or would such picker still have to include measures to prevent offering embeds with potential exploits?
Remote image embedding is not the issue, remote custom emojis would not have been an issue either. The issue, from my understanding, is that the way local emojis are rendered allowed for an XSS exploit.
You can look at the PR which fixed this issue if you have a better understanding of these things than me : https://github.com/LemmyNet/lemmy-ui/pull/1897/
I believe such a picker would be fine.
I see, so the prior emoji handling rendered content directly from the comment, instead of making sure it was strictly what was defined for the local emoji; that was a weird choice. Now they've also added a sanitizer wrapper to all of it in: https://github.com/LemmyNet/lemmy-ui/pull/1906
I guess the only downside of a picker that used the non-emoji image renderer, would be the loss of emoji CSS formatting.
From what I can tell the whole point to the css class/formatting was controlling the size of the emojis. Depending on where they came from, I could see some being of random size and shape. Admins might not have the time or know-how to shrink them down, so css seems like a reasonable compromise as long as the files aren't huge.
I'm kind of bothered that the only fix seems to be on the frontend. Unfortunately, I haven't been able to stick with Rust long enough to take a reasonable crack at figuring out how to help on the backend. Input and output sanitization should ideally be handled in both places.
Lemmy's backend is kind of curious, in that it does the bare minimum to move content around and add some metadata fields.
For example, did you know that "deleting" a comment, only marks a "deleted: true" field, while the comment is still pushed in full to the frontend? Same thing happens with banned/mod removed comments, they just get marked as "removed: true" but otherwise still get pushed to the client, and the user can still edit them.
All the display processing is done in the frontend, or whichever app you happen to use.
I can maybe see marking it as deleted in case someone wants to creat undelete functionality later. I don't agree with it, but I can see why someone would do it.
It's just weird to still push it to the frontend.
Same with the removed stuff. All of that should be handled on the backend and never even sent to the frontend. Sometimes the reason for deletion is something you don't want getting grabbed by someone who is bored and poking around in developer tools, like doxxing information.
Since I don't have the time to do anything about it, though, I guess I don't have a place to complain. I have strong feelings about this stuff, but there's a limit to the number of things a single person can work on. If I were to hop on an open source project this minute, it would be helping migrate Cursorless to an LSP.
There is an undelete feature, at least the Liftoff app has it.
Right now, the only effective way to delete a comment, is to edit and blank it, then you can delete it (well, the content, you still get shown as the author). The bright side is that even when the comment gets mod-deleted, you can still edit it... and everyone can still read it in the JSON... wait ๐ค
No need, just view source. In the Liftoff app there is a "nerd stuff" option where you can also read the content.
Anyway, once a comment gets federated, it's out of the original user's control, can really take it back.
Hey, I wanted to thank you for this exchange. I learned a lot about lemmy.
Glad to be of assistance. There's plenty of it I still haven't looked into, though.