[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DOH (was: geolocation services disabled and Gnome maps)



On 4/14/20, Reco wrote:
> 	Hi.

Hi

> On Mon, Apr 13, 2020 at 06:42:10PM -0400, Lee wrote:
>> On 4/13/20, Reco  wrote:
>> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>> >> > The questionable idea behind DOH is that the browser makers do not
>> >> > trust
>> >> > your local resolver.
>> >>
>> >> Mozilla claims it's a privacy issue:
>> >> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
>> >
>> > It's a privacy issue along with the other things.
>> > With the default settings the Firefox user is handing all DNS
>> > resolution
>> > to Cloudflare. Not an equivalent to complete browsing history, but
>> > close
>> > enough.
>>
>> Right.  The ISP can't see what names the user is looking up but
>> Cloudflare sees every single one.  On the other hand, take a look at
>>   https://wiki.mozilla.org/Security/DOH-resolver-policy
>
> An interesting declaration. For instance:
>
> 1. The resolver may retain user data (including identifiable data...)
> but should do so only for the purpose of operating the service and
> must not retain that data for longer than 24 hours.
> ...
> 2. Transparency Report. There must be a transparency report published at
> least yearly that documents the policy for how the party operating the
> resolver will handle law enforcement requests for user data and that
> documents the types and number of requests received and answered, except
> to the extent such disclosure is prohibited by law.
>
>
> Thus:
>
> a) Cloudflare is allowed to store whatever they want for 24 hours.
> b) They aren't forbidden to give that data to the law enforcement, which
> is not binded by that Mozilla’s Trusted Recursive Resolver program.

Maybe I'm being naive, but I'm taking the clause "except as may be
required by law" to mean they can't just give the data to LE; there
has to be some kind of court order compelling them to hand it over.

> c) Law enforcement entity hires some independent contractor to help them
> store this data.
> d) Next thing you know, everyone's DNS history is world-accessible via
> some unprotected ElasticSearch instance on AWS.
> e) And the best thing here is - Mozilla legally allowed it to happen.

Is there some other DNS provider that has a  published privacy policy?
 That's anywhere near as good as CloudFlare's?

To be clear - I'm not saying you should trust CloudFlare.  It's just
that I don't see a whole lot of options & quite possibly CloudFlare is
more trustworthy than your USA ISP.

>> >> If firefox wasn't a viable alternative to chrome, what are the chances
>> >> that change would have been implemented?
>> >
>> > It is implemented already, it's just there are alternatives to
>> > declarativeNetRequest that are working - so far.
>>
>> Ahh.  I thought Google backed down on the change..
>
> I happen to build chromium from the source from time to time. Recent
> versions (>=80) require re2 regex library just for declarativeNetRequest
> alone.

Cool - so you would know the answer to this question: Is the chromium
you build from source code **totally** built from source code you have
with no binaries, libraries, DLLs, or anything else like that
included?

In other words, how trustworthy is your 'built from source code'
chromium?  Have you done any testing to see if it "phones home"?

>> >> > With the advent of HTTPS all this may be seen as moot points (if
>> >> > you're
>> >> > redirected elsewhere the certificate validation should fail), but
>> >> > nevertheless DOH is forced upon the collective throat of Firefox
>> >> > users
>> >> > as we speak (and Chrome users are likely to follow them Soon™).
>> >> > Currently a Firefox user is supposed to trust Cloudflare to do DNS
>> >> > queries for them, and HTTPS is used for this purpose because
>> >> > Security™.
>> >>
>> >> For some values of "security", DOH _is_ more secure.
>> >
>> > As far as the "last mile" is concerned - maybe.
>>
>> How about as far as the "end user" is concerned? (which is what I
>> thought we were talking about -- clueless end-users having doh forced
>> on them)
>
> It's akin to the tempered glass. I.e. it's less likely to break than a
> normal glass, but it's still transparent. It's also akin to building a
> castle on a sand.
>
> I.e. if the user does not care about security it may improve overall
> situation somewhat, but the cost of this improvement is privacy.

Do you live in the EU?

Not everyone has the ability or inclination to do things like run
their own resolver or build chromium from source.  It's possible FF
enabling DOH is an improvement for most of their users.

>> >> How many people use a dnssec validating resolver?
>> >
>> > See above. Besides, DNSSEC is for integrity of zones, not privacy.
>> > You need DNS-over-TLS if you need last one.
>>
>> "integrity of zones" is part of "security" - yes?
>
> Yes. My point is that it's only a part of the security. A needed part,
> but a part nevertheless.
>
>
>> DoT or DoH - either one gets you privacy from your ISP
>> DoT is easy to block, DoH is harder to block, so somewhat censorship
>> resistant?
>
> Both are easily blocked in their current form, in fact, DoH is easier in
> this regard - it makes very distinct HTTPS (i.e. tcp:443) queries to a
> ten (at most) well-known IPs.

I count a lot more than 10 DoH providers at
  https://github.com/curl/curl/wiki/DNS-over-HTTPS

>> >> At least Cloudflare resolvers have dnssec enabled.
>> >
>> > *And* the ability to see users' DNS queries. Neat, right?
>>
>> Yup, and probably a net win for people that don't have a clue about
>> dns .. or at least people in the US.  Do people in the EU have to
>> worry about their ISP selling their usage data?
>
> No. You do not worry about something that widely happens, you deal with
> it one way or another.

you're saying that EU ISPs sell their user's online activity data?

> And it's possible to sidestep GDPR just by
> injecting "trusted partners'" ads in users' HTTP traffic, for instance.

Wow!  I'm amazed that would be allowed in the EU

Regards,
Lee


Reply to: