Change Details

This is something that several people have reported as useful. It was also mentioned in the talk page on meta about masking IPs. Basically, just as we have public and private filters, we could add another visibility level (like "sensitive") for CUs only. Filters with "sensitive" visibility could contain explicit NPI mentions, and we could allow using new variables. For instance, the UA (T50623), maybe the IP even for registered users. This idea has great potential, but there are various things to discuss: # From a legal standpoint, would this be OK? Speaking about active filters, the access is //sort of logged//. # What to do with /test etc. Using a "sensitive" variable to test a filter against recent changes is currently not logged. # More generally, we don't have any system in place that would prevent people from using certain variables in certain contexts. # A filter marked as "sensitive" should always keep the same visibility, to avoid any possible info leak. # In theory, a schema change is not mandatory (af_flags is a commalist of flags); in practice, I'd strongly recommend doing that instead (i.e. add a new column, like "af_sensitive"; maybe in abuse_filter_history, too). --- Speaking for myself, I do not plan to engage in such a work in the short term. Aside from the blockers above, the AF is currently undergoing a bunch of relatively big changes, which I'd like to prioritize. Should a team (AHT?) be interested in exploring the idea (e.g. as part of the IP masking project), I can help.

This is something that several people have reported as useful. It was also mentioned in the talk page on meta about masking IPs. Basically, just as we have public and private filters, we could add another visibility level (like "sensitive") for CUs only. Filters with "sensitive" visibility could contain explicit NPI mentions, and we could allow using new variables. For instance, the UA (T50623), maybe the IP even for registered users (T155553). This idea has great potential, but there are various things to discuss: # From a legal standpoint, would this be OK? Speaking about active filters, the access is //sort of logged//. # What to do with /test etc. Using a "sensitive" variable to test a filter against recent changes is currently not logged. # More generally, we don't have any system in place that would prevent people from using certain variables in certain contexts. # A filter marked as "sensitive" should always keep the same visibility, to avoid any possible info leak. # In theory, a schema change is not mandatory (af_flags is a commalist of flags); in practice, I'd strongly recommend doing that instead (i.e. add a new column, like "af_sensitive"; maybe in abuse_filter_history, too). --- Speaking for myself, I do not plan to engage in such a work in the short term. Aside from the blockers above, the AF is currently undergoing a bunch of relatively big changes, which I'd like to prioritize. Should a team (AHT?) be interested in exploring the idea (e.g. as part of the IP masking project), I can help.

This is something that several people have reported as useful. It was also mentioned in the talk page on meta about masking IPs. Basically, just as we have public and private filters, we could add another visibility level (like "sensitive") for CUs only. Filters with "sensitive" visibility could contain explicit NPI mentions, and we could allow using new variables. For instance, the UA (T50623), maybe the IP even for registered users (T155553). This idea has great potential, but there are various things to discuss: # From a legal standpoint, would this be OK? Speaking about active filters, the access is //sort of logged//. # What to do with /test etc. Using a "sensitive" variable to test a filter against recent changes is currently not logged. # More generally, we don't have any system in place that would prevent people from using certain variables in certain contexts. # A filter marked as "sensitive" should always keep the same visibility, to avoid any possible info leak. # In theory, a schema change is not mandatory (af_flags is a commalist of flags); in practice, I'd strongly recommend doing that instead (i.e. add a new column, like "af_sensitive"; maybe in abuse_filter_history, too). --- Speaking for myself, I do not plan to engage in such a work in the short term. Aside from the blockers above, the AF is currently undergoing a bunch of relatively big changes, which I'd like to prioritize. Should a team (AHT?) be interested in exploring the idea (e.g. as part of the IP masking project), I can help.