a11y: allow aria-label and aria-hidden tags on pre tags

nbsp commented

2022-12-07 17:11:13 +00:00

Contributor

close #153 (ooh an oldie)

would help accessibility a ton, and would let people post ascii art without worrying about messing up people's screenreaders

close #153 (ooh an oldie) would help accessibility a ton, and would let people post ascii art without worrying about messing up people's screenreaders ![post of ascii art with aria-label attribute in it](https://snowdin.town/media/1c7ef1230a1fc1327992ff5de026f42c0cfe68384de743964378eb7b2cb89c76.png)

nbsp added 1 commit 2022-12-07 17:11:13 +00:00

ci/woodpecker/pr/woodpecker Pipeline is pending Details

619920ff8c

Allow aria-label and aria-hidden tags on pre tags

floatingghost commented

2022-12-29 15:37:56 +00:00

Owner

honestly i'm starting to be of the mindset that HTML posting is silly - does anyone actually use it?

honestly i'm starting to be of the mindset that HTML posting is silly - does anyone _actually_ use it?

Ghost commented

2022-12-29 17:59:57 +00:00

First-time contributor

Honestly if most forums/boards out there disallow HTML posting, it's probably for the better for it to be disallowed in the context of interactive social media.

nbsp commented

2022-12-29 23:08:48 +00:00

Author

Contributor

i've seen a few people use it
it allows for some of the mfm things but with a different markup
it doesn't have any security vulns i don't see a reason it should be removed really

i've seen a few people use it it allows for some of the mfm things but with a different markup it doesn't have any security vulns i don't see a reason it should be removed really

Ghost commented

2022-12-29 23:18:21 +00:00

First-time contributor

If you're able to add arbitrary tags like this, then the only thin line protecting you from said vulnerabilities is the HTML sanitiser and a likely XSS waiting to happen because the default Akkoma (seems to be a Pleroma relic) CSP is to allow unsafe-inline CSS, and (what seems to be) allowing unsafe-inline for JavaScript too from a quick search for unsafe-inline, and unsafe-eval (????).

If HTML posting is going to exist, then there needs to be better protections than a single sanitiser. As is, arbitrary HTML posting poses quite a pretty large risk that some instances are already disabling it. A stronger CSP would be a good start, but apparently that breaks MFM which is quite problematic.

If you're able to add arbitrary tags like this, then the only thin line protecting you from said vulnerabilities is the HTML sanitiser and a likely XSS waiting to happen because the default Akkoma (seems to be a Pleroma relic) CSP is to allow unsafe-inline CSS, and (what seems to be) allowing unsafe-inline for JavaScript too from a quick search for `unsafe-inline`, and `unsafe-eval` (????). If HTML posting is going to exist, then there needs to be better protections than a single sanitiser. As is, arbitrary HTML posting poses quite a pretty large risk that some instances are already disabling it. A stronger CSP would be a good start, but apparently that breaks MFM which is quite problematic.

nbsp commented

2022-12-29 23:27:04 +00:00

Author

Contributor

like iunno any instance could already send whatever html it wants and we can't do anything about it except sanitize it
removing it when outgoing is gonna do nothing

like iunno any instance could already send whatever html it wants and we can't do anything about it except sanitize it removing it when outgoing is gonna do nothing

nbsp commented

2022-12-29 23:27:52 +00:00

Author

Contributor

s/could already send/sends, actually
we only deal with the incoming html except with misskey

`s/could already send/sends`, actually we only deal with the incoming html except with misskey

Ghost commented

2022-12-29 23:32:09 +00:00

First-time contributor

As I mentioned above, a strong CSP substantially helps in the event the sanitiser doesn't work to further mitigate the risk of malicious CSS and JavaScript. So yes we actually can do something about it.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Akkoma's (and Pleroma's) current dynamic CSP has mentions of extremely permissive directives like unsafe-inline, unsafe-eval, and data:.

With recent incidents like activitypub-proxy and activitypub-troll, it clearly shows that some security needs to start being taken seriously.

As I mentioned above, a strong CSP substantially helps in the event the sanitiser doesn't work to further mitigate the risk of malicious CSS and JavaScript. So yes we actually can do something about it. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Akkoma's (and Pleroma's) current dynamic CSP has mentions of extremely permissive directives like `unsafe-inline`, `unsafe-eval`, and `data:`. With recent incidents like activitypub-proxy and activitypub-troll, it clearly shows that some security needs to start being taken seriously.

Ghost commented

2022-12-29 23:33:48 +00:00

First-time contributor

If the feature itself poses a risk and very few to anyone is using said feature, there's very little harm in removing this and could signal others to do the same.

It's not any different than when Akkoma recently removed ruffle.js (ruffle.rs).

AkkomaGang/akkoma-fe#263

If the feature itself poses a risk and very few to anyone is using said feature, there's very little harm in removing this and could signal others to do the same. It's not any different than when Akkoma recently removed ruffle.js (ruffle.rs). https://akkoma.dev/AkkomaGang/akkoma-fe/issues/263

nbsp commented

2022-12-30 00:28:19 +00:00

Author

Contributor

does the feature itself pose a risk? from what i understand it's not this html post option being problematic, it's html sanitization in general, both in and out

if few people use it then surely removing it wouldn't reduce the risk

does the feature itself pose a risk? from what i understand it's not *this* html post option being problematic, it's html sanitization *in general*, both in and out if few people use it then surely removing it wouldn't reduce the risk

floatingghost commented

2023-01-02 15:26:17 +00:00

Owner

Akkoma's (and Pleroma's) current dynamic CSP has mentions of extremely permissive directives like unsafe-inline, unsafe-eval, and data:.

thanks for reminding me, i've significantly tightened the CSP in 336d06b2a8

>Akkoma's (and Pleroma's) current dynamic CSP has mentions of extremely permissive directives like unsafe-inline, unsafe-eval, and data:. thanks for reminding me, i've significantly tightened the CSP in https://akkoma.dev/AkkomaGang/akkoma/commit/336d06b2a8ca75362578b1d67ea1f32a45c8edd3

nbsp commented

2023-01-03 07:03:50 +00:00

Author

Contributor

in this case then, does removing html posting really improve anything security wise? it won't get rid of html posts inbound, after all