Process for blacklist removal

[tripleee]

web (no space here) line (no space here) india (dot) com is demanding that we remove them from our blacklist. (I will create a separate ticket about that incident and link back here.) We can perhaps accommodate their demand in a way which might be acceptable to them without sacrificing our goals, but we want to have clear criteria for when we can do that, mainly in order to not be inundated by requests from every spammer on the planet to have us do the same for them.

I have a proposal which will be posted as a separate comment below so you can give it thumbs up or thumbs down, and/or make a separate proposal so we can vote.

[magisch]

Disclaimer: Personal opinion only.

I suggest we do not accomodate them. We're not obligated to help a company police their image online. If someone is spamming for them, they have to be the ones to stop it. Our blacklist should only be modified based on our blacklist criteria.

I think we do not have an obligation to obfuscate anything, and I propose not starting with even accomodating through workarounds. Once we do that, nothing stops other companies from demanding the same.

We can perhaps accommodate their demand in a way which might be acceptable to them without sacrificing our goals, but we want to have clear criteria for when we can do that, mainly in order to not be inundated by requests from every spammer on the planet to have us do the same for them.

I think this can work, but only when:

• The company provides sufficient evidence that spamming is not condoned by them, or done by employees or affiliates, and puts forth a sufficient effort to prevent that from happening
• Performance of our spam checks isn't affected
• Functionality of our spam checks isn't affected.
• The company is not hostile in requesting the change, and does not threaten legal action when not immediately satisfied.

[Glorfindel83]

For the record, an acceptable workaround could be not having example\.com as a blacklist entry, but [ee][xx][aa][mm][pp][ll][ee]\.com instead.

[tripleee]

We can't really put in respectable and professional conduct as an unconditional requirement for fixing a problem. People are often frustrated, afraid, and stressed when they think something is wrong. But other than that, I think the draft by Magisch summarizes more or less what I had in mind; and I have given my thumbs up.

[magisch]

@tripleee In general I agree, but I think that giving an inch when someone is demanding a mile is legally dubious for us. When the first thing someone spouts is a legal threat I'd say we should wait for them to actualize it and not give in to that, on principle alone.

[tripleee]

I completely agree that we mustn't cave just because they try to intimidate us; what I'm trying to say is that we also cannot refuse simply because of that. If somebody has a grievance, we should decide the matter on facts alone. It's easy and very human to take offense if somebody is being unpleasant; but our principles need to simply disregard that, and perhaps even guide us as humans to try to be professional about it .

[AWegnerGitHub]

My initial proposal, so that we have something to argue about, for removal from a blacklist. These guidelines are for patterns/urls/terms that are requested by an outside party.

• Proposed term/URL will receive a dedicated GitHub issue that includes links to the discussion in Charcoal HQ where the removal is discussed and searches to metasmoke with posts containing the URL. There may be multiple searches to account for leading/missing www or other variations seen in the past.
• Proposed term/URL must not have been used in any reported and confirmed spam post on Stack Exchange in the last 6 months
• Proposed term/URL will be demoted from a blacklisted term to a watched term for a period of 2 months.
• Proposed term/URL will NOT be obfuscated when it is demoted to a watched term.
• If the proposed term/URL is seen again within those 2 months and it is confirmed spam, the term/URL will be immediately promoted to a blacklisted term again, the associated Github issue will be updated and the term will be ineligible for requested removal.
• If the proposed term/URL is not seen again within those 2 months, it is removed from the watch list.
• If the proposed term/URL is seen after that removal and those 2 months, it will go through our standard process of determining whether or not to add it to the blacklist.
• A proposed term/URL can only go through this requested process one time. If it is removed and then readded, this URL will be ineligible for requested removal. Instead it will follow our standard process of blacklist pruning.

---

Argue away.

[j-f1]

Counterproposal: once we have Helios, we can stop search crawlers from seeing it, meaning that it wouldn’t be possible to find the blacklist via search, so there wouldn’t be a reason to remove it to avoid PR issues for the website admin.

[AWegnerGitHub]

The pedant in me wants to say "we should still have a way to allow someone to request removal"...but I think this is the first request we've received so your way seems easier, @j-f1

[caffeineaddiction]

along with @j-f1 's idea ... it would be relatively trivial to automatically 'retire' domains from the blacklist once the pattern has not been triggered for X number of days/months ... best problems are ones that take care of themselves

[ArtOfCode-]

We can have both. @j-f1's suggestion is the most practical; avoiding the issue entirely is a good way to go. I do agree with Andy's inner pedant, though.

How I suspect it'll work: we won't actually officially agree on a removal process, but if/when we get another removal request, whoever deals with it will follow Andy's suggested process anyway.

[magisch]

sounds reasonable @ArtOfCode- . Not that we'd likely get another one anyways, I suspect the cross section of known spammers and companies that care about us is really just this one weird indian outsourcing studio.

[tripleee]

Even before reading the latest comments, I was going to suggest simply closing this issue as something we probably will never have to think about again, but if it ever comes up, we have a reasonable draft to refer to. At that point, maybe reopen this ticket, or create a new one which links back here.

In the chat transcript, there were multiple things in responses to Tech (the guy from SmokeDetector/1444) which I thought would be useful to include as context for an outside person to read before even asking us to remove anything, but I'll just leave this remark here at this point.

[angussidney]

It looks like we've come to an agreement here; should we transfer this policy to a wiki page so that we can close this issue?

[angussidney]

I've written this up on our wiki, feedback is welcome.