Can you elaborate? Neither Google nor CloudFlare seem to collect information for profiling.
Google: https://developers.google.com/speed/public-dns/privacy
CloudFlare: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Can you elaborate? Neither Google nor CloudFlare seem to collect information for profiling.
Google: https://developers.google.com/speed/public-dns/privacy
CloudFlare: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Cloudflare does not store any information, but they are pretty frank about passing it on to APNIC for "research" as part of the deal where APNIC lend the 1.0.0.1 and 1.1.1.1 address to them. This is pretty well established and actually openly communicated by both entities, so should be easy to DDG. You are of course free to believe that this data is totally anonymized and not used for profiling / targeting at all, but imo that is pretty naive.
For the record, we don't build any sort of profile of DNS queryiers, map them back to any existing profile we have, or even keep the data you would need to have to do that.
If the data sent to APNIC is so safe and non-personal, why not make it transparent? Instead, when contacting APNIC about it, you get a typical one liner stating that
> ... the access to the primary data feed will be strictly limited to the researchers in APNIC Labs, and we will naturally abide by APNIC's non-disclosure policies.
Clearly, someone thinks there is something to hide. Maybe not Cloudflare, but then it's someone else.
I'm not with CF or APNIC, but it's likely due to issues with sensitive data.
Say a web service is hitting `http://internal.example.com:5220` with basic authentication, or there's a misconfigured jira trying to access `internal.example.com:3306`, but the DNS admins have retired `internal.example.com` and decided to make it return `1.1.1.1` for some reason. Showing all traffic that hits the service would expose a little too much sensitive information.
In addition, if "internal.example.com" is not already resolvable publicly (which would mean that it's known) CF could not guarantee the privacy of that query anyways because their DNS is not part of the root zone, which means they need to forward it to someplace beyond their control, meaning they leak it no matter what.