Quad9 "does not collect", but .... it does.... (Was: Google DNS on Salt Mobile)

TLDR:
  - https://quad9.net/policy/ and https://quad9.net/privacy/ are the 
multiple pages of legalese
     - it is a long text, not actually mentioning any actual technology
     - nobody using 9.9.9.9 will read it as they are using an IP, not a 
website with text
     - it can change whenever, there are no versions, there is no history 
of what changed (archive.org possibly)
     - for a variety of reasons IP (and thus PII) might be gathered 
anyway
     - IP prefixes are summarized, but unknown till which size (IPv6 
/48?)
     - Undefined what happens with packets towards 9.9.9.9 (is somebody 
doing PDNS, or otherwise grabbing bits?)
     - Nothing mentioned about RFC7871 (EDNS Client Subnet) which is 
required for helping CDNs/Geo-DNS...
     more inline ;)


Oh and for the record: Woody, you are not the "problem" here, the 
companies around Quad9 though, they have a commercial interest in the 
data... somebody has to pay for it, and that can mostly only be solved 
with the personal data collection.... nothing is for free in the end and 
bills (and woody's :) have to be paid.


On 2018-11-01 06:24, Bill Woodcock wrote:
>> On Oct 29, 2018, at 11:38 PM, Jeroen Massar <[email protected]> wrote:
[snip]
>> How can something be "GDPR compliant" when no consent is given at all?
> 
> By not collecting any PII.

That is indeed a great start, what one does not have, one cannot abuse.


>> Have you layered HTTP on top of DNS to provide a 20-pager of legalise 
>> that nobody can be bothered to read as it will change at a moment's 
>> notice?
> 
> No.
> 
>> Stating "it doesn’t collect source IP addresses" means "but we collect 
>> everything else”.
> 
> That’s an obviously false statement, and doesn’t usefully contribute
> to the conversation.


Strange as https://quad9.net/privacy/ reads:

"We share anonymized data on specific domains (such as domain, 
timestamp, geolocation, number of hits, first seen, last seen) with our 
threat intelligence partners."

That says "Domains" and possibly labels.
It also says "geolocation" which is derived from an IP, which can be 
wildly wrong but also extremely specific...


It is not specified at all what is actually really collected. It would 
be great to have a list, or a log example or heck the tool (as it is 
likely open source...) of what is actually logged/collected/"shared with 
partners".



But more importantly, for us 'geeky people' who run our own domains, 
that domain identifies an individual and thus a domain in effect points 
to PII..... while 'gmail' is general, 'massar.ch' is not so general any 
more...



Next to that labels can include IP addresses (e.g. 1.2.3.4.in-addr.arpa, 
but also the forward 4-3-2-1.dsl.isp.example) Noting that these are 
looked up by every SMTP server on the planet.

Are you saying you are dropping these labels? As otherwise, you are 
collecting PII.


https://quad9.net/policy/ reads:

"This policy may be amended by Quad9, and the new version of the policy 
shall become effective upon its posting "

so, as it is not versioned, and previous versions are not available, 
that 'policy' can be changed any time.

Today it might look okay, tomorrow, it will not, and then 9.9.9.9 is 
hardcoded like 8.8.8.8 and nobody gave consent on the change in policy.


Lets look a bit deeper:
"When you use Quad9 DNS Services, the information we gather aides us to 
personalize, improve and operate our infrastructure. "

Personalize? So, as in, P(ersonaliz)eII , how does one "personalize" 
when you claim to not collect Personal Information?

"Our normal course of data management does not have any IP address 
information or other PII logged to disk or transmitted out of the 
location in which the query was received."

What is the "not-normal course"? When is that applied? What happens 
then?


Did you note the 20 pages of legalese I mentioned, indeed, there is 
about that amount on those pages. Would be cool to have a bullet list of 
what is collected...

"We may aggregate certain counters to larger network block levels for 
statistical collection purposes"

So, you keep addresses, but at "block" level. For IPv6, is that on /64, 
/56 or /48? And for IPv4 /31? ... would be great to specify otherwise 
that is a meaningless statement.

"observed behaviors which we deem malicious or anomalous"

Is "trying to resolve a malware URL" considered "malicious"? would be 
great to specify this.
(I guess what I know what is written, but hey, it is a policy, thus 
legalese and thus, needs to be specific).


"We do keep some generalized location information (at the 
city/metropolitan area level) so that we can conduct debugging and 
analyze abuse phenomena."

Are you saying that certain "cities" have more abuse than others!? :)

Look, just state that for debugging, IP addresses will be seen, nobody 
minds they are in the clear.
But just do not log it and definitely do not automatically share with 
"3rd parties"...


I'll skip commenting on the cookie section as that section just violates 
any form of 'privacy'...


"Quad9 does not store PII IP address data on permanent storage methods 
(disk) or transmit that data out of the datacenter in which the query 
was received."

Funny, it actually says exactly that it shares those things with 
'partners'...

I'll also skip over that "partner" means $world when one talks about 
companies the size of IBM, everybody is a 'partner' (google uses that 
same tactic in their 'privacy' policies)

[snip]
> If you see a privacy problem with any of that, please tell them.  Or
> tell me, and I’ll pass it along.  The entire purpose is to improve
> privacy and security.  If they’re not actually doing that, they’re
> failing, and there’s no point in doing it if it’s failing.

How is privacy and security improved by sending packets to a third party 
one does not have a financial incentive with (if you are not the 
customer, you are the product)...

Somebody pays for the infra, thus what are they getting back?

>> IP addresses, especially sources, sometimes also appear in the label, 
>> simply because some weird CDNs/ISPs will encode the source IP for 
>> 'geo-dns' or 'loadbalancing' reasons in the label.
> 
> While you’re right, that has no bearing, since the labels aren’t being
> collected.
> 
>> Are you stripping those?
> 
> Or do you mean RFC 7816?  Yes.  I believe it may not be entirely
> rolled out in production yet, but that may have gotten finished while
> I wasn’t looking.
> 
>> And then there are RBLs, and reverse-IPs in general. Do you filter 
>> those?
> 
> Can you ask the question more explicitly?  I don’t understand it as 
> stated.

Simple embedding of IPs in labels. See above in-addr.arpa and 
dsl.isp.example examples.


But speaking of RFCs.... RFC7871 (ENDS Client Subnet) is not supported 
to optimize all that GeoDNS traffic?
No mention in the 'privacy' or 'policy'.

Would be good to just list the technologies used.


>> There are many reasons why so many of the public DNS resolvers popped 
>> up: one of them is the amount of data that can be extracted from it.
> 
> Exactly.  And in Quad9’s case the reason is because privacy regulators
> were looking for an exemplar to use in their argument that collection
> of PII wasn’t a business requirement for operating a DNS resolver.

ISPs do not have to collect it either, and people already have a 
relationship with them and locally, with low latency and full support 
desks to help people when there are problems.

Thus the example one is looking for is the ISPs.

Though of course, in the US this might be quite different from other 
countries where ISPs work against their customers instead of for them...

>> Please stop centralizing this Internet thing….
> 
> To the best of my knowledge, I’ve spent the past thirty years doing
> the opposite.  If you have some reason to believe otherwise, please
> bring it to my attention.

You indeed have, but the companies involved in quad9 have not...

and while previous work has been awesome, this is a bit the opposite and 
centralizes things.

Greets
  Jeroen



_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog