Putting aside the fact that the task mentioned in the description doesn't seem to exist, this is something that I would support and would be happy to assist with in any way possible. We shouldn't allow users to violate the Content Policy or Code of Conduct by way of their custom domain name(s).

However, one thing we should be mindful of is that certain services that sell or provide domains to users will already have their own blacklists/restrictions in place as to what they will not provide or offer, and IMO Miraheze should do its best to not have redundant policies (i.e. Miraheze shouldn't need to explicitly blacklist something that no legitimate custom domain provider would sell or offer anyway). From my experience, most, but admittedly not all domain providers have at least general restrictions around references to or explicit inclusions of content that is "not safe for work".

I would also suggest that we make clear what domains are not allowed on the Custom Domains page on Meta, and directly link to that section or page from Special:RequestWiki. Also maybe add a reminder to check to make sure that a custom domain doesn't violate any restrictions to the boilerplate/prefill text of the SSL Phabricator form.

In T5644#110163, @AmandaCath wrote:

Putting aside the fact that the task mentioned in the description doesn't seem to exist, this is something that I would support and would be happy to assist with in any way possible. We shouldn't allow users to violate the Content Policy or Code of Conduct by way of their custom domain name(s).

However, one thing we should be mindful of is that certain services that sell or provide domains to users will already have their own blacklists/restrictions in place as to what they will not provide or offer, and IMO Miraheze should do its best to not have redundant policies (i.e. Miraheze shouldn't need to explicitly blacklist something that no legitimate custom domain provider would sell or offer anyway). From my experience, most, but admittedly not all domain providers have at least general restrictions around references to or explicit inclusions of content that is "not safe for work".

I would also suggest that we make clear what domains are not allowed on the Custom Domains page on Meta, and directly link to that section or page from Special:RequestWiki. Also maybe add a reminder to check to make sure that a custom domain doesn't violate any restrictions to the boilerplate/prefill text of the SSL Phabricator form.

If the task has a lower ID than the latest one, it existed at one point. The referenced issue is currently non-public and is likely the largest driving factor for paladox coming up with this idea, although it would likely be a good time to incorporate any policies or restrictions we feel are needed.

Putting aside the fact that the task mentioned in the description doesn't seem to exist

Phabricator does not link to objects you can’t view.

If you went to https://phabricator.miraheze.org/T5643, you would see that it does exist and get an access denied message.

Regarding

From my experience, most, but admittedly not all domain providers have at least general restrictions around references to or explicit inclusions of content that is "not safe for work".

We do not ban NSFW content unless what it depicts is illegal.

I agree with your methods to advertise the new policy but as you can’t see the task, it’s impossible for you to know the driving factors behind it and half your comment entirely misses the actual point.

But yes, of course, a custom domain does not allow you to circumvent our policy.

Perhaps we should avoid creating public tasks that are documenting a response to a security sensitive task until the security task is public, since it otherwise creates confusion.

Although @RhinosF1 how did you view the task when as far as I can tell you are not in the Security project membership?

In any sense, I don't see this being a real problem because whatever policy/blacklists we create, I would expect that any Phabricator SSL requests for a domain in violation of policy would just be declined and therefore suspending the wiki/domain wouldn't even be necessary.

Perhaps we should avoid creating public tasks that are documenting a response to a security sensitive task until the security task is public, since it otherwise creates confusion.

The task will likely never be public due to what's discussed in it

Although @RhinosF1 how did you view the task when as far as I can tell you are not in the Security project membership?

As I created the task :)

In any sense, I don't see this being a real problem because whatever policy/blacklists we create, I would expect that any Phabricator SSL requests for a domain in violation of policy would just be declined and therefore suspending the wiki/domain wouldn't even be necessary.

We can't know what people do after we accept the request so it possibly would.

The task will likely never be public due to what's discussed in it

It is my understanding that security tasks are made public once the actual issue has been resolved and is no longer exploitable. If I recall correctly, Phabricator administrators can redact comments that contain private information. I also don't think it would be good practice to create a global policy based upon something that the vast majority of users who it would possibly affect can't view.

In T5644#110227, @AmandaCath wrote:

The task will likely never be public due to what's discussed in it

It is my understanding that security tasks are made public once the actual issue has been resolved and is no longer exploitable.

My comment still applies.

If I recall correctly, Phabricator administrators can redact comments that contain private information. I also don't think it would be good practice to create a global policy based upon something that the vast majority of users who it would possibly affect can't view.

You can’t redact the title or task description.

We don’t want them to know about the reasons why, just they can’t do it.

We don’t want them to know about the reasons why, just they can’t do it.

From my experience (and speaking as someone who deals with security issues on a semi-regular basis) people are more likely to try to evade/exploit something that they don't know the reasons for than they are something that they do know the reasons behind. Unless it is obvious, the rationale for any global policy should be public at least in some form.

Unless it is obvious, the rationale for any global policy should be public at least in some form.

Due to security concerns