We removed this property in T348659: [S] Decide which tunnels to store because at the time we had no use for it. However, T380711: Provide ip_reputation_tunnel_type AbuseFilter variable will use it to determine whether or not to return data so we should re-implement it.

In T380711#10371245, @STran wrote:

iirc, we never wrote the anonymous property to the table and then discovered that a tunnel.operator could be used both anonymously and not. Since the operator name is the unique constraint, we would have only ever recorded the first value of anonymous found regardless and never been able to distinguish the usage.

In T348659#10371290, @STran wrote:

but to restore this field we'd also have to:

• remove the unique constraint on the operator name (as a tunnel can be used both anonymously or not)
• support null/true/false on the anonymous property, as we have no way of knowing whether or not current users of the tunnel are doing so anonymously or not (or make some assumptions)
• update any searches for tunnel operators to also include the anonymous property

Additionally, that means null will no longer be a valid entry so we should probably write a maintenance script that periodically clears out these stale values.

I think this should be a 3 step process:

• record the anonymous property, ensure that it's being correctly written to the tunnels table
• audit and wherever necessary, update calls to the tunnel table. We don't reveal the anonymous property anywhere (because we don't expect it) but that doesn't guarantee the queries in use now will still work after this update
• implement the maintenance script to clear out now-invalid rows in tunnels