You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ban certain usernames that could cause confusion or annoyances #880
Hmmmm, but that could could result in a lot of questions about why this and not that? I think we should mainly consider things that could be used in social engineering.
Maybe the blacklist could contain the username not allowed and a reason for why? So that if people try to use that name, they would get a reason behind it?
The list would of course have to be maintained by the POD providers, and they would have different reasons for which usernames they allow and disallow. The base file that we provide with the installation/git repo would contain the names that is disallowed due to obvious misunderstandings (such as www and admin, and perhaps password and user?).
IMO banning common names that could be used for social engineering seems fairly straightforward and reasonable.
The profanity issue is a whole other can of worms.
I am inclined to ignore that sort of thing unless I find it personally offensive. In which case, I would probably consider that to be a troll account and block it on the existing social media platforms.
Maybe we need some kind of Username Alias, Proxy, or Masking mechanism?
It could substitute an undesirable string in a displayed name with asterisks or a completely different name (VulgarPerson12345) based on a POD Providers blacklist?
We should ban www because Google tends to represent www.foo.bar the same as foo.abr in future, which would be a security issue: Someone grabing the www username would be able to pose as the whole site, for example probpting for new user names and passwords. Adding security tag, https://github.com/linkeddata/rdflib.js/blob/master/src/fetcher.js#L643
“I don’t know what this will look like, because it’s an active discussion in the team right now. But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.” – Parisa Tabriz, Director of Engineering, Google Chrome
I'm going to make a simple solution based on the the-big-username-blacklist and a configurable list in addition (in case POD providers want to exclude other usernames such as profanities).
Activity
elf-pavlik commentedon Oct 20, 2018
Would profanity list come from a configuration of each deployment? Also managing i18n list of profanities might come as challenge.
RubenVerborgh commentedon Oct 20, 2018
The entire list would be configurable, I guess.
megoth commentedon Oct 21, 2018
I guess this issue would also entail removing existing accounts that fall within the ban as well? How should we handle that =/
RubenVerborgh commentedon Oct 21, 2018
Only if they are problematic.
rimmartin commentedon Oct 21, 2018
Another tough thing to parse/recognize is context and meaning. Such as Mr Coons or Senator Coons
kjetilk commentedon Oct 21, 2018
Hmmmm, but that could could result in a lot of questions about why this and not that? I think we should mainly consider things that could be used in social engineering.
megoth commentedon Oct 21, 2018
Maybe the blacklist could contain the username not allowed and a reason for why? So that if people try to use that name, they would get a reason behind it?
The list would of course have to be maintained by the POD providers, and they would have different reasons for which usernames they allow and disallow. The base file that we provide with the installation/git repo would contain the names that is disallowed due to obvious misunderstandings (such as www and admin, and perhaps password and user?).
steven-tomlinson commentedon Oct 24, 2018
IMO banning common names that could be used for social engineering seems fairly straightforward and reasonable.
The profanity issue is a whole other can of worms.
I am inclined to ignore that sort of thing unless I find it personally offensive. In which case, I would probably consider that to be a troll account and block it on the existing social media platforms.
Maybe we need some kind of Username Alias, Proxy, or Masking mechanism?
It could substitute an undesirable string in a displayed name with asterisks or a completely different name (VulgarPerson12345) based on a POD Providers blacklist?
timbl commentedon Oct 27, 2018
We should ban www because Google tends to represent www.foo.bar the same as foo.abr in future, which would be a security issue: Someone grabing the www username would be able to pose as the whole site, for example probpting for new user names and passwords. Adding security tag,
https://github.com/linkeddata/rdflib.js/blob/master/src/fetcher.js#L643
“I don’t know what this will look like, because it’s an active discussion in the team right now. But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.” – Parisa Tabriz, Director of Engineering, Google Chrome
Hard to find the original Parisa Tabriz article
megoth commentedon Oct 31, 2018
I'm going to make a simple solution based on the the-big-username-blacklist and a configurable list in addition (in case POD providers want to exclude other usernames such as profanities).
Any objections on this?
dmitrizagidulin commentedon Oct 31, 2018
@megoth +1 to this. Seems like a great first step.
megoth commentedon Oct 31, 2018
I've implemented a first iteration of the blacklist service; if this looks good, I'll continue using this on #824
michielbdejong commentedon Jun 20, 2019
@kjetilk can this be closed?
kjetilk commentedon Jun 21, 2019
Hmmm, yeah.