Ask Lemmy

Because then you need to take care everywhere to decode it as needed and also make sure you never double-encode it.

For example, do other servers receive it pre-encoded? What if the remote instance doesn't do that, how do you ensure what other instances send you is already encoded correctly? Do you just encode whatever you receive, at risk of double encoding it? And generally, what about use cases where you don't need it, like mobile apps?

Data should be transformed where it needs it, otherwise you always add risks of messing it up, which is exactly what we're seeing. That encoding is reversible, but then it's hard to know how many times it may have been encoded. For example, if I type & which is already an entity, do you detect that and decode it even though I never intended to because I'm posting an HTML snippet?

Right now it's so broken that if you edit a post, you get an editor... with escaped HTML entities. What happens if you save your post after that? It's double encoded! Now everyone and every app has to make sure to decode HTML entities and it leads to more bugs.

There is exactly one place where it needs to encode, and that's in web clients, more precisely, when it's being displayed as HTML. That's where it should be encoded. Mobile apps don't care they don't even render HTML to begin with. Bots and most things using the API don't care. They shouldn't have to care because it may be rendered as HTML somewhere. It just creates more bugs and more work for pretty much everyone involved. It sucks.

Now we have an even worse problem is that we don't know what post is encoded which way, so once 0.19 rolls out and there's version mismatches it's going to be a shitshow and may very well lead to another XSS incident.

Sorry for the late reply, but the point is that there is no trivial way to detect whether and how many times something has been encoded. You may end up with multiple levels of encoding in multiple systems and everything becomes untractable. Morever, as i said this doesn't have to be a problem, as you can just decode everything as much as you can BEFORE you put it in the db, as the db can handle all of that by itself. Just let it do its job. Paradoxically, if you use only channels that support utf8 and don't apply any transformation, your data is already perfect as it is. Then it is the job of the client to do what it needs to be able to render properly, but for instance a non-html client shouldn't need to use html libraries to be able to strip html stuff from the text before it can be displayed.