[keyserver] Handle offensive words in invite links
ClosedPublic
Actions

Authored by tomek on Jul 18 2023, 4:14 AM.

Details

Reviewers

kamil
inka
ashoat

Commits

rCOMM9370f91f0482: [keyserver] Handle offensive words in invite links

Summary

Check if an invite link contains abusive words and return an error if that's the case.

https://linear.app/comm/issue/ENG-4181/handle-offensive-abusive-words
https://www.npmjs.com/package/bad-words

Depends on D8494

Test Plan

Tried to create a link consisting of just an offensive word and an error was returned.
Tried to create a link with a string consisting of an offensive word with some prefix - a link was created correctly. This isn't ideal, but handing it correctly might be challenging: e.g. invite/class sounds like a proper link, but simply checking if it contains an offensive substring would forbid it.

Diff Detail

Repository

rCOMM Comm

Branch

invite-error

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

tomek created this revision.Jul 18 2023, 4:14 AM

Harbormaster completed remote builds in B20986: Diff 28771.Jul 18 2023, 4:32 AM

tomek requested review of this revision.Jul 18 2023, 4:32 AM

Can you provide some more context on the selection of this package? I noticed it hasn't been updated in 3 years and has some unaddressed GitHub issues, but I'm guessing your research showed that it's the best option.

tomek added a child revision: D8615: [keyserver][lib] Block users from creating reserved invite links.Jul 25 2023, 3:39 AM

In D8527#251416, @ashoat wrote:

Can you provide some more context on the selection of this package? I noticed it hasn't been updated in 3 years and has some unaddressed GitHub issues, but I'm guessing your research showed that it's the best option.

It is the most popular NPM package for profanity checks https://www.npmjs.com/search?q=keywords%3Aprofanity&ranking=popularity. Also, the issues on Github aren't serious. The implementation is so simple that it doesn't need frequent updates.

tomek edited the summary of this revision. (Show Details)Jul 26 2023, 1:18 AM

Doe this mean that it is possible to create a community with a name that is a swearword in some language, but then we won't be able to create a link that has the name of that community in it? That seems odd

In D8527#253676, @tomek wrote:

In D8527#251416, @ashoat wrote:

Can you provide some more context on the selection of this package? I noticed it hasn't been updated in 3 years and has some unaddressed GitHub issues, but I'm guessing your research showed that it's the best option.

It is the most popular NPM package for profanity checks https://www.npmjs.com/search?q=keywords%3Aprofanity&ranking=popularity. Also, the issues on Github aren't serious. The implementation is so simple that it doesn't need frequent updates.

Thanks for explaining!

In D8527#254082, @inka wrote:

Doe this mean that it is possible to create a community with a name that is a swearword in some language, but then we won't be able to create a link that has the name of that community in it? That seems odd

The name will eventually be encrypted, so we (as Comm) should have no way to ban it. On the other hand, the invite link will use our domain name in the future, so I think it makes sense to add some filtering there.

Can you clarify what will happen on older clients when this endpoint returns a ServerError that they aren't aware of?

EDIT

Looks like on older clients it will display offensive_words directly. But D8494 makes it so if a future keyserver returns an unknown error code to a future client, unknown error will be displayed instead.

This revision is now accepted and ready to land.Jul 27 2023, 6:08 PM

In D8527#254913, @ashoat wrote:

Can you clarify what will happen on older clients when this endpoint returns a ServerError that they aren't aware of?

EDIT

Looks like on older clients it will display offensive_words directly. But D8494 makes it so if a future keyserver returns an unknown error code to a future client, unknown error will be displayed instead.