Allowing tainted data in to the dataset means every single client has to do every single spot of content rendering correctly or else be vulnerable to easy hacking. Keeping it out of the dataset means not all clients have to be perfect for Lemmy to be a secure place.
I’m a fan of the swiss cheese model of safety. While blindly blocking arbitrary characters is a bit silly, not filtering/encoding the data even on the output from web services can end up in disaster.
It’s an open API that serves publicly-sourced data. I’d not want to serve up anything more than markup content even if every single API call had perfect handling. At least not without a lot more sophisticated filtering in front of it. Even certain totally valid arrangements of HTML can be vulnerable as all hell.
Even certain markup systems have problems, but I doubt this one has huge vulnerabilities to exploit. Certain wiki systems in the past had to be completely retired over such things.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
Could have done it with proper encoding, don’t need to remove it lol o.O
Allowing tainted data in to the dataset means every single client has to do every single spot of content rendering correctly or else be vulnerable to easy hacking. Keeping it out of the dataset means not all clients have to be perfect for Lemmy to be a secure place.
The point of encoding, the process of representing data in a different way, is to have the data set not be tainted. :)
Here, for example: https://www.w3schools.com/html/html_entities.asp
I’m a fan of the swiss cheese model of safety. While blindly blocking arbitrary characters is a bit silly, not filtering/encoding the data even on the output from web services can end up in disaster.
It’s an open API that serves publicly-sourced data. I’d not want to serve up anything more than markup content even if every single API call had perfect handling. At least not without a lot more sophisticated filtering in front of it. Even certain totally valid arrangements of HTML can be vulnerable as all hell.
Even certain markup systems have problems, but I doubt this one has huge vulnerabilities to exploit. Certain wiki systems in the past had to be completely retired over such things.