>
We need to anonymize both IP addresses and proxy information with a secure hash if we want to keep each GET request's geolocation, to be compliant with the Privacy Policy. Maybe this is not clear, raw IPS are not kept once geolocalization is done. IPs are discarded and geolocation info is the one kept long term.
>The Privacy Policy is the most prominent policy on the far left on the footer of every page served by
>every editable project, and says explicitly that consent is required for the use of geolocation.
The privacy policy talks about client side geo location to offer you geo-specific features on the client side, which is an entirely different topic of what we are taking about here. IP addresses are going to be sent via HTTP regardless with your request and the geo location we do (to be able to report for example pages per country, one of the reports most sought after by our community) has nothing to do with geolocated features.
Anonymization is hard but thus far none is mentioned doing that, right? When it comes to IP data, again, we do not kept it long term neither do we anonymize it with any illusion of privacy, we just discard it as soon as we can.
>If Ops needs IP addresses, they should be able to use synthetic POST requests, as far as I can tell. If they anticipate a need for non-anonymous GET requests, then perhaps some >kind of a debugging switch which could be used on a short term basis where an IP range or mask could be entered to allow matching addresses to log non-anonymously before >expiring in an hour would solve any anticipated need?
You can bring that up with ops team, I doubt we can operate a website for hundreds off millions of devices (almost a billion) and troubleshoot networking issues, DOS and others without having access to raw IPs for a short period of time. Ops work doesn't need to have access to IP data long term, just near term.