Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #221123 > unrolled thread
| Started by | Anil F Duggirala <anilduggirala@fastmail.fm> |
|---|---|
| First post | 2020-04-09 15:00 +0200 |
| Last post | 2020-04-10 20:00 +0200 |
| Articles | 20 on this page of 118 — 23 participants |
Back to article view | Back to linux.debian.user
geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-09 15:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-09 16:50 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-09 16:50 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-11 17:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:40 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 18:10 +0200
Re: geolocation services disabled and Gnome maps Celejar <celejar@gmail.com> - 2020-04-13 15:50 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-13 23:10 +0200
Re: geolocation services disabled and Gnome maps Brad Rogers <brad@fineby.me.uk> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Joe <joe@jretrading.com> - 2020-04-11 20:50 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-12 01:20 +0200
Re: geolocation services disabled and Gnome maps Gene Heskett <gheskett@shentel.net> - 2020-04-12 02:40 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 09:20 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-12 20:20 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 17:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:50 +0200
Re: geolocation services disabled and Gnome maps Brad Rogers <brad@fineby.me.uk> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 18:20 +0200
Re: geolocation services disabled and Gnome maps rhkramer@gmail.com - 2020-04-11 22:10 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 22:20 +0200
Re: geolocation services disabled and Gnome maps rhkramer@gmail.com - 2020-04-12 02:30 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 10:10 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-12 10:20 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 10:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 11:50 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 16:20 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 17:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-12 12:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-12 12:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 12:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-12 13:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-13 01:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 07:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-13 10:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 12:00 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-13 12:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-13 13:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 15:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-13 17:20 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:40 +0200
Re: DOH "Liam O'Toole" <liam.p.otoole@gmail.com> - 2020-04-14 22:10 +0200
Re: DOH Reco <recoverym4n@enotuniq.net> - 2020-04-14 22:50 +0200
Re: DOH Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-14 23:30 +0200
Re: DOH Celejar <celejar@gmail.com> - 2020-04-15 00:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-15 01:10 +0200
Re: DOH Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-15 01:30 +0200
Re: DOH Reco <recoverym4n@enotuniq.net> - 2020-04-15 09:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 00:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-14 08:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 13:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) nito@dismail.de - 2020-04-14 13:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-14 14:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-14 15:30 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-14 17:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-14 05:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 11:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-14 19:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-14 19:20 +0200
Re: DOH Celejar <celejar@gmail.com> - 2020-04-15 00:00 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-13 09:20 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 01:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) tomas@tuxteam.de - 2020-04-14 10:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-14 13:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-14 16:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-15 01:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-15 13:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) David Wright <deblis@lionunicorn.co.uk> - 2020-04-15 16:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-17 05:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Gene Heskett <gheskett@shentel.net> - 2020-04-12 13:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:40 +0200
Re: DOH Michael Howard <mike@dewberryfields.co.uk> - 2020-04-12 15:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Gene Heskett <gheskett@shentel.net> - 2020-04-12 18:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Tixy <tixy@yxit.co.uk> - 2020-04-12 14:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 15:00 +0200
Re: geolocation services disabled and Gnome maps Joe <joe@jretrading.com> - 2020-04-11 23:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 10:00 +0200
Re: geolocation services disabled and Gnome maps Celejar <celejar@gmail.com> - 2020-04-13 16:00 +0200
Re: geolocation services disabled and Gnome maps Richard Owlett <rowlett@cloud85.net> - 2020-04-13 16:40 +0200
Re: geolocation services disabled and Gnome maps Michael Howard <mike@dewberryfields.co.uk> - 2020-04-13 16:40 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-11 17:10 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-09 18:20 +0200
Re: geolocation services disabled and Gnome maps "Anil Felipe Duggirala" <anilduggirala@fastmail.fm> - 2020-04-10 15:30 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 15:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 16:30 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:30 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 16:30 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:00 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 17:40 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 18:10 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 20:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 18:20 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 18:40 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-10 18:40 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps tomas@tuxteam.de - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:30 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:30 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-11 17:20 +0200
Re: geolocation services disabled and Gnome maps Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-13 13:40 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 20:00 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-11 09:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 10:30 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps mick crane <mick.crane@gmail.com> - 2020-04-10 19:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 20:00 +0200
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-04-13 15:30 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zV7jY-7e6-7@gated-at.bofh.it> |
| In reply to | #221381 |
On Mon, Apr 13, 2020 at 12:14:44PM +0100, Liam O'Toole wrote: > On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote: > > Hi. > > > > On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote: > > [...] > > > > Whether DoH or DNS-over-TLS, you have to trust the DNS server. > > > > Yup. That's why I have my own, and every Debian user can have their own > > too, using only free software. > > > > Pray tell us more. I use dnsmasq for clients on my LAN, but even that > has to use an upstream name server --- in my case the one provided by my > ISP. 1) Rent yourself a VPS, install bind there (there's no DNS but bind). Replace bind with unbound if you need caching-only nameserver (caching-only bind is possible, but it's an overkill). 2) Apply [1] to your dnsmasq. 3) Your ISP gets a TLS tunneled DNS request (and they can't do anything about it), you get unmolested name resolution. stunnel can be replaced with ipsec or openvpn or wireguard. Whatever you use as a caching DNS on your end does not matter, as long as it can forward DNS queries to another upstream DNS. Reco [1] https://kb.isc.org/docs/aa-01386
[toc] | [prev] | [next] | [standalone]
| From | Liam O'Toole <liam.p.otoole@gmail.com> |
|---|---|
| Date | 2020-04-13 17:20 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zV92q-8kG-19@gated-at.bofh.it> |
| In reply to | #221391 |
On Mon, 13 Apr, 2020 at 16:19:55 +0300, Reco wrote: > On Mon, Apr 13, 2020 at 12:14:44PM +0100, Liam O'Toole wrote: > > On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote: > > > Hi. > > > > > > On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote: > > > > [...] > > > > > > Whether DoH or DNS-over-TLS, you have to trust the DNS server. > > > > > > Yup. That's why I have my own, and every Debian user can have their own > > > too, using only free software. > > > > > > > Pray tell us more. I use dnsmasq for clients on my LAN, but even that > > has to use an upstream name server --- in my case the one provided by my > > ISP. > > 1) Rent yourself a VPS, install bind there (there's no DNS but bind). > Replace bind with unbound if you need caching-only nameserver > (caching-only bind is possible, but it's an overkill). > > 2) Apply [1] to your dnsmasq. > > 3) Your ISP gets a TLS tunneled DNS request (and they can't do anything > about it), you get unmolested name resolution. > [...] Thanks for the detailed information. I'm not familiar with bind. Does it work by consulting root name servers directly?
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-13 17:40 +0200 |
| Subject | Re: DOH |
| Message-ID | <zV9lL-8ra-11@gated-at.bofh.it> |
| In reply to | #221406 |
Liam writes: > I'm not familiar with bind. Does it work by consulting root name > servers directly? It starts with the root servers and builds a database in exactly the same way your ISP's DNS server does. In fact, it is probably what your ISP uses. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | "Liam O'Toole" <liam.p.otoole@gmail.com> |
|---|---|
| Date | 2020-04-14 22:10 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVA2B-5l-9@gated-at.bofh.it> |
| In reply to | #221411 |
On Mon, 13 Apr 2020 at 16:37, John Hasler <jhasler@newsguy.com> wrote: > > Liam writes: > > I'm not familiar with bind. Does it work by consulting root name > > servers directly? > > It starts with the root servers and builds a database in exactly the > same way your ISP's DNS server does. In fact, it is probably what your > ISP uses. I see. I have two reservations about the approach advocated by Reco above. Maybe I'm not seeing some part of the big picture. 1. The risk of DNS snooping is merely shifted from the ISP to the VPS provider. 2. Having completed a DNS lookup unbeknownst to the ISP, we still have to make a connection to the resulting IP address through the ISP's gateway. The ISP can perform a reverse DNS lookup of the IP address if they are determined to snoop. Of course, the above can be mitigated using tor or a VPN, but setting up your personal bind instance doesn't achieve much on its own.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-04-14 22:50 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVAFj-iY-5@gated-at.bofh.it> |
| In reply to | #221554 |
Hi. On Tue, Apr 14, 2020 at 06:25:24PM +0100, Liam O'Toole wrote: > I have two reservations about the approach advocated by Reco above. > Maybe I'm not seeing some part of the big picture. > > 1. The risk of DNS snooping is merely shifted from the ISP to the VPS provider. Usually you have a limited number of ISPs to choose. You have the whole Internet of VPS providers. Choose one that does not screw with your traffic, and if you don't like that one - there's always another. > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have > to make a connection to the resulting IP address through the ISP's > gateway. The ISP can perform a reverse DNS lookup of the IP address if > they are determined to snoop. And that is why it's important to use DNS over TLS. Unless your ISP can magically decrypt TLS on the fly, the scenario you're describing is impossible. Reco
[toc] | [prev] | [next] | [standalone]
| From | Liam O'Toole <liam.p.otoole@gmail.com> |
|---|---|
| Date | 2020-04-14 23:30 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVBi1-Qn-1@gated-at.bofh.it> |
| In reply to | #221556 |
On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote: [...] > > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have > > to make a connection to the resulting IP address through the ISP's > > gateway. The ISP can perform a reverse DNS lookup of the IP address if > > they are determined to snoop. > > And that is why it's important to use DNS over TLS. > Unless your ISP can magically decrypt TLS on the fly, the scenario > you're describing is impossible. I think you misunderstand me. I'm talking about making a connection to an IP address that you have already obtained by (encrypted) DNS. For example, your personal bind instance tells you that www.debian.org resolves to 130.89.148.77. Assuming you then connect to that IP address through your ISP, there's nothing to stop them performing a reverse DNS lookup on it.
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2020-04-15 00:00 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVBL4-10A-5@gated-at.bofh.it> |
| In reply to | #221559 |
On Tue, 14 Apr 2020 22:26:09 +0100 Liam O'Toole <liam.p.otoole@gmail.com> wrote: > On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote: > > [...] > > > > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have > > > to make a connection to the resulting IP address through the ISP's > > > gateway. The ISP can perform a reverse DNS lookup of the IP address if > > > they are determined to snoop. > > > > And that is why it's important to use DNS over TLS. > > Unless your ISP can magically decrypt TLS on the fly, the scenario > > you're describing is impossible. > > I think you misunderstand me. I'm talking about making a connection to > an IP address that you have already obtained by (encrypted) DNS. For > example, your personal bind instance tells you that www.debian.org > resolves to 130.89.148.77. Assuming you then connect to that IP address > through your ISP, there's nothing to stop them performing a reverse DNS > lookup on it. To prevent that that I suppose you'll also have to setup a VPN to your VPS ... Celejar
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-15 01:10 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVCQO-1SW-3@gated-at.bofh.it> |
| In reply to | #221559 |
Liam writes: > I think you misunderstand me. I'm talking about making a connection to > an IP address that you have already obtained by (encrypted) DNS. For > example, your personal bind instance tells you that www.debian.org > resolves to 130.89.148.77. Assuming you then connect to that IP > address through your ISP, there's nothing to stop them performing a > reverse DNS lookup on it. What is your threat model? -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Liam O'Toole <liam.p.otoole@gmail.com> |
|---|---|
| Date | 2020-04-15 01:30 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVDa9-1ZH-1@gated-at.bofh.it> |
| In reply to | #221563 |
On Tue, 14 Apr, 2020 at 18:00:41 -0500, John Hasler wrote: > Liam writes: > > I think you misunderstand me. I'm talking about making a connection to > > an IP address that you have already obtained by (encrypted) DNS. For > > example, your personal bind instance tells you that www.debian.org > > resolves to 130.89.148.77. Assuming you then connect to that IP > > address through your ISP, there's nothing to stop them performing a > > reverse DNS lookup on it. > > What is your threat model? I don't have one. I'm simply querying the approach advocated above by Reco.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-04-15 09:00 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVKbD-6h9-3@gated-at.bofh.it> |
| In reply to | #221559 |
Hi. On Tue, Apr 14, 2020 at 10:26:09PM +0100, Liam O'Toole wrote: > On Tue, 14 Apr, 2020 at 23:42:48 +0300, Reco wrote: > > [...] > > > > 2. Having completed a DNS lookup unbeknownst to the ISP, we still have > > > to make a connection to the resulting IP address through the ISP's > > > gateway. The ISP can perform a reverse DNS lookup of the IP address if > > > they are determined to snoop. > > > > And that is why it's important to use DNS over TLS. > > Unless your ISP can magically decrypt TLS on the fly, the scenario > > you're describing is impossible. > > I think you misunderstand me. I'm talking about making a connection to > an IP address that you have already obtained by (encrypted) DNS. I misunderstood you indeed. While it's true that this particular threat is something that DNS over TLS cannot guard against, I suggest you to consider this: 1) Not every IP on the Internet has PTR record. 2) There are multiple cases of sharing the same IP between multiple sites (including HTTPS). 3) For HTTPS (and TLS in general) there's more precise method called SNI snooping (there's TLSv1.3 against *that*, but it's not widely adopted). Reco
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-13 17:30 +0200 |
| Subject | Re: DOH |
| Message-ID | <zV9c6-8nT-31@gated-at.bofh.it> |
| In reply to | #221368 |
Andrei writes: > Whether DoH or DNS-over-TLS, you have to trust the DNS server. You have to trust the root zone but you needn't trust any single server other than your own with every single query. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-14 00:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVg3U-4c1-1@gated-at.bofh.it> |
| In reply to | #221362 |
On 4/13/20, Reco wrote: > Hi. Hi > 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 Not that I understand my ISP's privacy policy, but I don't see anything like [will not] sell, license, sublicense, or grant any rights to user data to any other person or entity. in my ISP's privacy policy. So at least in that sense, handing my data to Cloudflare is better than letting my ISP have it. >> > 1) One can use a local resolver with the ability *not* to resolve >> > certain DNS queries, which refer to the sites which just happen to >> > contain advertisements, fingerprinting, tracking, cryptomining etc. >> > Since all two major browser makers (Google and Mozilla) happen to rely >> > on revenue generated by advertising *and* users' browsing habits this >> > obviously can not be tolerated. >> >> Wasn't there a fairly recent kerfluffle about an upcoming change to >> chrome that would break things like the uMatrix addon? > > There was, indeed. > > >> 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 don't use chrome, so I don't follow what they're doing other than reading the occasional news article. >> > 3) Bad guys and gals can hijack DNS too, to the usual hilarious >> > results. >> >> And the bad guys and gals can use DOH to "hide" their traffic and >> circumvent things like pihole. > > There is tor or i2p for *that* already. Right. Again :) >> I just did a quick search and couldn't find anything for smart TVs >> using DOH. > > Probably because they aren't there yet. A typical smart TV is based on > the Android, and Google haven't said their word about DOH so far. > > >> > 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) > As far as the whole > Internet goes - not so much as overall security of DNS queries depends > of DNSSEC implemented in every zone (and it ain't there yet). Unfortunately, yes. DNSSEC adoption is way below where I was hoping it'd be. >> 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? 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? >> 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? Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-04-14 08:20 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVn5o-xI-3@gated-at.bofh.it> |
| In reply to | #221462 |
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. 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. > >> 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. > >> > 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. > >> 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. > >> 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. And it's possible to sidestep GDPR just by injecting "trusted partners'" ads in users' HTTP traffic, for instance. Reco
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-14 13:10 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVrC1-3l9-1@gated-at.bofh.it> |
| In reply to | #221473 |
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
[toc] | [prev] | [next] | [standalone]
| From | nito@dismail.de |
|---|---|
| Date | 2020-04-14 13:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVseJ-3yv-1@gated-at.bofh.it> |
| In reply to | #221498 |
On Tue, Apr 14, 2020 at 07:06:05 -0400, Lee wrote: > 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. Some non-profit organisations here operate public non-logging[1] DNS servers. They all support DoT, only some support DoH. But none of them would have enough resources to serve all Firefox users in the world though. --- Nito [1]: Only malformed queries are logged for diagnosis.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2020-04-14 14:10 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVsy6-3UO-5@gated-at.bofh.it> |
| In reply to | #221504 |
On Tue, Apr 14, 2020 at 01:48:24PM +0200, nito@dismail.de wrote: > On Tue, Apr 14, 2020 at 07:06:05 -0400, Lee wrote: > > 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. > > Some non-profit organisations here operate public non-logging[1] DNS servers. > They all support DoT, only some support DoH. > But none of them would have enough resources to serve all Firefox users in the > world though. I really don't understand the appeal of this approach on a Linux users' mailing list. The amount of technical knowledge and effort that it takes to run your own caching resolver and point resolv.conf to 127.0.0.1 is only *slightly* greater than the amount of technical knowledge and effort that it takes to point resolv.conf to "some global caching resolver that is like 8.8.8.8 but theoretically more trustworthy, maybe". In both cases, the major issue is getting isc-dhcp-client and network-manager and other such things to leave your resolv.conf the hell alone after you edit it. See <https://wiki.debian.org/resolv.conf> for help with that. Installing a caching resolver is pretty simple. Editing /etc/resolv.conf is likewise pretty simple, or *should* be for anyone on this mailing list.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-04-14 15:30 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVtNw-4AX-3@gated-at.bofh.it> |
| In reply to | #221498 |
On Tue, Apr 14, 2020 at 07:06:05AM -0400, Lee wrote: > >> 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. Probably. But I fail to see how a court order will prevent such data leak in the described scenario. > > 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 frank, then you have your own DNS, there's little need to be interested in others' privacy policies. > 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. I disagree. Cloudflare serves 10-20% sites on the Internet world-wide already. There's no need to trust them to do DNS resolution on the top of it. > 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? I do it the same way as Debian does, from the same sources (but with the custom patches on top on them). So, chromium version 81.0.4044.92 contains: 1) 5412 assorted python scripts, which are executed during the build process (maybe not all of them). 2) 16299 javascript files, but those are definitely not required by the build process. Since I do it for the Linux only, I could not care less if the source tree contains EXEs, DLLs or other Windoze artifacts. I'm definitely sure that there are no ELF executables there or pre-built .so and .a files. I should note, however, that Debian's chromium source is sanitized, and certain parts of the source tree are deliberately removed. > In other words, how trustworthy is your 'built from source code' > chromium? Have you done any testing to see if it "phones home"? YES! In fact, I do it after every update (once a month on average), and check periodically just for the fun of it. The answer is - the only connections it does without my intervention are "trial experiment downloads" (it's clients[0-9].google.com), so I'm looking for a patch to disable *that* too (currently I'm merely blocking it). Check out [1] if you're interested, that patchset rocks. Combining it with Debian chromium patches is an interesting exercise though. > >> > 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? I won't answer that. Privacy. > >> >> 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? If it bothers you (it does bother me), you probably should not take DoH as your only means of defence. An ipsec tunnel to a throwaway VPS served me well so far, for instance. > > 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 curl is ahead of Firefox in this regard. But it's a good list, something one could consider for blocking the controversial feature. > >> >> 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? I won't call it "selling" per se. It's rather "we provide our sub-contractors with the data to increase the value of our services, and we're closing collective eyes on what the contractors are doing with the data". I cannot disclose any names here. Reco [1] https://github.com/Eloston/ungoogled-chromium
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-14 17:40 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVvPk-5Oe-15@gated-at.bofh.it> |
| In reply to | #221514 |
Lee wrote: > 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. Reco writes: > Probably. But I fail to see how a court order will prevent such data > leak in the described scenario. The point is that if there is a court order then the data *will* be handed over regardless of what the contract says. "But I promised this guy that I'd wouldn't reveal his secrets to the government" carries no weight in court. The clause makes it clear that data will be handed over if and only if there is a court order. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2020-04-14 05:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVkAx-7fm-1@gated-at.bofh.it> |
| In reply to | #221362 |
On Mon, 13 Apr 2020 08:47:22 +0300 Reco <recoverym4n@enotuniq.net> wrote: > Hi. > > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: ... > > I just did a quick search and couldn't find anything for smart TVs > > using DOH. > > Probably because they aren't there yet. A typical smart TV is based on > the Android, and Google haven't said their word about DOH so far. I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT), but just to clarify for the record, they have implemented the latter: https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/ https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/ Celejar
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-14 11:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVqmB-2pY-5@gated-at.bofh.it> |
| In reply to | #221472 |
On 4/13/20, Celejar wrote: > On Mon, 13 Apr 2020 08:47:22 +0300 > Reco <recoverym4n@enotuniq.net> wrote: > >> Hi. >> >> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: > > ... > >> > I just did a quick search and couldn't find anything for smart TVs >> > using DOH. >> >> Probably because they aren't there yet. A typical smart TV is based on >> the Android, and Google haven't said their word about DOH so far. > > I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT), > but just to clarify for the record, they have implemented the latter: > > https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/ > https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/ > Yes, DNS over HTTPS specifically is the concern. DNS over TLS uses a specific port (that they could change, yeah, i know) that I have blocked, so I'm not all that concerned about DoT. Regards, Lee
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web