Change Details

==== Background T363906 introduces the concept of variables that have PII, specifically a `user_ip` variable, for use when temporary accounts are enabled, since `user_name` will no longer be the IP address. (This will not be available for fully registered users, just temporary users.) The IP address in the filter and the filter details will only be readable by users who have access to reveal IP addresses. As will the logs for that filter being triggered. In accordance with our policy of deleting IP addresses after a fixed time, the value will be stored in `afl_ip` (separately from the rest of the data, in `afl_var_dump`), so that it can be purged after the fixed time. However, as it stands, logs will be visible forever, so whoever can read a filter containing the IP address can see who triggered the filter from that address or range. ==== Is this a problem? This was mentioned up in T363906#9782548. There's a comparable case in CheckUser, where it can be accurately guessed from the CheckUser logs which users are associated with which IP addresses, even after the IPs have been removed. This case is arguably worse, if the barrier to triggering a filter is lower than the barrier to triggering a CheckUser investigation. ==== What can be done? Some suggestions: * Do nothing * Purge any logs for filters containing IP addresses after a time * Remove the filter ID from any logs for filters containing IP addresses after a fixed time

==== Background T363906 introduces the concept of variables that have PII, specifically a `user_unnamed_ip` variable, for use when temporary accounts are enabled, since `user_name` will no longer be the IP address. (This will not be available for fully registered users, just temporary users.) The IP address in the filter and the filter details will only be readable by users who have access to reveal IP addresses. As will the logs for that filter being triggered. In accordance with our policy of deleting IP addresses after a fixed time, the value will be stored in `afl_ip` (separately from the rest of the data, in `afl_var_dump`), so that it can be purged after the fixed time. However, as it stands, logs will be visible forever, so whoever can read a filter containing the IP address can see who triggered the filter from that address or range. ==== Is this a problem? This was mentioned up in T363906#9782548. There's a comparable case in CheckUser, where it can be accurately guessed from the CheckUser logs which users are associated with which IP addresses, even after the IPs have been removed. This case is arguably worse, if the barrier to triggering a filter is lower than the barrier to triggering a CheckUser investigation. ==== What can be done? Some suggestions: * Do nothing * Purge any logs for filters containing IP addresses after a time * Remove the filter ID from any logs for filters containing IP addresses after a fixed time

==== Background T363906 introduces the concept of variables that have PII, specifically a `user_unnamed_ip` variable, for use when temporary accounts are enabled, since `user_name` will no longer be the IP address. (This will not be available for fully registered users, just temporary users.) The IP address in the filter and the filter details will only be readable by users who have access to reveal IP addresses. As will the logs for that filter being triggered. In accordance with our policy of deleting IP addresses after a fixed time, the value will be stored in `afl_ip` (separately from the rest of the data, in `afl_var_dump`), so that it can be purged after the fixed time. However, as it stands, logs will be visible forever, so whoever can read a filter containing the IP address can see who triggered the filter from that address or range. ==== Is this a problem? This was mentioned up in T363906#9782548. There's a comparable case in CheckUser, where it can be accurately guessed from the CheckUser logs which users are associated with which IP addresses, even after the IPs have been removed. This case is arguably worse, if the barrier to triggering a filter is lower than the barrier to triggering a CheckUser investigation. ==== What can be done? Some suggestions: * Do nothing * Purge any logs for filters containing IP addresses after a time * Remove the filter ID from any logs for filters containing IP addresses after a fixed time