Inside Firefox’s DNS-over-HTTPS engine • Hacker News Board

Re: Inside Firefox’s DNS-over-HTTPS engine

#11

Post by greglindahl » Mon, Jun 04, 2018, 3:40 AM UTC

peterwwillis wrote: post #7

niftich wrote: post #3

Earlier quoted context omitted.

Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers. [1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https

You think regular end users having to set up and maintain server software in order to force a name for an IP is going to become a widespread pattern? That's horrifying. I don't want to live in that world.

Regular users today don't use that feature, so you're choosing a rather odd hill to die on.

To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.

Re: Inside Firefox’s DNS-over-HTTPS engine

#12

Post by da_chicken » Mon, Jun 04, 2018, 3:56 AM UTC

greglindahl wrote: post #11

peterwwillis wrote: post #7

Earlier quoted context omitted.

You think regular end users having to set up and maintain server software in order to force a name for an IP is going to become a widespread pattern? That's horrifying. I don't want to live in that world.

Regular users today don't use that feature, so you're choosing a rather odd hill to die on. To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.

There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.

Re: Inside Firefox’s DNS-over-HTTPS engine

#13

Post by greglindahl » Mon, Jun 04, 2018, 4:02 AM UTC

da_chicken wrote: post #12

greglindahl wrote: post #11

Earlier quoted context omitted.

Regular users today don't use that feature, so you're choosing a rather odd hill to die on. To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.

There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.

And what market share do they have? None of my non-techie relatives or friends who've asked me to look at their machines run that kind of software.

Re: Inside Firefox’s DNS-over-HTTPS engine

#14

Post by greglindahl » Mon, Jun 04, 2018, 4:03 AM UTC

peterwwillis wrote: post #9

riquito wrote: post #8

Earlier quoted context omitted.

> will be an absurd hassle for a very large number of organizations they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file

This isn't an acceptable compromise. In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of…

I wanted this feature.

Re: Inside Firefox’s DNS-over-HTTPS engine

#15

Post by Immortalin » Mon, Jun 04, 2018, 4:14 AM UTC

peterwwillis wrote: post #7

niftich wrote: post #3

Earlier quoted context omitted.

Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers. [1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https

You think regular end users having to set up and maintain server software in order to force a name for an IP is going to become a widespread pattern? That's horrifying. I don't want to live in that world.

It's easier than ever to host a server transparently for end user software. You don't hear users complaining about node.js running in most Electron apps. A http server for DNS can easily be compiled to binary and ran like any other system daemon.

Re: Inside Firefox’s DNS-over-HTTPS engine

#16

Post by mortenlarsen » Mon, Jun 04, 2018, 4:27 AM UTC

greglindahl wrote: post #13

da_chicken wrote: post #12

Earlier quoted context omitted.

There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.

And what market share do they have? None of my non-techie relatives or friends who've asked me to look at their machines run that kind of software.

Only the use case with the largest market share matters?

That kind of thinking, really irks me.

Re: Inside Firefox’s DNS-over-HTTPS engine

#17

Post by greglindahl » Mon, Jun 04, 2018, 4:29 AM UTC

mortenlarsen wrote: post #16

greglindahl wrote: post #13

Earlier quoted context omitted.

And what market share do they have? None of my non-techie relatives or friends who've asked me to look at their machines run that kind of software.

Only the use case with the largest market share matters? That kind of thinking, really irks me.

No, I don't think like that.

It does bother me when Firefox introduces a feature which covers up a huge hole in TLS, and they get a large number of complaints on HN.

Re: Inside Firefox’s DNS-over-HTTPS engine

#18

Post by oger » Mon, Jun 04, 2018, 4:29 AM UTC

Nice job Daniel (again...)! While TRR only sounds very appealing for certain threat vectors the handling of captive portals is still a ‚nasty‘ thing. While certainly not in the realm of DNS over HTTPS the logic / UX on the browser side as well as interaction with the underlying OS definitely needs improvement.

Re: Inside Firefox’s DNS-over-HTTPS engine

#19

Post by caf » Mon, Jun 04, 2018, 4:40 AM UTC

da_chicken wrote: post #12

greglindahl wrote: post #11

Earlier quoted context omitted.

Regular users today don't use that feature, so you're choosing a rather odd hill to die on. To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.

There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.

OK, but software like that can easily include an internal DOH proxy (or just turn off DOH in Firefox).

Re: Inside Firefox’s DNS-over-HTTPS engine

#20

Post by dogecoinbase » Mon, Jun 04, 2018, 4:46 AM UTC

greglindahl wrote: post #14

peterwwillis wrote: post #9

Earlier quoted context omitted.

This isn't an acceptable compromise. In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of…

I wanted this feature.

No, you wanted encryption for DNS transport, and I completely agree with that desire. This is a terrible half-measure that bypasses many existing security precautions people have intentionally taken by default, and moreover exposes private data to a company with a history of handling such poorly.