> some of these devices are using a sneaky tactic to bypass your PiHole entirely
I don't think that it's malevolent on their part. Lots of ISP DNS are crappy. Hardcoding a reasonably reliable one saves them a lot of frustration and unnecessary technical support.
So if every single piece of hardware or software followed this one crazy trick the world would be better because some people at a tech company wouldn’t have to field as many support questions?
Yes, support is supremely expensive. This is especially true in the hardware IoT space under discussion. Some large fraction of any semi-successful hardware company will exist to field a constant onslaught of support emails, handling returns, warranties, and social media. It’s a big money sink.
Margins are already razor thin in hardware, so yeah anything that can be done to reduce your support costs is welcomed.
I worked in support a long time and yes it's expensive. A few support cases will destroy your margin on a product sold.
However, these IoT companies add these features mainly to benefit from selling the acquired data. The users are not asking for this. They're making it difficult for themselves.
I agree. I have support costs too. Which is why every company that sells a product with a hard coded DNS server configured but doesn't advertise said aspect prominently in all advertising, so I can know to avoid their intentionally defective product, should pay me $10000 for the time I wasted buying their product, discovering their product is secretly and intentionally broken, and then return their product.
Why would they advertise this feature? The device isn’t broken, it’s not violating any standards, devices aren’t required to accept DNS servers offered by DHCP — my laptop doesn’t for any network that isn’t my home.
This is done because the manufacturer’s and public DNS servers are more of a known quantity then you ISPs router and DNS servers. Using pihole is super rare and wouldn’t be worth the effort if it weren’t for the fact that it makes devices more reliable.
Devices that don't use the DNS servers specified by the DHCP server I have configured on my network most certainly are broken. I'm not talking some kind of principle here, I mean they literally will not resolve addresses correctly as I have configured a split horizon DNS environment for DNS names that I control. I have no interest in exposing many of the names on my network to the public so that 8.8.8.8 can resolve them.
Saying that a device is not violating any standards as they "aren't required to accept DNS servers offered by DHCP" is like saying a device is not broken and not violating any standards because "they aren't required to accept IP addresses offered by DHCP." It's a silly to say devices are not required to accept the parameters sent by my DHCP server as such a statement is only correct in the most abstract sense that there is no law that requires a device to adhere to the relevant RFCs for DHCP. On the other hand there are laws, federally and in many states, that only allow you to connect to and use other people's network with their permission and only use their networks within the bounds that they allow.
I don't care about the device manufacturer's opinion of DNS server quality. I own the device and I own the network that the device is connected to and I pay for the uplink between that network and the rest of the internet. There is only one person who can correctly make an assessment as to the correct DNS server for my network and that is me. If a device manufacturer chooses to hard code a different DNS server they are wrong and it is broken and they should tell me so I don't waste my time buying their product and returning it.
Additionally they should advertise this behavior because it is a security vulnerability for my network for their shitty device to be sending my internal names to outside servers to resolve. The names of the devices on my network that I choose not to expose to the internet are no business of anyone else.
E: And I didn't even get into the mess that it would be to try and expose the DNS zones for the RFC 1918 address spaces that everyone is using.
It is because they don’t give you the option to change it. Set the default to what ever you want, but give me the user who bought the goddamn thing the option to configure it how I see fit. You think TV companies are injecting adverts into peoples TV home screens for their benefit, I don’t see a big sticker on the box when I buy the TV “Ads Integrated Directly into Device”
So as a techie I agree with you but as a user I don’t really think it matters. If your device exists to connect to public endpoints and uses mDNS for local discovery then any public DNS server should be fine. All these devices want is a clean connection to the public internet and you’ll never see them officially supporting blocking. At best DNS filtering is a hack that currently works because most people don’t do it and there’s little pressure to work around it. The device is free to exfiltrate all your private data through the connection to the manufacturer’s servers. It doesn’t really need DNS to do it.
I bought the device to stream content not to display ads. So you'd be happy if every laptop manufacturer installed crypto-miners on a new laptop you purchased without telling you before purchasing the device with no way to remove it.
It's no different than ads, they are using your resources without your explicit permission after the sale of the device to generate income for their company.
It's madness to me that people find this acceptable. These companies are profiting off the ignorance of people and misleading customers on what they're actually selling them.
As a techie and a possible user, I agree that I'd like that feature.
As someone who has/might work for companies building things like that, it sounds like a nightmare. It's a ton of design, testing, translation, validation, etc work to build the UI for adjusting optional settings. And it has to be maintained and tested through all future versions, redesigns, refactorings, etc. It's gonna be a tough sell to do it right considering:
For every 1 techie who legitimately uses it to set it to his custom server and can handle debugging when it goes wrong, 50 people will accidentally set it to something random, or have some distant relative set up some weird hack and then disappear when it breaks, and then call the support line and rage at somebody when it doesn't work and they don't understand why, and rage some more when they can't get the instructions to reset it right.
Whatever feature somebody else is about to propose to fix that is yet another thing that will need design, validation, maintenance, etc forever. It's pretty understandable why product designers would rather build simple dumb UIs with no options that mostly work automatically.
The point is I wouldn't have to change my DNS if they didn't inject adverts into my homepage. When I bought the TV there was no mention of Adverts included.
Amazon sold two versions of their kindle, one with and one without ads, not an issue for me. As customer the pro/con relationship is clear. I get what I pay for.
These ads slow down my TV, waste electricity, waste my time more importantly. It's not my problem as a customer if other people mis-configure their TV and have to call support, that's a UX problem, I've never met anyone who has mis-configured their DNS on their phone. If you've updated your DNS on your TV before it's a very long process, using arrow keys to select characters, it's not something you accidentally do.
I paid for a TV and I didn't get what was advertised. The argument that they do it to protect dumb users is non-sense because the TVs that don't have this configurable in the settings are the ones mainly bundled with ads.
Most important, TV ads also may show scary or sexually suggestive material to my young children because the TV doesn't know how or when to be more discreet.
I’m responsible for a bunch of IoT hardware, and every firmware spec I write includes a note on not using the DNS servers provided via DHCP. While sure there are companies explicitly doing this to avoid filtering, at least in my case it’s because a significant proportion of DHCP servers are configured to send DNS to your ISP, and ISP provided DNS is almost universally terrible. They’ll ignore TTLs, rewrite NXDOMAIN responses into the IP address of their ad-laced web search, and occasionally just highjack every single query to send you to a page saying you’re approaching your bandwidth quota. In the face of that sort of behaviour you inevitably end up with technical support having to field angry customers who just don’t get that it’s not our fault the hardware isn’t working, and the response to that is hardcoding a set of known good DNS servers which we can rely on.
Please, if you have a Pihole, redirect all DNS through it as described in the article. Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
You're right to be suspicious. The DNS-over-HTTPS model favors those who run the servers (because they get exclusive access to monetizable end user name resolution data) and those who control the resolvers.
You might control the resolver on your personal computer (for now). You probably don't control it on your phone. You most likely won't control it on your embedded devices.
The root evil here is that you can't change the root certificates in such devices. Even if you controlled its DNS, the device could still just be programmed to fail if it doesn't reach its analytics/ad/whatever server.
You can go back from network settings back to settings or something like this. just poke around.
Discovered it when comcast went down for 4 days and wanted to run kodi on firetv
Amazon also tends to hide options until you "try" connecting to your network. My device refused to work without internet until I "tried" connecting to my network using an incorrect password. When I did that and the device failed, an option to skip network setup appeared. In small font at the bottom of the screen, of course.
The IKEA Tradfri "smart" lighting gateway will stop responding to commands if it can't phone home to some IKEA server. I noticed this when I changed my router to use NextDNS, which blocked the IKEA lookups. I was ready to return the device as broken until I realized this. I've also had issues with Bang & Olufsen speakers in the past, and inclined to believe it's for the same reasons.
I think it's insane that devices can effectively be bricked if they can't phone home. It's nothing short of waste, and I think environmental legislation should require device manufacturers to supply ways of disabling or overriding these mechanisms such that devices can continue to operate regardless of whether home servers are blocked or otherwise out of reach, e.g. company goes belly up, censorship etc.
I tend to cut DJI a break, because customer (non-)compliance with no-fly zones is a class-1 existential threat to their business selling consumer drones. Pinging DJI servers to check for altitude restrictions at every power-up cycle is intrusive, but I honestly don't see that they have much choice.
When I installed PiHole a few years back I blocked my tradfri gateway from connecting to Ikea's servers and everything kept working! I wonder if something has changed since then? Ikea devices are kind of nice because they don't actually rely on the internet at all and work completely locally (at least, they did a few years back).
All I can say is when I had NextDNS configured on my router it blocked requests to some IKEA domain, possibly smetrics.ikea.com from a cursory search through he logs, and my Tradfri gateway would just straight stop responding to anything at that point. I googled around for a while and found other people having issues with DHCP and QoS with Tradfri gateways, so I made sure it had a static IP set as well as all QoS “features” being disabled, but this didn’t help. It would work at first, for some period of time (30 min maybe?) and then stop responding. Once I saw the blocked DNS lookups I disabled NextDNS on the router and flushed any caches on the router, rebooted everything and it’s worked fine now for a good month or so.
I will admit I haven’t done any further investigation, but simply concluded that the gateway at some point started phoning home and if it didn’t receive a response went into some catatonic state. Maybe I’ll dig deeper at some point, time permitting.
I believe that Google pushed DoH to track your cross-site browsing. TLS hides your URL, and blockers can break adsense tracking and/or any other call-home backlinks.
Using DoH, especially one served by an advert company is just signing up to be their open book.
Chrome didn't change the resolver, though. It just enables DoH if it's on a whitelist of known DoH-capable resolvers. It doesn't send your data to Google unless you already used Google's DNS.
I still prefer DoH giving "exclusive" access to resolvers, because the alternative is sending that data in plaintext for everyone along the path to read?
If your ISP is large enough it is only sent to ISP's name server which probably has everything you need cached, and if it isn't it might blend in with other queries. And your ISP can sniff SNI or guess target domains from target IPs already.
> The DNS-over-HTTPS model favors those who run the servers (because they get exclusive access to monetizable end user name resolution data)
Hold up. You are claiming that the fact that DoH prevents DNS requests from being visible in cleartext network traffic is a bad thing?
...what? In a world where the choice is between one party (the DNS provider) having access to my DNS requests and everyone on the network including my DNS provider having access to my DNS requests, I'll choose "DNS provider having exclusive access" every single time.
Hold up. You are claiming that the fact that DoH prevents DNS requests from being visible in cleartext network traffic is a bad thing?
It is when its my network. If they cared about people sniffing they would use DNSSEC, but still use the network DNS server. DNS over HTTPS is just a way for shady companies to hide what they're doing.
At this point it is really tough to find devices that don't leak data like a sieve.
I recently bought a car, and could not find one without a cellular modem and microphones. Removing the modem voids the warranty. The period where you can opt out is mostly over.
The Magnuson–Moss Warranty Act of 1975 ensures that’s not the case in the US. I suspect something similar is true in EU.
For the manufacturer to avoid a warranty claim due to a modification or aftermarket part, they must show that the defect was linked to the part or modification.
They might have to show that it was caused by, but in any case, if your paint fails prematurely, they can’t say your warranty is void because you disabled the cell connection.
To get 5 stars by EuroNCAP (and AFAIK EU law demands it too) the car have to call 911/112 automatically if it detect a crash. I doubt you can remove telemetry without also disabling this. If you do the car is illegal.
Because it is probably part of the vehicle type approval, it would be a modification that needs to be authorized by whatever institution does that in your country.
Otherwise it is probably mostly equal to driving without registration. It may not be a felony, but it will be fined.
Given what I see driving around on US roads, there is epsilon-squared chance this would be found let alone fined here. (I’m also not nearly convinced that it’s even illegal in my state and likely not so in any of them, especially given that my car had a dealer service to remove the SIM card as a recall item.)
It definitely wouldn't be illegal to remove a vehicle's cell modem from your own car in the US. The US is very friendly to vehicle modifications compared to much of the world. At a federal level, pretty much the only thing you cannot do to your own vehicle is remove emission equipment. The US does not even have universal requirements for insurance or safety inspections. And even in the states that do have safety inspections, there are typically very few pieces of safety equipment that are required.
Theoretically illegal perhaps but I'd be very very surprised if this ever actually gets picked up by anyone even on an annual roadworthiness inspection. Maybe during some OEM servicing but then again maybe not.
Interesting point. I wonder if an insurance company can argue the modification made the car lose the safety certification, and in effect the user made the car more dangerous by removing the SIM card, and that it would not pay out for injuries sustained in a crash.
It's not just shitty devices. By putting it on the HTTP layer which usually is even available to sandboxed applications they made it possible for every single application to bypass your own resolver. Pretty much a trojan horse.
I've hated DoH from the beginning, and not just because shoehorning everything into http is a silly idea, but as I suspected, we now live in a reality where you have to keep an adblock-esque list of DoH servers. Now you have yet another internet arms race.
DNS based blocking was already trivially bypassable before DoH was ever conceived so I don't see how DoH or its use by browsers is at fault for that problem.
As mentioned in TFA, configuring a firewall to redirect DNS traffic from broken or malicious software is also trivial. Or are you talking about hardcoding IP addresses?
There are plenty of other alternatives. The simplest (but least flexible) would be hardcoding an IP of the final server.
Somewhat more sophisticated would be hardcoding an IP to a server with a REST endpoint that returns the real final IP. (Basically just like what DoH does, but without calling it DoH).
Even more sophisticated would be hiding the final IP on some kind of public web service like Twitter or Github.
Note that malware of various sorts has done all of this for years. It used to be reasonably common to get command/control server info via IRC, basically DNS over IRC. DNS blocking has never been an effective network management strategy, and it never will be.
Should be done by your host/gateway/router, not each client app.. Same goes for SSL SNI filtering if that ever gets accepted... router should know where requests are going...
Currently we’re using both Google and Cloudflare’s DNS, providing resiliency against one or the other being unavailable, but I’m looking at potentially using our own resolvers just to reduce the amount of data being exposed to third parties.
So the company you work for will be fighting for my privacy? I'd rather have a PiHole doing that.
These devices do usually have an UI. Why not provide some options to the user? Let him choose among different types and providers. I'd set mine to use the one provided by DHCP or enter the address of my resolver manually.
Have you ever had to do technical support for someone who changed settings they didn't understand? Or maybe someone who decided to "clean up" a bunch of system files that they thought were wasting space?
In my experience, product design is generally done with a well-meaning attempt to protect the average user from themselves. People who can and do manage their own networks in sophisticated ways are, unfortunately, far less common than people who have no idea that their ISP fscks with DNS lookups.
Personally, I'd bury this setting pretty deep in an advanced-usage-only tab and behind a notice SCREAMING about how using these settings is unsupported. And then tell support staff that they are not obligated to support whatever crazy configurations people cook up for their home networks.
I understand not doing it at all. A few people will complain, but the number of people who will refuse to buy a TV because it doesn't play nice with their pihole is almost certainly too small to register on any material financial statement, and attempting to please them will generally run into some other point they are unwilling to budge on. The number of people who screw up an advanced setting they don't understand will show up in support costs.
My company makes IoT systems to support low power devices that use mobile (NB-IoT and LTE-M) connectivity and we have some similar problems having to do with mobile networks and APNs.
The way we solve this is that we assume any knowledge the device has about the outside world can become obsolete, so we do we have a two layer approach.
The bottom layer is that we have a set of semi hard-coded fallback values that are likely to work in the forseeable future. Updating these fallbacks requires an over the air firmware upgrade which isn't a terribly big deal since we regularly upgrade firmware over the air. The goal of these values is to make sure we can get the device online and direct it to somewhere where we can trigger firmware updates.
The second layer is that one or more times per day we ping a config server that sends a packet with configuration data to the unit. This is typically API endpoints etc. The configuration data is essentially a prioritized list of resources, so if one won't respond it will go to the next on the list (while still trying to determine if a higher priority resource becomes available).
Last week we got a chance to see how this failed over beautifully as multiple resources were removed and a fleet of devices just adapted as they should. (The shutdown of these resources were planned, but presented a good opportunity to do a fire drill).
How do you deal with NAT64? It's a real thing with some consumer ISPs.
I can see myself using it as well, maybe even just to see which devices don't use DNS.
Here's another idea: generate a unique IPv6 address per DNS request, route them to the correct destination, filter other IPs. Not really scalable, but usable on small networks/VLANs.
Not the OP, but you should also be reminded that many of these limitations are brought out by cost-cutting measures that we didn't have control of and could be used to fire us immediately, and even when IPv6 is implemented most IoT backend servers only operate over IPv4 anyway. Another one that you might be angry about is only including 2.4GHz-band WiFi even though 5GHz WiFi is already ubiquitous (although only including 5GHz WiFi is much more questionable ;).
Exactly this, we’re a small team and have to pick our battles. In practice very few people have IPv6 only connections, and even fewer of the people who buy our products.
Sony did the same thing with a Blu-Ray player for NTP, effectively DDoSed that particular box because they also didn’t think to stagger the polling so like clockwork millions of consumer devices would check in at the same time nightly. From what I gathered from the electronics guys a few floors down they eventually resolved that in later revisions, or so I was told.
I worked on an IoT platform for a while that struggled with this. Our workaround was to tell support to tell people to not set automations to run on the quarter, half, 3 quarters or hour mark. Something set to run at 7:14 or 7:16 PM would run every night, something set to run at 7:15 was a crapshoot.
> Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
I wonder who's the first sponsor for that thing, dns-over-https...
> and ISP provided DNS is almost universally terrible. They’ll ignore TTLs, rewrite NXDOMAIN responses into the IP address of their ad-laced web search, and occasionally just highjack every single query to send you to a page saying you’re approaching your bandwidth quota
Universally? Perhaps in the US? But IoT devices are sold worldwide.
While I do run my own recursive resolver I checked my ISP's and they're behaving fairly reasonable and do none of the above and I have a direct (contractual) relationship with them and we reside in the same jurisdiction so at least in principle I could apply pressure to them if they do something shady. The same can't be said about google or cloudflare.
> Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
I'm sure google had only our best interests in mind when unleashing that on us.
It’s not just the U.S. A problem report once lead me to discover that the Spanish company Telefónica cached DNS results for years longer than the TTL. My error monitoring also picked up content injection (prior to HTTPS) and DNS hijacking around the world.
Before going with the conspiratorial take note that Mozilla shipped DoH early and both Microsoft and Apple implemented it. Untrustworthy ISPs are a real problem even if Google deservedly gets suspicion about their motives. This isn’t another AMP.
> At this point Mozilla is just the Non-profit Arm of Google, They do what google tells them
You can just say you don’t follow this closely. Mozilla is not perfect but they do push for privacy, with an increasingly limited amount of negotiating power.
> DoH is absolutely designed to get around network based security and filtering, both for Ad's and other reasons.
This is similarly reflecting a poor understanding of the situation. DoH can’t get around network filtering - if you block packets, there’s no magic trick to bypass it. It’s great for preventing ISPs from tampering with traffic or monitoring activity (this will also require eSNI to complete) but it’s not giving an attacker any capability they didn’t already have. If you’re concerned about security you’re fooling yourself if you don’t have endpoint management and some level of network segmentation and egress control. Attackers have hard-coded DNS servers, C&C endpoints, etc. for decades.
DoH absolutely can get network filtering: if I block port 53 outbound to control DNS queries within my network, DoH (and other tunneling technologies) is bypassing my network filtering of DNS.
By the same logic HTTPS is bypassing your network filtering of every service which happens to have an alternative available over HTTPS. So do you block HTTPS?
I would not want to use your network if that was the case, and I wonder if you similarly would use someone else's network if it was configured like that. I don't think network operators who provide access to the Internet can realistically expect to control what their users do on the Internet, unless the network operator is also the administrator of those workstations.
Maybe, but my rule is: my home network, my rules. I can’t really do this invisibly anyways: any device I don’t control will get certificate validation errors.
The problem here is even the device owner is not the "administrator" of the device as we have lost ownership rights, locked behind EULA's, Patents and copyright
The point of the original story is "your" meaning a device you own, is ignoring your network controls
it is highly unlikely that the TV manufacturer is going to allow me to install my own custom root certs to inspect their traffic to HTTPS, so yes DoH and other things are a threat to network security, because if the TV become compromised I have limited administrative controls to prevent it other the blocking it completely which is a poor response to the problem
DoH is a solution in search of a problem that can be solves in better more user friendly ways
The usual approach to setting up a firewall is a default of "block everything" and then selectively allow only what is needed.
Most people cheat and only do this on inbound connections, allowing everything on the egress side, because it's easier. But if you want to block your IoT devices from making outbound https connections, you easily can.
There's nothing really new going on here. It's always been possible to tunnel one protocol over another, or use nonstandard ports, and use encryption on the traffic to hide what you're doing.
I would absolutely love to have control over HTTPS traffic on my network, specifically to enable my Squid proxy to cache HTTPS pages, but unfortunately not every device or even program supports custom CA's. I'd be the man-in-the-middle between the internet and every device I own.
I think that is a pretty user-hostile attitude and I suspect you probably wouldn't really love it if every network operator was doing that kind of thing.
Yes, I agree that is also user-hostile, since it should be configurable. The problem is not about network policies though, since DHCP is explicitly not designed to be a policy and is purposely meant to be optional for the client.
For this reason I wouldn't recommend buying a device like the Chromecast, in which the user can't configure the network settings. Instead maybe consider something like the Amazon Fire Stick which is not as user-hostile.
Yes, but my point is that if you feel it's justified for your own network then you ought to expect every other network operator will feel that way about their network too.
So before applying that mentality, it would be wise to consider what your experience would be like if all your neighbours, friends, colleagues etc also did that on their networks.
I have no problem with that: if my workplace MITMs traffic, I’ll use my cellphone connection and a personal laptop for sensitive data. If a friend’s house mitms traffic, same deal.
Is the point that I sometimes use these networks? Then I somewhat agree - I would set up a separate guest network without shenanigans for guests to use. This avoids both the ethical sketchiness and having to explain why their web browser is shouting at them
True, that could be a good compromise. Although there are still some disadvantages like creating an SPoF for yourself and increasing your attack surface (e.g. anyone who compromises your internal CA has access to all your encrypted connections)
Network filtering means blocking traffic at the network level. Trying to use DNS for this leaves you trusting the client - and there are decades of precedent for clients bypassing that for various reasons, such as this post shows.
The solution is to start doing network filtering: if you block packets to unapproved servers, you can actually stop this. You’ll need to run your own proxy, of course, but that’s always been the only way to actually accomplish that goal.
That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy.
You’ll note that I mentioned a proxy. That’s why: you need to force all traffic through a proxy you control or you’re just hoping that a client doesn’t use hard-coded IPs or an outside API of some source. If your network allows the client to send traffic to port 443 anywhere, any blocking is on the honor system.
My question here is how are you going to install your root certificate on a $300 smart TV? Or, if that is not required because the TV does not verify DoH certificates, how bad is that for security (which we already know is awful on these devices)?
This comes back to the core decision: do you care about controlling the network enough to block access? If the device can't be managed / is no longer supported the safest choice is not to allow it online at all. Different people will have different risk tolerances – it might make sense to put, say, a remote-control power switch on an IoT no-man's land network but if it has access to personal information or cameras/microphones it's not unreasonable to say it should just be blocked unless you're actively using those features.
"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy."
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.
> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.
It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
"This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective."
If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.
That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
There isn’t an effective solution for a device which ignores local network policy other than returning it so the manufacturer pays the cost of designing a bad system.
With the side effect of your local vendor refusing to do further business with you, "the problem customer", with your "unreasonable demands" and technobable.
DNS over HTTPS has been a thing since before IETF standardized it, the technique was just in the form of a non-standardized API running on some benign domain.
Thinking about it, if you’re willing to give up TLS 1.3, you could probably just break all https connections with encrypted SNI and then filter based on the SNI information.
Just to nitpick: TLS 1.3 still uses plaintext SNI by default. You need to explicitly put public keys in DNS to enable the encrypted SNI extension.
And in the context of pihole and such, avoiding that means editing the DNS response to remove those public keys. Which takes us full circle back to "do I control DNS for this gadget, or not".
You have two choices: trust the device or don’t let it on the network. Voluntary measures like local DNS only work to the extent that the device maker wants them to.
The issue isn't network filtering, it's encryption.
Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that secure the DNS lookup. At that point, filtering will require MITM proxies, whether it's for DNS or HTTP or any other protocol.
It's a trade-off with security on the open network meaning harder penetration and control in your internal network. There's no easy answer.
DNSSEC is not encrypted. Moreover, between end systems and DNS servers --- the scenario we're discussing on this thread --- it isn't even authenticated.
Sure, DNSSEC provides authentication and integrity rather than encrypted traffic, which makes spoofing or rewriting the responses hard.
Why do you say it's not authenticated? If they're using the newer standards then that's what it provides. If they're not then there's no issue with network filtering as usual.
Again: the article discusses an environment where machines on a home network are refusing to use the DNS servers the network is configured to use. DNSSEC authenticates requests between servers. But between DNS clients ("stub resolvers") and servers ("full recursers"), there is no authentication, just a single bit in the header that says "trust me, I authenticated this data".
It doesn't matter if you're using your ISP's servers, 8.8.8.8, 1.1.1.1, or a custom server you set up on Digital Ocean somewhere: an on-path attacker can forge DNSSEC responses to you. It's a ridiculous situation.
Your technical description doesn't really respond to the meat of the critique of DoH, which is that it prevents the technique described in this article - transparent proxying for all traffic of a certain service, in this case DNS.
The problem is that your relationship with your network devices is logically the same as a totalitarian country's/company's relationship with their citizens/users. So any protocol that prevents censorship/surveillance by ISPs also impinges upon bona fide network administrators. Corporate networks have the same dynamic, although there are few tears shed when it becomes harder for them to tamper with users' traffic.
The right answer is to make sure devices that have any Internet access run code you control. The root of the problem here is buying a "smart" TV, hooking it up to the network, and then expecting to tame all of its user-hostile anti-features by policing its communication. The only way to use black box IoT devices is to remove all general Internet access from them, allowing communication only with hosts you do control. For instance I've got a network of tp-link bulbs that are all controlled from a Home Assistant instance, and they never have and never will get a packet out to the larger Internet.
My point was simply that DNS was never an effective measure. Corporate operators don’t need it since they can configure proxies and install endpoint monitoring, but the people building untrustworthy IoT devices or malware can’t be relied upon to cooperate.
I agree that the core problem here is blocking egress entirely – and that’d be a good area for home routers to add UI polish so you could easily allow your TV to hit Samsung.com if there’s an update you need before turning it back off. Unfortunately that’s going to be a losing game for many devices and that really hits at the root cause: we need strong regulation controlling privacy because trying to stop a well-funded company with purely technical measures is almost always a losing game.
Well DNS has been a pragmatic measure for quite some time. I've definitely seen jailbreaks of embedded devices that start off by MITMing DNS to proxy all traffic. DoH is changing that, and I can see how that's annoying.
> hit Samsung.com if there’s an update you need
Why would you need an update? Updates are mainly necessary for security, which you don't need if the device isn't on the Internet. If the device doesn't have all the features you expect out of the box, return it within the return period. There's a small corner case where an update could carry significantly increased functionality, but it seems easier to ad-hoc address that down the line rather than plan for it. Carelessly doing updates is a good way to break your device.
> Unfortunately that’s going to be a losing game for many devices
I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and a local modbus network.
> Why would you need an update? Updates are mainly necessary for security, which you don't need if the device isn't on the Internet.
You've never had a problem which was fixed by an update or something which added support for, say, a new model peripheral? I have, which is why I allowed for the possibility of wanting to do this on the schedule of your choosing but not the default case.
> I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and say a local modbus network.
I was thinking less narrowly than devices which never need to be online. A TV connected to other players can run entirely offline but there are many other things which legitimately need connectivity and there's no good way to prevent that. For example, think about a device like a Chromecast or Fire TV, or those Facebook video chat appliances — people buy those to stream content so the most you can do is force the vendor to send marketing stuff through the same endpoint they use for your content, and that's increasingly hard to filter (think how useful a “it goes to an IP in AWS. Block y/n?” prompt is). That's why I said it'll require a legal fix since a large fraction of the most invasive devices either already do or could trivially be modified to mix other data in with the traffic needed to function.
> You've never had a problem which was fixed by an update or something which added support for, say, a new model peripheral
For embedded devices? No. I can imagine it happening in general, but I don't think I would ever buy into a proprietary ecosystem so hard that there would be peripherals, and newly released ones at that. Still I would be cautious about doing said updates, lest they ruin the device I already have. Like I've got a newer Marantz receiver that works great and hasn't seen the Internet in several years. Even if they developed some new desirable feature, why would I want to let it reflash itself and possibly break, or even just get slower (software bloat)? I'd rather just continue using it as I bought it.
> there are many other things which legitimately need connectivity and there's no good way to prevent that
I sort things into categories. A TV would be in the category of "wtf would you ever hook that up online" - Internet access can only enable anti-features. A Chromecast is a different category - single purpose disposable device that if it turns into shit you just throw it out. Ads and surveillance are part of its price, and if your goal is to avoid them, you should just setup a Kodi box and call it a day.
Legally I don't really see what you're getting at here. I can see a law for my TV category, but leaving it disconnected or pulling the 5G modem will also solve that. How would you even begin to solve the Chromecast problem with a law? Maybe in the EU you could convince them to mandate unbundling ads from a service, but in the US exploiting consumers by shoving ads at them is one of the most popular business models. I don't see that ever changing via the legal system.
You mean actions like the Mozilla engineers advocating for users in standards groups or industry coordinating teams? Or the ones building privacy-oriented features?
You’re going to have to make a more substantial argument to get anywhere with this.
> At this point Mozilla is just the Non-profit Arm of Google, They do what google tells them....
As someone who has used (and still use Firefox) continously since around 2005 it surely feels that way sometimes and some of the decisions I see would make much more sense to me if I knew top management was somehow in Googles pocket.
(That said
1. for my workflows I still consider Firefox the best browser.
2. switching would only make it even easier for Google.
3. I always hope something will change and Firefox will become really really great again or someone will fork it.
They are in google pockets for 95% of revenue. But I think as a browser with a smaller market they join things and change things to be like everyone else.
There was a recent change to facebook picture albums that lazily loads pictures as you scroll. In large albums this grinds to a halt after a few pages and each scroll takes 30 seconds to load the next set of images. Chrome handles this smoothly. For social media I had to switch to chrome.
Firefox is still better for privacy and I use it when I can even though it feels like it's slowing down after each upgrade.
> Universally? Perhaps in the US? But IoT devices are sold worldwide.
Ugh, the situation is even worst in countries with censorship laws. For example, in my country, all ISP are required to intercept all DNS requests and filter all requests to any blocked domains found in the government block list. At least they're transparent about which sites are blocked though (the list is publicly available to query or download), but the fact that all DNS requests are intercepted causes various technical issues and some ISP are trying to profit from it by redirecting the blocked query to their own ads-laden landing pages. They even went as far as inspecting http host header as well as randomly injecting scripts on unencrypted http requests.
OP talks about somewhere else, but Poland have public registry of domain names that every ISP must block/redirect to Ministry of Finance website in their DNS resolver: https://hazard.mf.gov.pl/ (gambling sites running without proper license) (this is only about ISP resolver, no intercepting going on)
ISPs will also enforce other things using DNS. For example when Spectrum was fighting with Netflix, they sent traffic to some overloaded peering connection.
DNS over HTTPS is an abomination sold as snake oil security.
The absolute worst version I had of this was in China (and I think Korea as well).
I was troubleshooting an issue where a company's client computers which connected to the company VPN wouldn't have internet access post-connection.
The problem turned out to be that instead of sending a NXDOMAIN they'd return their ad server and then _always_ send back some JS to show ads.
The company network used PAC files (these are a piece of JS with a single FindProxyForURL() function) via an internal-only URI to steer most requests to our proxies, while keeping some internal.
The problem came about when clients would first start up the OS would attempt to access the internal-only URI before the VPN client finished connecting. In a normal network it'd get nothing and life would carry on. With this problematic ISP they'd get something that /should/ have been a PAC file, but because it was some other piece of JS without FindProxyForURL() it wouldn't work as a PAC file and thus the client wouldn't go to the proxy.
The expiration on this piece of JS was set to some absurd amount of time, so when the client would eventually try hitting our PAC file server again (happens every 20 minutes on Windows) it wouldn't get our file because it thought the garbage one from the ISP was newer. And the ISP updated their hijacking JS more frequently than we updated our PAC file.
There were two possible solutions to this. One, routinely touch the PAC file so it's date was newer than whatever the ISP put out. Or two, set up an external A record for the internal PAC server name to keep the hijacking from working. We went with the second.
My ISP in the UK returns NXDOMAIN for records pointing to 10. ips. I had to go through a lengthy process to have that issue fixed with them. Their support had no idea, and was trying to tell me it's nothing to do with them.
I think that actually supports my point. A customer has a relationship with the ISP and can actually sue them. If people start putting google or cloudflare DNS into lots of devices and apps and those start doing something questionable then you have no recourse and even if they did they'd have to go after dozens of different vendors to change their behavior instead of the single ISP.
It doesn’t matter to the device OEM when the customer demands a refund because the device stopped working, even though the root cause is the ISP hijacking the DNS request and the device OEM has nothing to do with it. Easier to work around this apparently common ISP practice.
> I'm sure google had only our best interests in mind when unleashing that on us.
Laughably, DoH is from the same gang of A-record squatters that refused to incorporate SRV into HTTP on the (now very evidently spurious) grounds that it could, in some scenarios, require an extra packet, and they couldn't work out how to make it backwards compatible.
Having been comprehensively hijacked by the interests of advertising companies, my view of the HTTP WG has never been lower. And that's a shame because there are some smart people there, tasked with slowly eroding away the last semblance of end-to-end transparency.
Because no one has asked for it. The people who care are redirecting port 53, which the devices cope fine with, because if you’re doing that you probably have same resolvers upstream. The people who don’t care are never going to decide they’d like to change the DNS resolvers.
This sounds like a game of cat-and-mouse. Lists of 'known' DoH DNS servers will be collected, and PiHole-esque blocking will take shape via more advanced filtering.
What a terrible state of affairs we're in now that you can't trust the network's own DNS. Please consider making it an advanced option to switch back on the DHCP provided address.
When you are contracted to build something to spec and you don’t build to spec, you don’t make any money. If you push back on the requested spec, the client will leave and go to another company thus leaving you without any money.
What I’m trying to say unless you are writing the spec, you usually have no chance to change anything
> and occasionally just highjack every single query to send you to a page saying you’re approaching your bandwidth quota
It boggles my mind it's still a problem in some countries. Last time I saw this kind of notice it was in the nineties, and on a web server, definitely not on a client endpoint. People have had unlimited bandwidth for at least a decade now.
This has regressed. In the NetZero days you would be limited to some hours per month depending on your plan. Then came unlimited cable. And now we are back: my residential AT&T DSL connection is limited to 1TB per month in the Bay Area
DoH will just be the start of another arms race. If you would like to control DoH also user LinuxBender responded to a question I asked about DoH blocklists with these repos in another post. I haven't got around to trying it out yet though.
> In the face of that sort of behaviour you inevitably end up with technical support having to field angry customers who just don’t get that it’s not our fault the hardware isn’t working
If your hardware isn't resilient to network failures then it absolutely is your fault.
There is no justification for bypassing users network settings, and especially doing it for your own convenience. At very least it should be opt in. If you want to violate customer privacy to save money on support, then I don't know why this is worth even discussing.
> Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
I've been running PiHole-like software on my network for a few years now. A couple of years ago, it would block over 40% of traffic consistently. I never saw ads, and it was nice.
In the last year, blocked traffic has dropped to about 15%, and I'm increasingly getting ads on my phone and Chromecast despite tunneling my traffic through my ad-blocked network and blocking Google's DNS at the network level.
I'm one of those "idiots" whose been whistling in the wind against encryption of everything and all kinds of security lockdowns and it's because of this sort of thing. The theoretical threat of someone sniffing my traffic is just not a concern to me compared to the very real and increasing threat of handing all control of my computing to centralized user-hostile powers.
I’m responsible for a bunch of IoT hardware, and every firmware spec I write includes a note on not using the DNS servers provided via DHCP.
And that along with DoH is contributing to making my life a pain in the butt. How exactly do you folks who avoid our DHCP's DNS expect us to comply with legal filtering requirements? Also, what happens when your hard coded DNS servers are shutdown?
> How exactly do you folks who avoid our DHCP's DNS expect us to comply with legal filtering requirements?
I would argue that this is more a problem with the legal requirements than with the equipment - the law(maker) has expectations you can’t reasonably fulfill.
Doesn’t make your situation any better of course, the law is the law even when it’s impossible
Oh, we can fulfill them. We'll resort to TLS inspection and force you to trust our CA on your device if you want to continue accessing our corporate network. And now we get to see (almost) everything again, like in the "good old days," not just your DNS queries.
Clear text DNS is the ultimate compromise, a gentleman's agreement if you want, that benefits everyone. We can see just enough to filter what we are required to by law on a best-effort basis, but we never see what you are actually doing thanks to the prevalence of TLS. DoH just broke that agreement.
It's a sad example of how a privacy solution like DoH will eventually result in less privacy, at least in some environments. And I'm not even considering how DoH will be the excuse for totalitarian regimes to up their surveillance antics.
Yeah. The pre-DoH world was good for both. I could say its all filtered for the kids on the locked down machines and the adults who knew something about technology could get on with their lives. Now, we are entering a world where we are going to end up locking down everyone. Good job.
I'm damn sure once I have to do the trusted CA path that someone is going to sell a deep packet inspection solution and present it at some conference where someone in charge will hear about it and then it will be off to the races.
Its not a law problem. Its an expectation that technology isn't as random or stupid that it cannot keep a headstart kid from going to PornHub because some tech folks don't trust their ISP.
I think the classic "the network treats censorship as damage and routes around it" applies here.
Designing a device to connect to something over the internet even if the network it's connected to behaves strangely isn't random or stupid; it's just in conflict with your goals. Incidentally, last time I ran into a network with legally mandated filtering, I checked whether a google image search for "tits" worked. It did.
Nope, it behaves fine. The owner of the network is serving under age kids. Push too far and its white lists only and block all other IP and I'm sure we'll get deep packet inspection forced on us. Some folks have serious problems with Google Images Search, but you can actually deal with that.
I would also say anyone hard coding DNS into a device is just absolutely unprofessional. Its basically a red flag that any filtering the owner of the network doesn't matter to them.
From the perspective of the device maker, a network causing a DNS lookup to return something other than an accurate result is behaving strangely. That may keep a device from working, so the device maker guards against it. A quick scroll through this thread reveals good reasons for device makers to do this, mostly ISPs behaving badly.
I'm generally inclined to think an "always use this manually-configured DNS" option is desirable in that situation. Of course, many devices may have a financial incentive (ads) to actively resist the network owner's attempts at filtering.
Filtering is inherently adversarial, and I expect a reasonably sophisticated user on your network could find a way to access some proscribed content. I also expect the users of concern on your network are under five years old and that most of them lack advanced knowledge of networking. Is there an established standard for what qualifies as a reliable-enough filter?
Many years ago, a old friend of mine purhcased a new Panasonic Smart TV. It was when "Smart TVs" were just becoming a thing.
I hooked her TV up for her; wiring it into the ATT uVerse modem directly. Other devices worked, but this one did not.
After resetting the modem, factory resetting TV, and making sure the ip address on the TV's menu were displaying properly and matched the router's config (they were), as a young naive tech nerd, I just said:
"Looks like they sold you a dud. Thankfully you kept the receipt!. Either way, you still have warranty to get it replaced."
My friend replied: "Shouldn't I call them first before taking it back?"
I said I didn't think it would help, but go ahead.
About 30 mins laters, she was talking to Panasonic tech support and they asked her to manually enter the DNS entries [I believe it was 75.75.. so Comcrap's], and voila, the TV was online again.
We were very happy it was an easy fix; but that day I deftinely did a LOT of reading on DNS servers.
Till this day, DNS entries are something I always check over when troubleshooting (as well as setting my router to Cloudfare's).
I've recently setup AdGuard Home on my Raspberry Pi, and noted that requests made from an Android phone weren't going through the DNS server at all. Turns out it uses a default IPv6 DNS first (which I found no method to modify) and then falls back to the manually entered IPv4 DNS server.
It's not perfect, but I find blocking all traffic in/out to global dns servers with pfBlockerNG to be an okay way to limit the DoH bypass of simple port 53 blocking. There are still ways around it, but it has caught a lot of other interesting traffic (snmp, ntp, etc.) leaving my network and that a simple port 53 block misses.
I agree, if it is an embedded device specifically designed to connect to a limited set of services, there is no reason to expect it to follow DNS provided by DHCP.
Conceivably, there's no need to it to even use "real" DNS at all, you could just run a server that responds to queries like "updateserver.ecorp" and save the hassle of even announcing these servers to the public DNS at all.
Also, DoH or not, there are plenty of other ways to ensure that ads get through a DNS filter. For example, a local hosts file could be included in firmware updates and they would just need to make extra effort to ensure that the server IPs didn't change (an elastic IP or load balancer in AWS would be all you need, then it can persist even if the VM has to be deleted).
I'd think most of IoT interfaces have some form of user-definable configuration. So most of the time it should be possible to make DNS user-configurable (hidden in some "advanced settings" area). Of course, it might lead to some more support calls eventually and requires a little more money (as in paid work) to implement, but you'd be playing nice and have a balanced compromise of default-hardcoded-DNS with an option to appease power users and/or orgs+corps, and you'd also avoid angry-me calling your support hotline and ranting at your people :P
That's not really a consumer-friendly solution. It's also borderline illegal in the EU IMHO (if you hardcode DNS servers in the USA, for example).
The toxic ISP issue isn't so dramatic where I live, it used to be worse 15-20 years ago. But the solution has always been: if the ISP is messing with you, you just buy your own router and configure it for your network, with a VPN tunnel if necessary. Ignoring DHCP makes this unnecessarily harder.
> Smart devices manufacturers often “hard-code” in a public DNS server, like Google’s 8.8.8.8, and their devices ignore whatever DNS server is assigned by your router - such as your PiHole.
Going to be a sad day for those advertisers when the DNS project gets killed by Google. Hopefully they are smart enough to set a alternate as well.
I don’t understand the downvotes. Google has a long history of killing projects. Of all the public DNS to trust, why does anyone have confidence in Google? Because they’re big?
There are two classes of Google products: ones that are small user applications, and ones that are core infrastructure internally and externally. As far as I know, only the former have a reputation for being EOLed.
DNS is the latter. Google’s RSS reader was the former.
The future is uncertain. Google has a history of canceling services and gives no signs of changing their behavior. Even if they made public acknowledgments hand waving “oh it’s these services not those other ones”, why would I fee any better? Google needs to spend a lot of time building trust. They don’t have it.
Just a few months ago there was a leaked email from Google execs talking about how Google Cloud needed to start making more money or it would be shuttered within a few years.
It’s pretty simple really. Google acts like a VC — place lots of bets on new projects in the hope that they’ll blow up and either a) start making adwords-scale profits or b) markedly increase adwords profits. Projects that don’t do either of those things are killed. The question is: Does 8.8.8.8 markedly increase adwords profit?
Because you made a zero effort joke that has been worn to the absolute bone by people repeating it thousands of times per year in HN comments, rather than at least putting in a bit of thought as to what the risk is for this service. Here's a quick attempt:
Track record: 8888 has been running for more than ten years.
Popularity: It appears to be incredibly widely used; e.g. a research paper from 2013 claimed it was serving 7% of all end user DNS queries, and Wikipedia claims that in 2018 it answered a trillion DNS requests per day (i.e. 10M qps).
Business value: It is true that there is no direct revenue here. But I'm pretty sure that the original reason for launching it was defensive. A lot of Google's networking projects have clearly been driven by trying to ensure that users can connect straight and reliable to Google's services with no interference from middleboxes, since every request lost to interference is also lost ad revenue.
Crappy ISP DNS servers that serve spam pages instead of NXDOMAIN are a pretty big vector here.
It’s not a joke. It’s a question of trust and authority. “Google DNS has been running for 10 years” does not negate Google’s management behavior or change the inherent risk of a free running for-profit entity being considered a DNS authority.
You calling it a tired joke doesn’t change these things.
On the business value front, I’d also bet that they see value from the data visibility front since that gives them a chance to identify malware and phishing domains early and the terms of service appear to allow aggregate activity data mining. It’s not as precise as Google Analytics, of course, but it works on many things which don’t have JS beacons and I’d be surprised if they couldn’t find a good deal of useful information from that stream.
> Track record: 8888 has been running for more than ten years.
I understand the point you're trying to make here - but long-lived products are still shut down by Google, fairly often. Here's a list of some Google products that have been / were around for 10 years or more before being killed (or are slated to be killed soon):
- Chrome Apps
- Cloud Print
- Fusion Tables
- Youtube Video Annotations
- Google Search Appliance (17 years old!!)
- Google Showtimes
- Google Code
- Picasa
- Orkut
- Postini
That's not even close to the full list of things that were more than 10 years old when Google shut them down. I left a bunch off for brevity's sake - but browsing https://killedbygoogle.com is a really eye-opening experience. They really have shut down a lot of stuff - and if you loosen the requirement to ">= 7 years" the list gets very, very long.
Again - I understand what you're trying to say. But it's just not simply a "zero effort joke". Google has killed a lot of things, and a lot of the things they killed were well used, long lived, and popular.
They'll keep Google DNS running as long as it provides business value to them, and that's it.
Use your brain. Google kills product because no one uses them because they mostly suck. Google's DNS server serves something like a trillion requests a day. It might be hard to see the business value for google but it is clear. Google makes money when people use the internet. The DNS server exists to make the internet the best it can be. If you have a shitty dns server you can always use googles. That means google is still making money off you. They won't kill something so integral o their basic monetization strategy.
> I understand the point you're trying to make here
The point was that it's a multi-dimensional space, and the OP should actually consider the product rather than automatically go all "lol, Google product, bet it gets killed".
So if you think that "some old products were discontinued" is any kind of rebuttal, I clearly didn't make my point well enough. Of course that happens! The alternative is that any sufficiently old product would automatically become immortal, which would be a ludicrous idea.
8.8.8.8 clearly has a ton of users, which already differentiates it from basically everything on your list. It's also isn't something you could just put in a maintenance mode and forget about, unlike a lot of the things on your list, both due to the scale and due to the impact if it were to stop working. Something like "Google Showtimes" would not have been a big drain on resources for most of its lifespan... When there's a measurable cost to keeping a service running, the longevity does actually signal something about the business value.
Products with no users get killed by all companies. Products with hundreds of millions of users don't get killed with one exception: to migrate the users to a different product for the same task.
And that can't really happen with DNS! They can't replace the clients, nor force the clients to upgrade, and they can't change the protocol in a way that would force some kind of a migration. Even if they end up deciding that the service needs a full rewrite, the external interface will have to stay the same.
And once you think about the specifics, it actually becomes kind of an interesting discussion to have! What are the circumstances that could lead to this service being discontinued?
A complete migration from IPv4 to IPv6 might do it: part of the value of both this and 1.1.1.1 is that these are IP addresses that people can actually remember. Their IPv6 addresses do not have that property. Not holding my breath on that one though :-P And even if that migration ever finishes, it's plausible that operating systems start including a dropdown of well-known public DNS servers as one of the configuration options.
Could they replace DNS entirely? Come up with a "QuikDNS" that starts off as proprietary, is implemented in only Chrome and Android but never replaces DNS outside of their ecosystem? Or instead of a proprietary protocol just stop supporting classic DNS and only continue supporting DNS over HTTP? I don't see the former, there's just not enough wrong with the standard protocols for that to be worth it. I could definitely imagine the latter happening at very long timescales (like, not for at least 10 years). At the point where 99% of the traffic is DNS over HTTP, maybe the cost benefit ratio stops being there for classic DNS.
> and a lot of the things they killed were well used, long lived, and popular.
I don't think the examples you posted really match that description. Most of them weren't ever popular, let alone when they were discontinued. Maybe Picasa was?
probably a win-win situation with google wanting to ensure users can use google services (foremost doubleclick) and users wanting to avoid crappy or censored isp resolvers.
but gog not using the harvested data seems somewhat unbelivable
This makes whole anti-trust angle actually even more interesting. If Google or Alphabet were to be split up, who would own the DNS? And would they still have business case to run probably relatively expensive service? Or would someone calculate that it makes more sense just to shut it down. Or maybe point all queries to nice marketing website?
I suspect that if Level 3 wrote a decent contract, if Google shuts it down, Level 3 will either take it over, or lease the IPs to someone else who wants to run recursive DNS with lots of clients.
(downvoters #1, what about telling me what you think is wrong with my post :) , I love to see that I am wrong at something as this teaches me new things)
(downvoters #2: still cant understand why are you donvoting, explanations are vague - I dont care about karma, but do allow me to understand what you dont like/understand)
It can probably ignore it, but it cant ignore my router forbidding all external dns communications except for it. And anyway, I am blocking all my "IoT" devices accessing internet or rather, every network communication is forbidden unless I explicitly allow it. And in this case it goes trough mitm transparent proxy where communication is examined and cut. I dislike dns based blocking anyway, it is a patch, not a solution. I prefer "owning" my communication.
Not to mention I dont buy a toaster if it requires 3rd party servers and it is not rootable (my roborock is playing Sepultura while cleaning, I dont know how much time the "beeper" will but feels good. :D). Vote with your money (!), no one will protect you from your behavior but yourself and once you figure out that the device is ignoring your network rules, return it. Or soon all the devices will be like that.
It is 2020. Peak of surveillance capitalism was ~5 years back. Why anyone would allow its devices freely roam the internet is beyond my understanding.
aaomidi: Sure. Then I wont buy the device. It is that simple. That means "vote with your wallet". If this is the society that everyone wants I wont join it. And legislation is always on the side of capital. Have you seen this "shit"? https://ec.europa.eu/digital-single-market/en/news/proposal-...
GDPR havent even started to fly yet and the EU commission is already undermining it with help of industry ("think of the children"... eee.. or covid in this case). Voting with your wallet is the only option. And if people are incapable of doing it, I will just stop buying devices - they are just toys as I like to tinker but I have yet to find any device that is so useful that I cant live without, more or less they are leveled with toaster with internet connection.
GekkePrutser: then you are living in wrong universe (and so do I). You cant help if people are oblivious to what is going on so use your time wisely and inform people. I have personally helped a lot of people to get rid of google and facebook adiction (even serving my own searx instance to them and hosting a few for free email). And the one that is making the hardware CANT change the stance if you dont allow the device to internet. Firmware was updated and this is not what you have bought (do you get the hint ;) ? ) so make the life of the seller a living hell. And if you are living in EU you surely can.
CraneWorm: Nope. I wont buy such a device.
Kiro: I dont use reply function as they are abusing it to take a revenge on non agreeable opinion (please DO something about it, if you sting one particular person - rust threads are a good example - they will downvote everything from you). Anyway I am provoking this debate as seems like people dont want to hear the facts. And they need to be heard - there is noone that will bother with legislation and they will fail at the end. The only solution is to educate normal people like they were educated to use firefox instead of internet explorer and later to use chrome instead of firefox (which was bad idea).
Dahoon: Not really. If the device doesnt have access to the internet, no "dns over http*" will help it.
This is becoming an example of frog boiling in action. The usual retort to mentions of frog boiling is that the frogs jump out but in this case, it's just bigger pots of boiling water all the way down.
Voting with your wallet doesn't help if everyone does the same thing. Not everyone is willing/able to live without technology.
It's also very hard to figure out what exactly they do before making the purchase, and many vendors change their stance with devices already in the field. Look at TP-Link for example: They suddenly stopped allowing local access to their Kasa switches 2 weeks ago. No more integration with Home Assistant. Yes, they have decided to revert it already. That doesn't mean they can't do it again. I had bought 7 of these plugs because they offered local access. Now I'm a lot less sure of this brand. But the money is already sunk into it.
How is it beyond your understanding? What is so hard to understand about the fact that 99.999% of people won't have the knowledge or the inclination to do that?
Another step in the silly device manufacturer / device owner arms-race. As long as people keep rewarding device manufacturers who treat owners as tenants it will progress. I wish people would just stop buying this garbage. They won't, though-- they see the features but not the down-side.
The next step will be hard-coded DoH server IPs. Sly owners will NAT those to a transparent MiTM proxy.
Then device manufacturers will counter with certificate pinning for DoH. That will be "game over", and the device manufacturers win. (It'll be a double-win, actually. It will put a hard "expiration date" on the device's functionality when a link in the PKI chain expires.)
I believe the owner of a device has right to control the device's network traffic (and, more generally, control of the code running on the device). Business models that rely on taking away an owner's control of their rightfully-purchased general purpose computing devices are really rental models and should be handled as such.
I eschew these kinds of devices, use or create self-hosted solutions where I can, and just do without when I can't. It does make me a little sad that I can't get some of these cool "living in the future"-type devices, but I'd be sadder to have my home festooned with manufacturer-controlled surveillance and advertising delivery devices.
I wish there was a way to convince the average non-technical person of the merits of owner control. Given the enthusiastic responses in favor of allowing device manufacturers to mistreat owners I see from the Hacker News community, though, even convincing technical people is a lost cause. It feels like most people really want to be subjugated. It doesn't seem ratioinal.
I do recognize that the Hacker News community also includes some of the people who profit from subjugation of device owners. Their motivation seems rational (if not sociopathic).
> It will put a hard "expiration date" on the device's functionality when a link in the PKI chain expires.
If you're certificate pinning an IP address for use with your own software, you can just create a self-signed cert with expiration date set to 2999 or some commonly ridiculous date you don't expect your devices will live to.
Why would they do that when they can force you to update your firmware by setting the expiration to a year or even less. This way you are guaranteed to be communicating with the mothership and the devices will incorporate any new malfeatures the manufacturer conceives.
I think that "privacy" is being used as a trojan-horse in this regard. Technical-minded people are especially reactionary to any criticism of HTTPs and the other related things that will inevitably arise from giving entities effectively an end-to-end untamperable and non-user-controlled pipe straight into your TV/Monitor from their server.
In an alternate universe, "ability to control/mitm data going through your network" could have been argued to be a fundamental right such as "right to repair" and "right to be forgotten". Where is the EFF on this? Where is Stallman when you need him again? Why is Mozilla not fighting this instead of pushing DoH?! EU regulators? Anyone?
As long as people keep rewarding device manufacturers
who treat owners as tenants it will progress. I wish
people would just stop buying this garbage. They won't,
though-- they see the features but not the down-side.
I hope that folks who blindly espouse free markets above all else realize that this sort of thing is the inevitable consequence.
Consumers nearly always shop with price as a primary concern, and almost never have the sort of detailed domain knowledge to understand pitfalls like the ones discussed here.
We certainly do not want the government to control too many things and should err on the side of freedom, but the result of too little consumer protection by the government means that situations like this are an absolutely guaranteed outcome.
Educated consumers are a good and necessary thing to have, but that falls far short of correcting the issue. It is impossible for a single person to have expert domain knowledge in every single product category. I've been a software developer for 20 years, so (relative to the general population, not HN) I am an "expert" of sorts in this field, but I am assuredly not also an expert in automobiles, food safety, home appliance safety, airline maintenance, medicine, or any of the other things upon which I might spend money.
> The next step will be hard-coded DoH server IPs.
1^4 exposes an endpoint on the regular IPs (1.1.1.1/dns-query) and dns.google is just pointing to the 2 IPs, so you could hardcode those as well. Not that you can redirect it:
> Sly owners will NAT those to a transparent MiTM proxy.
Is it? I’m still holding onto my TV from 2014 because it doesn’t have “smart” functionality. Every time I look at new ones I can’t find good dumb ones.
Aren’t all smart TVs dumb if you don’t connect them to the internet?
I wouldn’t be surprised if manufacturers start selling TVs that need to be activated online before first use, but I don’t know of any that do that already.
Mine quite happily works as a dumb TV without a connection, and I know many others who do the same. Though I hear stories of TVs being annoying to use without a connection (timing out waiting for a server response that can never come, before falling back to an ad free menu, or just constantly nagging, even while content is playing, about the lack of connectivity).
That’s Alexa hardware using something like LORAWAN or zigbee or something. Bandwidth is low.
I doubt that (at this stage) TVs have something similar builtin. When they come with Alexa/GHome/... it’s usually the software and not an actual Alexa device built in.
Likewise (s/Chromecast/Mac Pro/), but mine (LG) has no apparent means to disable Wi-Fi Direct, so it's still potentially vulnerable to local wireless exploits.
Yeah I worry about this sort of “annoy the customer into connecting” behavior becoming more common as integrating ads becomes more a part of the business model. Also could connect to open wifi networks in more densely populated areas
The real problem will be integrated cellular connectivity with no option to disable.
I hate my Samsung. All of our TV content comes through our Xfinity internet (no digital antenna, no cable box). However, when you turn the TV on the Samsung defaults to "Samsung TV" set of stations that look like local TV and have commercials. They hijack your internet, bandwidth that you pay for, to feed you commercials that they get paid for.
I have a Samsung but use an Apple TV, I'd recommend disconnecting it and going this route. I was paranoid to give this TV any access to a network, and actually kind of freaked out on my poor wife when she connected it one time when I wasn't home.
Yeah, but if/when that situation comes about, they're not going to let you do that. They'll brick your TV when you pry it out after forcing you to void your warranty by burying it in some difficult-to-access electronic guts.
I'm waiting on some high quality "dumb" TV. I'll happily pay more for not having to worry about all this nonsense and my sense is that I'm not alone (though most people will happily continue to buy non-privacy respecting brands for a lower price).
Depends where you are looking. They are not often carried by big name stores because of a mix of lack of demand and manufacturer kick-backs for selling the smart ones. Any they are relatively expensive, for the same reasons.
Another option is to buy a monitor not a TV, but again because of market scale you'll pay a lot more for a monitor that large. They don't sell enough to consumers for volume savings to kick in, and they are aimed at commercial use so there is at least a little more "make it good rather than cheap" incentive than there is in other markets.
Displays - TVs without the tuner, are very pssibly to buy if you don't mind it beint shipped to you. The sector is a live and well, just not targeted to consumers.
If you don't need any "TV" features such as a tuner or speakers, you might consider using a monitor. I use a 32" 4k monitor as my "TV".
In my case, anything with a TV tuner requires an expensive license, so that's another motivating factor, but whenever I use someone else's "smart TV", I'm always relieved that I don't have to deal with glacial UIs and injected ads.
The ubiquitous display control boards with HDMI/VGA on one side and a FFC connector on the other sold... just about everywhere also don't have ads. (Yet.) So get a working panel, pair it with such a thing and you are off to the races!
User friendliness does fall behind a bit, I'll give that.
To make matters worse, the SmartTV sold someone in my family just had the SmartTV apps (netflix, etc) taken forcefully off the device because they no longer wished to keep it up to date.
And I use a 55" 4K TV as my "monitor", because sub-$1,000 >>30" monitors with internal 3D LUT-based color calibration aren't a thing.
And, while I don't use the speakers, the TV's S/PDIF output is nevertheless handy for routing the audio output of whichever of the four HDMI inputs is active to the single S/PDIF input on my audio interface.
Finally, the TV has an RS-232 port that allows control of essentially all of the basic "TV" functionality, which was handy for setting up keyboard shortcuts for input switching, power, and brightness control; IME, monitor controls for such things that don't involve diddling with buttons on the side of the device itself are few and far between.
those have different panels tunned for more ambient lighting and doesn’t have the same color and black reproduction of a good tv panel. just buy a tv and use an external player without connecting the tv to internet and you are set.
The sales world you are looking for is a "panel", think something that goes on the wall at a convention center, or as a menu. They very muxh exist, and the stats are no B.S>
Yeah as others have said, the TV can't get online by itself, so you simply don't configure the "Smart" features and it should work just fine (although perhaps that is something to confirm before purchase).
Yes someone else linked to a story where TVs were hopping onto open Wifi, but honestly if a TV I owned ever did that, I would probably toss it and boycott that manufacturer forever.
I'm not an expert in this space, but professional displays (e.g., screens mounted in airports, and the like) do not seem notable for their cinematic visual quality-- usually they have a washed out appearance. They're reliable screens, but not made for watching movies.
Can you be so sure it is the screens that are at fault.
When mounted in airports and the like, they are also mounted in environments where the lighting is usually such (i.e., much too bright) that nearly any screen (LCD or old CRT's) would generally appear "washed out". So the effect you see may not be the screens, but instead may be caused by the environments in which you generally see them operating.
I have a side-business in digital signage. Professional displays are indeed usually dumb TVs and are made to witstand 24/7 operation and may have higher lumen, etc. They do come at 4k. They also usually come with better management software and more ports. They can be connected to the internet for some remote management but I’ve never used that.
There’s of course a price difference between you $300 cheapo consumer stuff, and a $1000-2000 pro display.
I used to have these pro displays at home with Chromecast, works fine.
> The term you are looking for is “professional display”.
Those cost way more than dumb displays did back before there were smart displays. Look at the 40-inch/43-inch models. They're like $800. I bought all my 40-inch 4k screens for under $300 in 2016.
The insane price gouging in these "professional displays" cannot be explained by advertising subsidies. We weren't paying those prices for equivalent-spec dumb TVs back when those were available for sale.
Unfortunately they no longer make them. The 43-inch Sceptres have a HUGE black space between the pixels, which you will totally notice if you try to use them as desktop monitors.
Also, 40-inch 4k screens don't seem to exist anymore. The 43-inch and above have a MUCH larger inter-pixel gap which I can easily notice when using them as a monitor. 50-inch and above are too big for desktop monitor use.
I think the panel manufacturers realized they torpedoed their high-end monitor market with the 40-inch 4k screens which is why they had to nuke them and make the 43-inch displays so crappy.
>And inevitably someone will say that they'd heard that Smart TVs will connect to unsecured WiFi networks in proximity and start uploading your data.
That's bullshit because that could get into a HIGHLY illegal issue on the manufacturer as they could join into a foreign network tampering with comms. And IDK on the US, but the fines on Europe on that are really high.
I never connect it via WiFi so it never has my password and use an Apple TV for streaming services. If I need to update the firmware, I use ethernet and then disconnect when done.
Though at least if they did this, it's not using my network/affecting my data limits/able to be used by a hacker to exploit my network. Plus there would probably be a physical cell antenna somewhere that could be... altered.
Details https://mashable.com/article/amazon-sidewalk-surveillance-ne... If you have certain Ring cameras or Echo devices, Amazon enabled a new radio in it back in September. You can opt out from the Alexa app: More -> Settings -> Account Settings -> Amazon Sidewalk -> Off.
It would be nice to get notified when my dishes are done. We’re it not for weirdly malicious data harvesting I think this would be considered a neat feature.
I agree. I think there are loads of "smart" things that sound super neat in principle. The problem is finding a company who is competent at making software, competent at making hardware, and trustworthy enough to allow to put a tracking device into my home. Those are three small circles without much (any?) overlap.
they still run a bloated operating system that occasionally crashes. The TV can still be smart and at some point I expect them to nag you constantly about not being connected.
That's my problem with them. The smart TVs I've used are slower to startup than the dumb ones, even when not using the "smart" features. Just changing the inputs is often painfully slow.
I'm not adverse to buying commercial displays for home use, but it's hard to find places that carry them and list prices. Those I have seen prices for were usually much more expensive than TV branded displays.
Then comes the other big thing. How am I supposed to spend so much when I can't see the thing before I buy it, and there's not much in the way of reviews?
I'm just hoping my next TV doesn't complain much when I don't connect it to the internet; not worried about it finding other networks to connect to, because of where I live.
>I'm not adverse to buying commercial displays for home use, but it's hard to find places that carry them and list prices.
I just spent 3 minutes googling for dumb tvs and found lots of them instantly. Why bother with commercial displays if you can buy cheap dumb TVs at Walmart? Here's a review for one [0].
We need legislation against this kind of crap. It is only a matter of time until these "smart" devices share childporn or host darknet drug shops.
Let's face it, the devs implementing these devices run a scrum process, features get stacked upon features and no one cares about, let alone understands the security of the whole tool stack. It is only a matter of time before we have a bot net of smart tvs and roombas. And network owners will be held responsible.
I'm not sure if its worth posting, but I just installed pihole and its great. You dont actually need a pi, you can run it in docker. its nice that you can see all the dns queries that are happening.
I think you meant to say that you don't actually need a Pi. It's unfortunate that they named it that way. Never name things after the technology involved in making them work, because if your thing is any good, it'll spread to other devices/languages/operating systems.
Great. I've set up Kodi on my Mac. Of course, there's no way to get the content from my machine in the office, to the actual TV that I can see. So that doesn't really solve any problems.
Unless you mean buy a separate box, put Kodi on it and attach that to the TV
In this point in time everything is compromised. It is a business function not user oriented design. If you affect the bottom line you actively making a statement in this. Don't buy smart IoT shit, don't buy new phones, don't use entertainment services. This is how you will make a difference. Waiting for legislation to remove corporate malpractice is absurd. Politicians are fighting who will get "retirement" benefits. The only voting mechanism in our disposal is money, voting with your money always counts.
Jio (India) is super obnoxious in the fact that their own router is locked down hard. Now you cant even change your DNS. I have suggested few people to bypass this limitation by removing the router as dhcp and using pihole for that. That works but don't know for how long. The pathetic thing is their router does not even allow bridging mode. Fuck jio.
Agreed. But that is another expense and essentially you are telling millions of people to buy a second device when the first one is capable of doing just that. Only the ISP has locked shit down. The idea should be to force ISPs to keep stuff open, unless the devices are junk and you definitely need a replacement.
That is not the case here. Their router is pretty capable, they just want to control people. Thats bad
not long before every TV comes with a built-in SIM card and a whispernet-like arrangement .
I hope computer monitors at 40-50inch size reach affordable prices.
If you have a device that tries to use sidewalk, you could put tinfoil around the device or desauter the bluetooth chip/900mhz radio (and hope the device works without them in there), but that's really it if these devices come out without a setting to disable sidewalk.
May be we start detaching the Smart into a separate box, or basically buying a large Monitor?
Is there such thing as 55" Monitor? The whole TV industry needs some new thinking and innovation. Right now it is race to the bottom and everyone is trying to get some extra revenues from Data gathering. There are also a huge oversupply from LCD panel maker.
You don't connect your TV but use Apple devices instead. Uhm... okay. You should see the IDS log I'm looking at here. Apple !== no telemetry. All you are doing is putting all your eggs in one basket.
An alternative view is that the parent commenter is being deliberate about which device(s) have access, and decided on Apple over whomever made the TV.
They appear to not be trustworthy to be on our networks - so we should:
1. Not join them to our networks
2. Stop buying 'Smart TV's'
3. Get panels and a smart box that you can control
I'm lucky enough to be able to direct ALL DNS through my router first. Nothing gets out without my say so. Not everyone has that capability, sadly, with home routers.
The solution provided by the OP is a solid one - another would be to purchase a decent router (such as a Mikrotik) and learn how to use it - much more powerful device for the same price, or sometimes lower, as a regular 'home' router.
>I'm lucky enough to be able to direct ALL DNS through my router first
Even DNS over HTTPS? Do you do packet inspection? Just blocking ports doesn't do much any more. I run an IDS/IPS and it blocks lots of DoH to Google. Apple devices are even worse.
I'm not sure what the commenter's setup is, but I have one that (at least mostly) achieves the same thing. It is a combination of a few things:
1. Redirect all outbound DNS traffic to your own local DNS server (as described in the link in this post)
2. Return NXDOMAIN for well-known DoH domains [1] (as well as "use-application-dns.net" for well-behaving software like Firefox [2])
3. Block traffic to well-known DoH providers by destination IP address [1]
Yep, pretty much the above - I have a combination of rules that control all traffic. Only the router is allowed to use port 53 outbound - all other traffic is redirected using NAT to the router's DNS server.
I mentioned Mikrotik previously - I use them myself.
It’s going to be really difficult to not get a smart tv pretty soon. You can, of course not hook it up to the internet. But pretty much all of the current TVs (particularly the good ones with nice displays) are going to be “Smart”. One reason for the recent huge price drops on TVs is the ability to subsidize the price by selling viewing data. It’s the new normal in the CE world.
Yeah the only thing that can stop this trend at this point is regulation unfortunately. Unless you make it a rule that TV manufacturers can’t do this putting them all on a level playing field the ones that do will always be ahead on price.
Regulation should intervene when smart tvs come with non-obvious downsides like data collection. Consumers don't get informed and have no possibility of making an informed choice here.
People know about data collection. They don't care.
The first thing we need to do to have productive conversations about privacy with non-technical people is to stop pretending they are ignorant or unable to understand trade-offs. People know that their online activity is tracked. They know that their Alexa devices record their conversations. All of this has been on the news enough times that you'd need to be living in a cave to be unaware of it.
People know this, and they have chosen to purchase these devices anyway. Maybe it's not because they are stupid and need the state to protect them -- maybe they are capable of evaluating trade-offs and their choices ought not to be second-guessed by people who think they know better.
> The first thing we need to do to have productive conversations about privacy with non-technical people is to stop pretending they are ignorant or unable to understand trade-offs.
And then those same people complain about folks who won't vaccinate their kids, saying they're being selfish.
Without realizing they're doing exactly the same thing.
They are ignorant. They do not understand the trade-offs.
I agree that people know about data collection and don't care to some extent, but I'd argue that they don't understand the consequences and the extent of this.
If they'd be presented a bill of what they're being overcharged through better targeting, ads, etc., the same way activity trackers show how many steps a user takes, things might change.
What I'd disagree is that people choose to purchase the device anyway, a non-tech-savy user will hardly get presented a non-smart device, wouldn't even know to search for this.
I think regulation should at least let you turn off features, e.g. it should be possible to use Airplay and turn off the app store the tv uses.
The article has convinced me to do exactly that and finally get a pfsense router to make the pihole more effective. I'll (try to) only allow each device to run the services I really want it to run. I doubt my partner, siblings, parents, etc. would be able to do that though, this needs a simple pfsense/pihole combo that runs well out of the box or regulation to protect consumers.
Umm. I’m not saying force TVs to stop being smart. I’m saying that you can level the playing field by saying that TV manufacturers aren’t allowed to collect user information or display ads. That’s the race to the bottom where users lose.
Can you share what “dashboard display” you’re buying snd what’s the quality like compared to an actual TV? I just want a high quality screen ~55-65” to use with an AppleTV. I’m considering an LG oled cx because I don’t want android and will not use any of its features other than sound and display. I wish there was an oled display only for this use-case :(
> One reason for the recent huge price drops on TVs is the ability to subsidize the price by selling viewing data. It’s the new normal in the CE world.
That's good though! If you are one of the people who wants a dumb TV, congratulations! You get to benefit from lower TV prices, subsidized by all the other people who are buying smart TVs for the smart features. Just don't connect your new TV to your network, don't try to use the smart features, and pretend it's a dumb TV. It works fine.
No Netflix or Amazon on Kodi. While I have a NAS with my media on it that Kodi worked fine on the need to open a browser and need for a keyboard and mouse became to much of a pain. I switched everything to AppleTV which had the issue of not being able to mount the NAS. Lucky there is a Kodi "port" to the AppleTV in the App Store called Mr.MC for like $8 that is pretty much Kodi with built in support for NFS, SMB, etc. AppleTV is the perfect box for this to be honest.
In terms of usability OSMC is in my opinion a lot better than all the smart tv UI's I've seen (and you can definitely run it from even older pi hardware)
You can also chromecast and airplay pretty smoothly as well.
A raspberry pi media centre obviously is not the simplest solution. But for someone who feels they just want a "dumb" tv and a box they can control, it's perfect. It's a good choice for those who can set it up and that get peace of mind and satisfaction from having a box that is on their side.
KDE is working on a "smart box" software to run on raspberrypi. I believe it's called KDE Bigscreen and even has voice search features through mycroft if you are hosting an instance. The project is available in beta right now but it looks like it has potential
Getting people to add another device like a Pihole or a separate router with better filtering capabilities isn’t going to be an option that most people can handle by themselves.
This solution would definitely not work for DNS Over HTTPS (DoH), which I’m guessing will soon become prevalent in many devices. It also seems like DNS Over TLS (DoT) isn’t going to get as much traction exactly because it’s easier to block.
As other comments have said, (for those who’re able to do it) not configuring any connection for the device sounds like a good start, but even that has caveats about the device connecting to nearby open networks. So the best thing to do instead is to connect it to a network but not allow any communications to the Internet.
A few years ago, I tried using ansible to automate setup of PiHole. That did not go well because it's essentially a poorly coded hobby-level project. I've since switched to BIND (named) & it's fantastic implementation of DNZ RPZ[0].
One of my incomplete-but-functional quarantine projects tries to tackle this "raspberry pi project" problem: How to reproducibly set up these community-maintained projects, with homebrew-like simplicity.
672 comments
[ 3.2 ms ] story [ 278 ms ] thread<link rel="canonical" href="https://0.0.0.0:4000/blog/force-dns-pihole">
So some "Share" buttons may pick that up.
Maybe we count this one as an art performance?
I don't think that it's malevolent on their part. Lots of ISP DNS are crappy. Hardcoding a reasonably reliable one saves them a lot of frustration and unnecessary technical support.
Margins are already razor thin in hardware, so yeah anything that can be done to reduce your support costs is welcomed.
However, these IoT companies add these features mainly to benefit from selling the acquired data. The users are not asking for this. They're making it difficult for themselves.
I agree. I have support costs too. Which is why every company that sells a product with a hard coded DNS server configured but doesn't advertise said aspect prominently in all advertising, so I can know to avoid their intentionally defective product, should pay me $10000 for the time I wasted buying their product, discovering their product is secretly and intentionally broken, and then return their product.
This is done because the manufacturer’s and public DNS servers are more of a known quantity then you ISPs router and DNS servers. Using pihole is super rare and wouldn’t be worth the effort if it weren’t for the fact that it makes devices more reliable.
Saying that a device is not violating any standards as they "aren't required to accept DNS servers offered by DHCP" is like saying a device is not broken and not violating any standards because "they aren't required to accept IP addresses offered by DHCP." It's a silly to say devices are not required to accept the parameters sent by my DHCP server as such a statement is only correct in the most abstract sense that there is no law that requires a device to adhere to the relevant RFCs for DHCP. On the other hand there are laws, federally and in many states, that only allow you to connect to and use other people's network with their permission and only use their networks within the bounds that they allow.
I don't care about the device manufacturer's opinion of DNS server quality. I own the device and I own the network that the device is connected to and I pay for the uplink between that network and the rest of the internet. There is only one person who can correctly make an assessment as to the correct DNS server for my network and that is me. If a device manufacturer chooses to hard code a different DNS server they are wrong and it is broken and they should tell me so I don't waste my time buying their product and returning it.
Additionally they should advertise this behavior because it is a security vulnerability for my network for their shitty device to be sending my internal names to outside servers to resolve. The names of the devices on my network that I choose not to expose to the internet are no business of anyone else.
E: And I didn't even get into the mess that it would be to try and expose the DNS zones for the RFC 1918 address spaces that everyone is using.
The more convincing narrative is that setting custom DNS decreases ad revenue and cuts into growth.
The same thing that happened each time when DRM servers went offline. Time to buy a new TV :^)
"Sorry, your product is out of warranty, I can redirect you to sales"
On balance, I'd expect Google is be much better about maintaining their DNS uptime than most ISPs.
It's madness to me that people find this acceptable. These companies are profiting off the ignorance of people and misleading customers on what they're actually selling them.
As someone who has/might work for companies building things like that, it sounds like a nightmare. It's a ton of design, testing, translation, validation, etc work to build the UI for adjusting optional settings. And it has to be maintained and tested through all future versions, redesigns, refactorings, etc. It's gonna be a tough sell to do it right considering:
For every 1 techie who legitimately uses it to set it to his custom server and can handle debugging when it goes wrong, 50 people will accidentally set it to something random, or have some distant relative set up some weird hack and then disappear when it breaks, and then call the support line and rage at somebody when it doesn't work and they don't understand why, and rage some more when they can't get the instructions to reset it right.
Whatever feature somebody else is about to propose to fix that is yet another thing that will need design, validation, maintenance, etc forever. It's pretty understandable why product designers would rather build simple dumb UIs with no options that mostly work automatically.
Amazon sold two versions of their kindle, one with and one without ads, not an issue for me. As customer the pro/con relationship is clear. I get what I pay for.
These ads slow down my TV, waste electricity, waste my time more importantly. It's not my problem as a customer if other people mis-configure their TV and have to call support, that's a UX problem, I've never met anyone who has mis-configured their DNS on their phone. If you've updated your DNS on your TV before it's a very long process, using arrow keys to select characters, it's not something you accidentally do.
I paid for a TV and I didn't get what was advertised. The argument that they do it to protect dumb users is non-sense because the TVs that don't have this configurable in the settings are the ones mainly bundled with ads.
Please, if you have a Pihole, redirect all DNS through it as described in the article. Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
I am very suspicious of the push for https and the like. I feel it is mainly about hiding the payload from me not any third party.
You might control the resolver on your personal computer (for now). You probably don't control it on your phone. You most likely won't control it on your embedded devices.
If it doesn't see internet it just blocks itself and goes to a screen "Oops I have no internet".
So you can forget about watching movies from your local server using the VLC app as well. Ridiculous.
I think it's insane that devices can effectively be bricked if they can't phone home. It's nothing short of waste, and I think environmental legislation should require device manufacturers to supply ways of disabling or overriding these mechanisms such that devices can continue to operate regardless of whether home servers are blocked or otherwise out of reach, e.g. company goes belly up, censorship etc.
Actually you probably should return such devices as broken.
It was kind of hard to send back a really nice device that I had just opened up and was ready to fly.
Thing is, some companies just use it as a way to fire their customers.
However, they are also playing these sorts of games with other types of devices, where no such justifications exist ( https://www.eevblog.com/forum/eevblab/eevblab-83-dji-pocket-... ) That needs to be answered by returning the product as defective.
I will admit I haven’t done any further investigation, but simply concluded that the gateway at some point started phoning home and if it didn’t receive a response went into some catatonic state. Maybe I’ll dig deeper at some point, time permitting.
Using DoH, especially one served by an advert company is just signing up to be their open book.
Hold up. You are claiming that the fact that DoH prevents DNS requests from being visible in cleartext network traffic is a bad thing?
...what? In a world where the choice is between one party (the DNS provider) having access to my DNS requests and everyone on the network including my DNS provider having access to my DNS requests, I'll choose "DNS provider having exclusive access" every single time.
It is when its my network. If they cared about people sniffing they would use DNSSEC, but still use the network DNS server. DNS over HTTPS is just a way for shady companies to hide what they're doing.
The problem of shitty devices on your private network is a different one.
I recently bought a car, and could not find one without a cellular modem and microphones. Removing the modem voids the warranty. The period where you can opt out is mostly over.
For the manufacturer to avoid a warranty claim due to a modification or aftermarket part, they must show that the defect was linked to the part or modification.
They might have to show that it was caused by, but in any case, if your paint fails prematurely, they can’t say your warranty is void because you disabled the cell connection.
Otherwise it is probably mostly equal to driving without registration. It may not be a felony, but it will be fined.
Somewhat more sophisticated would be hardcoding an IP to a server with a REST endpoint that returns the real final IP. (Basically just like what DoH does, but without calling it DoH).
Even more sophisticated would be hiding the final IP on some kind of public web service like Twitter or Github.
These devices do usually have an UI. Why not provide some options to the user? Let him choose among different types and providers. I'd set mine to use the one provided by DHCP or enter the address of my resolver manually.
In my experience, product design is generally done with a well-meaning attempt to protect the average user from themselves. People who can and do manage their own networks in sophisticated ways are, unfortunately, far less common than people who have no idea that their ISP fscks with DNS lookups.
Personally, I'd bury this setting pretty deep in an advanced-usage-only tab and behind a notice SCREAMING about how using these settings is unsupported. And then tell support staff that they are not obligated to support whatever crazy configurations people cook up for their home networks.
I understand not doing it at all. A few people will complain, but the number of people who will refuse to buy a TV because it doesn't play nice with their pihole is almost certainly too small to register on any material financial statement, and attempting to please them will generally run into some other point they are unwilling to budge on. The number of people who screw up an advanced setting they don't understand will show up in support costs.
The way we solve this is that we assume any knowledge the device has about the outside world can become obsolete, so we do we have a two layer approach.
The bottom layer is that we have a set of semi hard-coded fallback values that are likely to work in the forseeable future. Updating these fallbacks requires an over the air firmware upgrade which isn't a terribly big deal since we regularly upgrade firmware over the air. The goal of these values is to make sure we can get the device online and direct it to somewhere where we can trigger firmware updates.
The second layer is that one or more times per day we ping a config server that sends a packet with configuration data to the unit. This is typically API endpoints etc. The configuration data is essentially a prioritized list of resources, so if one won't respond it will go to the next on the list (while still trying to determine if a higher priority resource becomes available).
Last week we got a chance to see how this failed over beautifully as multiple resources were removed and a fleet of devices just adapted as they should. (The shutdown of these resources were planned, but presented a good opportunity to do a fire drill).
I can see myself using it as well, maybe even just to see which devices don't use DNS.
Here's another idea: generate a unique IPv6 address per DNS request, route them to the correct destination, filter other IPs. Not really scalable, but usable on small networks/VLANs.
Why wait?
Netgear, at one point, also decided that hard-coding an IP address (for NTP, not DNS) was the best solution [0].
--
[0]: https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#Ne...
As opposed to the IP addresses that your DHCP server told you about.
I wonder who's the first sponsor for that thing, dns-over-https...
Universally? Perhaps in the US? But IoT devices are sold worldwide.
While I do run my own recursive resolver I checked my ISP's and they're behaving fairly reasonable and do none of the above and I have a direct (contractual) relationship with them and we reside in the same jurisdiction so at least in principle I could apply pressure to them if they do something shady. The same can't be said about google or cloudflare.
> Just be aware DNS over HTTPS is a thing now, and while the devices I’m responsible for aren’t going to try and evade your redirects, the companies that are trying to make sure ads get delivered will absolutely switch to DoH which will be much more difficult to work around.
I'm sure google had only our best interests in mind when unleashing that on us.
Before going with the conspiratorial take note that Mozilla shipped DoH early and both Microsoft and Apple implemented it. Untrustworthy ISPs are a real problem even if Google deservedly gets suspicion about their motives. This isn’t another AMP.
and DoH is absolutely designed to get around network based security and filtering, both for Ad's and other reasons.
You can just say you don’t follow this closely. Mozilla is not perfect but they do push for privacy, with an increasingly limited amount of negotiating power.
> DoH is absolutely designed to get around network based security and filtering, both for Ad's and other reasons.
This is similarly reflecting a poor understanding of the situation. DoH can’t get around network filtering - if you block packets, there’s no magic trick to bypass it. It’s great for preventing ISPs from tampering with traffic or monitoring activity (this will also require eSNI to complete) but it’s not giving an attacker any capability they didn’t already have. If you’re concerned about security you’re fooling yourself if you don’t have endpoint management and some level of network segmentation and egress control. Attackers have hard-coded DNS servers, C&C endpoints, etc. for decades.
The point of the original story is "your" meaning a device you own, is ignoring your network controls
it is highly unlikely that the TV manufacturer is going to allow me to install my own custom root certs to inspect their traffic to HTTPS, so yes DoH and other things are a threat to network security, because if the TV become compromised I have limited administrative controls to prevent it other the blocking it completely which is a poor response to the problem
DoH is a solution in search of a problem that can be solves in better more user friendly ways
The usual approach to setting up a firewall is a default of "block everything" and then selectively allow only what is needed.
Most people cheat and only do this on inbound connections, allowing everything on the egress side, because it's easier. But if you want to block your IoT devices from making outbound https connections, you easily can.
There's nothing really new going on here. It's always been possible to tunnel one protocol over another, or use nonstandard ports, and use encryption on the traffic to hide what you're doing.
For this reason I wouldn't recommend buying a device like the Chromecast, in which the user can't configure the network settings. Instead maybe consider something like the Amazon Fire Stick which is not as user-hostile.
I would also love to MitM myself in some cases, mostly because it’d be interesting to see what’s going on.
So before applying that mentality, it would be wise to consider what your experience would be like if all your neighbours, friends, colleagues etc also did that on their networks.
The solution is to start doing network filtering: if you block packets to unapproved servers, you can actually stop this. You’ll need to run your own proxy, of course, but that’s always been the only way to actually accomplish that goal.
Of course, jailbreaking opens up other security issues, so it goes back to what you can tolerate.
[0] https://checkrain.org/ [1] https://letsencrypt.org/getting-started/
I would imagine you can use this to push any certificate that you can also push to an iOS/iPadOS/macOS device.
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.
> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.
It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.
That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
And in the context of pihole and such, avoiding that means editing the DNS response to remove those public keys. Which takes us full circle back to "do I control DNS for this gadget, or not".
Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that secure the DNS lookup. At that point, filtering will require MITM proxies, whether it's for DNS or HTTP or any other protocol.
It's a trade-off with security on the open network meaning harder penetration and control in your internal network. There's no easy answer.
Why do you say it's not authenticated? If they're using the newer standards then that's what it provides. If they're not then there's no issue with network filtering as usual.
It doesn't matter if you're using your ISP's servers, 8.8.8.8, 1.1.1.1, or a custom server you set up on Digital Ocean somewhere: an on-path attacker can forge DNSSEC responses to you. It's a ridiculous situation.
The problem is that your relationship with your network devices is logically the same as a totalitarian country's/company's relationship with their citizens/users. So any protocol that prevents censorship/surveillance by ISPs also impinges upon bona fide network administrators. Corporate networks have the same dynamic, although there are few tears shed when it becomes harder for them to tamper with users' traffic.
The right answer is to make sure devices that have any Internet access run code you control. The root of the problem here is buying a "smart" TV, hooking it up to the network, and then expecting to tame all of its user-hostile anti-features by policing its communication. The only way to use black box IoT devices is to remove all general Internet access from them, allowing communication only with hosts you do control. For instance I've got a network of tp-link bulbs that are all controlled from a Home Assistant instance, and they never have and never will get a packet out to the larger Internet.
I agree that the core problem here is blocking egress entirely – and that’d be a good area for home routers to add UI polish so you could easily allow your TV to hit Samsung.com if there’s an update you need before turning it back off. Unfortunately that’s going to be a losing game for many devices and that really hits at the root cause: we need strong regulation controlling privacy because trying to stop a well-funded company with purely technical measures is almost always a losing game.
> hit Samsung.com if there’s an update you need
Why would you need an update? Updates are mainly necessary for security, which you don't need if the device isn't on the Internet. If the device doesn't have all the features you expect out of the box, return it within the return period. There's a small corner case where an update could carry significantly increased functionality, but it seems easier to ad-hoc address that down the line rather than plan for it. Carelessly doing updates is a good way to break your device.
> Unfortunately that’s going to be a losing game for many devices
I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and a local modbus network.
You've never had a problem which was fixed by an update or something which added support for, say, a new model peripheral? I have, which is why I allowed for the possibility of wanting to do this on the schedule of your choosing but not the default case.
> I don't see how it's a losing game if you play it correctly. Fine grained policing of types of traffic is a losing game, but wholesale denying transit isn't. There is little difference between my network of tp-link bulbs and say a local modbus network.
I was thinking less narrowly than devices which never need to be online. A TV connected to other players can run entirely offline but there are many other things which legitimately need connectivity and there's no good way to prevent that. For example, think about a device like a Chromecast or Fire TV, or those Facebook video chat appliances — people buy those to stream content so the most you can do is force the vendor to send marketing stuff through the same endpoint they use for your content, and that's increasingly hard to filter (think how useful a “it goes to an IP in AWS. Block y/n?” prompt is). That's why I said it'll require a legal fix since a large fraction of the most invasive devices either already do or could trivially be modified to mix other data in with the traffic needed to function.
For embedded devices? No. I can imagine it happening in general, but I don't think I would ever buy into a proprietary ecosystem so hard that there would be peripherals, and newly released ones at that. Still I would be cautious about doing said updates, lest they ruin the device I already have. Like I've got a newer Marantz receiver that works great and hasn't seen the Internet in several years. Even if they developed some new desirable feature, why would I want to let it reflash itself and possibly break, or even just get slower (software bloat)? I'd rather just continue using it as I bought it.
> there are many other things which legitimately need connectivity and there's no good way to prevent that
I sort things into categories. A TV would be in the category of "wtf would you ever hook that up online" - Internet access can only enable anti-features. A Chromecast is a different category - single purpose disposable device that if it turns into shit you just throw it out. Ads and surveillance are part of its price, and if your goal is to avoid them, you should just setup a Kodi box and call it a day.
Legally I don't really see what you're getting at here. I can see a law for my TV category, but leaving it disconnected or pulling the 5G modem will also solve that. How would you even begin to solve the Chromecast problem with a law? Maybe in the EU you could convince them to mandate unbundling ads from a service, but in the US exploiting consumers by shoving ads at them is one of the most popular business models. I don't see that ever changing via the legal system.
Follow the money .. watch the actions not the words
You’re going to have to make a more substantial argument to get anywhere with this.
As someone who has used (and still use Firefox) continously since around 2005 it surely feels that way sometimes and some of the decisions I see would make much more sense to me if I knew top management was somehow in Googles pocket.
(That said
1. for my workflows I still consider Firefox the best browser.
2. switching would only make it even easier for Google.
3. I always hope something will change and Firefox will become really really great again or someone will fork it.
Consider.
[0] https://en.wikipedia.org/wiki/Mozilla_Corporation#Google
[1] https://www.theverge.com/2020/8/15/21370020/mozilla-google-f...
There was a recent change to facebook picture albums that lazily loads pictures as you scroll. In large albums this grinds to a halt after a few pages and each scroll takes 30 seconds to load the next set of images. Chrome handles this smoothly. For social media I had to switch to chrome.
Firefox is still better for privacy and I use it when I can even though it feels like it's slowing down after each upgrade.
Abrowser (from trisquel) is what firefox should have been. Best fork out there imo.
Here's an article from November 19, 2020 about the rollout and some of the criticisms/backlash:
https://www.zdnet.com/article/fearing-drama-mozilla-opens-pu...
Ugh, the situation is even worst in countries with censorship laws. For example, in my country, all ISP are required to intercept all DNS requests and filter all requests to any blocked domains found in the government block list. At least they're transparent about which sites are blocked though (the list is publicly available to query or download), but the fact that all DNS requests are intercepted causes various technical issues and some ISP are trying to profit from it by redirecting the blocked query to their own ads-laden landing pages. They even went as far as inspecting http host header as well as randomly injecting scripts on unencrypted http requests.
DNS over HTTPS is an abomination sold as snake oil security.
Mozilla did more to unleash it than Google. Someone from Mozilla coauthored the RFC for it, and Mozilla had browser support for it first.
I was troubleshooting an issue where a company's client computers which connected to the company VPN wouldn't have internet access post-connection.
The problem turned out to be that instead of sending a NXDOMAIN they'd return their ad server and then _always_ send back some JS to show ads.
The company network used PAC files (these are a piece of JS with a single FindProxyForURL() function) via an internal-only URI to steer most requests to our proxies, while keeping some internal.
The problem came about when clients would first start up the OS would attempt to access the internal-only URI before the VPN client finished connecting. In a normal network it'd get nothing and life would carry on. With this problematic ISP they'd get something that /should/ have been a PAC file, but because it was some other piece of JS without FindProxyForURL() it wouldn't work as a PAC file and thus the client wouldn't go to the proxy.
The expiration on this piece of JS was set to some absurd amount of time, so when the client would eventually try hitting our PAC file server again (happens every 20 minutes on Windows) it wouldn't get our file because it thought the garbage one from the ISP was newer. And the ISP updated their hijacking JS more frequently than we updated our PAC file.
There were two possible solutions to this. One, routinely touch the PAC file so it's date was newer than whatever the ISP put out. Or two, set up an external A record for the internal PAC server name to keep the hijacking from working. We went with the second.
Laughably, DoH is from the same gang of A-record squatters that refused to incorporate SRV into HTTP on the (now very evidently spurious) grounds that it could, in some scenarios, require an extra packet, and they couldn't work out how to make it backwards compatible.
Having been comprehensively hijacked by the interests of advertising companies, my view of the HTTP WG has never been lower. And that's a shame because there are some smart people there, tasked with slowly eroding away the last semblance of end-to-end transparency.
The ISP provided DNS in South Korea is absolutely terrible too. Setting 1.1.1.1 or 8.8.8.8 always serves far better experience than the ISP's.
When you are contracted to build something to spec and you don’t build to spec, you don’t make any money. If you push back on the requested spec, the client will leave and go to another company thus leaving you without any money.
What I’m trying to say unless you are writing the spec, you usually have no chance to change anything
It boggles my mind it's still a problem in some countries. Last time I saw this kind of notice it was in the nineties, and on a web server, definitely not on a client endpoint. People have had unlimited bandwidth for at least a decade now.
https://old.reddit.com/r/homeautomation/comments/k72lzq/sowh...
[1]: https://github.com/bambenek/block-doh
[2]: https://github.com/Sekhan/TheGreatWall
Edit: I am mostly curious to see what devices/applications it will break.
If your hardware isn't resilient to network failures then it absolutely is your fault.
I've been running PiHole-like software on my network for a few years now. A couple of years ago, it would block over 40% of traffic consistently. I never saw ads, and it was nice.
In the last year, blocked traffic has dropped to about 15%, and I'm increasingly getting ads on my phone and Chromecast despite tunneling my traffic through my ad-blocked network and blocking Google's DNS at the network level.
Run 'update your block lists' on your Pihole to make sure the lists are being updated correctly.
I'm one of those "idiots" whose been whistling in the wind against encryption of everything and all kinds of security lockdowns and it's because of this sort of thing. The theoretical threat of someone sniffing my traffic is just not a concern to me compared to the very real and increasing threat of handing all control of my computing to centralized user-hostile powers.
And that along with DoH is contributing to making my life a pain in the butt. How exactly do you folks who avoid our DHCP's DNS expect us to comply with legal filtering requirements? Also, what happens when your hard coded DNS servers are shutdown?
I would argue that this is more a problem with the legal requirements than with the equipment - the law(maker) has expectations you can’t reasonably fulfill.
Doesn’t make your situation any better of course, the law is the law even when it’s impossible
Clear text DNS is the ultimate compromise, a gentleman's agreement if you want, that benefits everyone. We can see just enough to filter what we are required to by law on a best-effort basis, but we never see what you are actually doing thanks to the prevalence of TLS. DoH just broke that agreement.
It's a sad example of how a privacy solution like DoH will eventually result in less privacy, at least in some environments. And I'm not even considering how DoH will be the excuse for totalitarian regimes to up their surveillance antics.
I'm damn sure once I have to do the trusted CA path that someone is going to sell a deep packet inspection solution and present it at some conference where someone in charge will hear about it and then it will be off to the races.
Designing a device to connect to something over the internet even if the network it's connected to behaves strangely isn't random or stupid; it's just in conflict with your goals. Incidentally, last time I ran into a network with legally mandated filtering, I checked whether a google image search for "tits" worked. It did.
Nope, it behaves fine. The owner of the network is serving under age kids. Push too far and its white lists only and block all other IP and I'm sure we'll get deep packet inspection forced on us. Some folks have serious problems with Google Images Search, but you can actually deal with that.
I would also say anyone hard coding DNS into a device is just absolutely unprofessional. Its basically a red flag that any filtering the owner of the network doesn't matter to them.
I'm generally inclined to think an "always use this manually-configured DNS" option is desirable in that situation. Of course, many devices may have a financial incentive (ads) to actively resist the network owner's attempts at filtering.
Filtering is inherently adversarial, and I expect a reasonably sophisticated user on your network could find a way to access some proscribed content. I also expect the users of concern on your network are under five years old and that most of them lack advanced knowledge of networking. Is there an established standard for what qualifies as a reliable-enough filter?
Yet that is what internet actually is for a lot of people...
Many years ago, a old friend of mine purhcased a new Panasonic Smart TV. It was when "Smart TVs" were just becoming a thing.
I hooked her TV up for her; wiring it into the ATT uVerse modem directly. Other devices worked, but this one did not.
After resetting the modem, factory resetting TV, and making sure the ip address on the TV's menu were displaying properly and matched the router's config (they were), as a young naive tech nerd, I just said:
"Looks like they sold you a dud. Thankfully you kept the receipt!. Either way, you still have warranty to get it replaced."
My friend replied: "Shouldn't I call them first before taking it back?"
I said I didn't think it would help, but go ahead.
About 30 mins laters, she was talking to Panasonic tech support and they asked her to manually enter the DNS entries [I believe it was 75.75.. so Comcrap's], and voila, the TV was online again.
We were very happy it was an easy fix; but that day I deftinely did a LOT of reading on DNS servers.
Till this day, DNS entries are something I always check over when troubleshooting (as well as setting my router to Cloudfare's).
This is the list I use: https://public-dns.info/nameservers-all.txt
Conceivably, there's no need to it to even use "real" DNS at all, you could just run a server that responds to queries like "updateserver.ecorp" and save the hassle of even announcing these servers to the public DNS at all.
Also, DoH or not, there are plenty of other ways to ensure that ads get through a DNS filter. For example, a local hosts file could be included in firmware updates and they would just need to make extra effort to ensure that the server IPs didn't change (an elastic IP or load balancer in AWS would be all you need, then it can persist even if the VM has to be deleted).
As is DoT :)
Certainly in Europe I’ve not seen anything even close to that.
I’d love to see a good country-by-country survey on ISP DNS to see just how common this manipulation is.
The toxic ISP issue isn't so dramatic where I live, it used to be worse 15-20 years ago. But the solution has always been: if the ISP is messing with you, you just buy your own router and configure it for your network, with a VPN tunnel if necessary. Ignoring DHCP makes this unnecessarily harder.
Going to be a sad day for those advertisers when the DNS project gets killed by Google. Hopefully they are smart enough to set a alternate as well.
Fool me once, shame on you. Fool me 1500 times...
Per this site that tracks dead google projects, thus far they are at 220.
DNS is the latter. Google’s RSS reader was the former.
Very tragic, but things change. The nerd rage over Google Reader, etc is similar.
It’s pretty simple really. Google acts like a VC — place lots of bets on new projects in the hope that they’ll blow up and either a) start making adwords-scale profits or b) markedly increase adwords profits. Projects that don’t do either of those things are killed. The question is: Does 8.8.8.8 markedly increase adwords profit?
Track record: 8888 has been running for more than ten years.
Popularity: It appears to be incredibly widely used; e.g. a research paper from 2013 claimed it was serving 7% of all end user DNS queries, and Wikipedia claims that in 2018 it answered a trillion DNS requests per day (i.e. 10M qps).
Business value: It is true that there is no direct revenue here. But I'm pretty sure that the original reason for launching it was defensive. A lot of Google's networking projects have clearly been driven by trying to ensure that users can connect straight and reliable to Google's services with no interference from middleboxes, since every request lost to interference is also lost ad revenue.
Crappy ISP DNS servers that serve spam pages instead of NXDOMAIN are a pretty big vector here.
You calling it a tired joke doesn’t change these things.
I understand the point you're trying to make here - but long-lived products are still shut down by Google, fairly often. Here's a list of some Google products that have been / were around for 10 years or more before being killed (or are slated to be killed soon):
- Chrome Apps
- Cloud Print
- Fusion Tables
- Youtube Video Annotations
- Google Search Appliance (17 years old!!)
- Google Showtimes
- Google Code
- Picasa
- Orkut
- Postini
That's not even close to the full list of things that were more than 10 years old when Google shut them down. I left a bunch off for brevity's sake - but browsing https://killedbygoogle.com is a really eye-opening experience. They really have shut down a lot of stuff - and if you loosen the requirement to ">= 7 years" the list gets very, very long.
Again - I understand what you're trying to say. But it's just not simply a "zero effort joke". Google has killed a lot of things, and a lot of the things they killed were well used, long lived, and popular.
They'll keep Google DNS running as long as it provides business value to them, and that's it.
(Edit: I'm bad at list formatting, sorry)
> They'll keep Google DNS running as long as it provides business value to them, and that's it.
As in yes: I know it provides business value to them.
> Use your brain
Please be civil in your comments and refrain from insults. That’s not a charitable way to interact with others.
The point was that it's a multi-dimensional space, and the OP should actually consider the product rather than automatically go all "lol, Google product, bet it gets killed".
So if you think that "some old products were discontinued" is any kind of rebuttal, I clearly didn't make my point well enough. Of course that happens! The alternative is that any sufficiently old product would automatically become immortal, which would be a ludicrous idea.
8.8.8.8 clearly has a ton of users, which already differentiates it from basically everything on your list. It's also isn't something you could just put in a maintenance mode and forget about, unlike a lot of the things on your list, both due to the scale and due to the impact if it were to stop working. Something like "Google Showtimes" would not have been a big drain on resources for most of its lifespan... When there's a measurable cost to keeping a service running, the longevity does actually signal something about the business value.
Products with no users get killed by all companies. Products with hundreds of millions of users don't get killed with one exception: to migrate the users to a different product for the same task.
And that can't really happen with DNS! They can't replace the clients, nor force the clients to upgrade, and they can't change the protocol in a way that would force some kind of a migration. Even if they end up deciding that the service needs a full rewrite, the external interface will have to stay the same.
And once you think about the specifics, it actually becomes kind of an interesting discussion to have! What are the circumstances that could lead to this service being discontinued?
A complete migration from IPv4 to IPv6 might do it: part of the value of both this and 1.1.1.1 is that these are IP addresses that people can actually remember. Their IPv6 addresses do not have that property. Not holding my breath on that one though :-P And even if that migration ever finishes, it's plausible that operating systems start including a dropdown of well-known public DNS servers as one of the configuration options.
Could they replace DNS entirely? Come up with a "QuikDNS" that starts off as proprietary, is implemented in only Chrome and Android but never replaces DNS outside of their ecosystem? Or instead of a proprietary protocol just stop supporting classic DNS and only continue supporting DNS over HTTP? I don't see the former, there's just not enough wrong with the standard protocols for that to be worth it. I could definitely imagine the latter happening at very long timescales (like, not for at least 10 years). At the point where 99% of the traffic is DNS over HTTP, maybe the cost benefit ratio stops being there for classic DNS.
> and a lot of the things they killed were well used, long lived, and popular.
I don't think the examples you posted really match that description. Most of them weren't ever popular, let alone when they were discontinued. Maybe Picasa was?
but gog not using the harvested data seems somewhat unbelivable
(downvoters #2: still cant understand why are you donvoting, explanations are vague - I dont care about karma, but do allow me to understand what you dont like/understand)
It can probably ignore it, but it cant ignore my router forbidding all external dns communications except for it. And anyway, I am blocking all my "IoT" devices accessing internet or rather, every network communication is forbidden unless I explicitly allow it. And in this case it goes trough mitm transparent proxy where communication is examined and cut. I dislike dns based blocking anyway, it is a patch, not a solution. I prefer "owning" my communication.
Not to mention I dont buy a toaster if it requires 3rd party servers and it is not rootable (my roborock is playing Sepultura while cleaning, I dont know how much time the "beeper" will but feels good. :D). Vote with your money (!), no one will protect you from your behavior but yourself and once you figure out that the device is ignoring your network rules, return it. Or soon all the devices will be like that.
It is 2020. Peak of surveillance capitalism was ~5 years back. Why anyone would allow its devices freely roam the internet is beyond my understanding.
aaomidi: Sure. Then I wont buy the device. It is that simple. That means "vote with your wallet". If this is the society that everyone wants I wont join it. And legislation is always on the side of capital. Have you seen this "shit"? https://ec.europa.eu/digital-single-market/en/news/proposal-... GDPR havent even started to fly yet and the EU commission is already undermining it with help of industry ("think of the children"... eee.. or covid in this case). Voting with your wallet is the only option. And if people are incapable of doing it, I will just stop buying devices - they are just toys as I like to tinker but I have yet to find any device that is so useful that I cant live without, more or less they are leveled with toaster with internet connection.
GekkePrutser: then you are living in wrong universe (and so do I). You cant help if people are oblivious to what is going on so use your time wisely and inform people. I have personally helped a lot of people to get rid of google and facebook adiction (even serving my own searx instance to them and hosting a few for free email). And the one that is making the hardware CANT change the stance if you dont allow the device to internet. Firmware was updated and this is not what you have bought (do you get the hint ;) ? ) so make the life of the seller a living hell. And if you are living in EU you surely can.
CraneWorm: Nope. I wont buy such a device.
Kiro: I dont use reply function as they are abusing it to take a revenge on non agreeable opinion (please DO something about it, if you sting one particular person - rust threads are a good example - they will downvote everything from you). Anyway I am provoking this debate as seems like people dont want to hear the facts. And they need to be heard - there is noone that will bother with legislation and they will fail at the end. The only solution is to educate normal people like they were educated to use firefox instead of internet explorer and later to use chrome instead of firefox (which was bad idea).
Dahoon: Not really. If the device doesnt have access to the internet, no "dns over http*" will help it.
These changes are always gradual until they become ubiquitous. Some changes are stopped in their tracks due to legislation.
It's also very hard to figure out what exactly they do before making the purchase, and many vendors change their stance with devices already in the field. Look at TP-Link for example: They suddenly stopped allowing local access to their Kasa switches 2 weeks ago. No more integration with Home Assistant. Yes, they have decided to revert it already. That doesn't mean they can't do it again. I had bought 7 of these plugs because they offered local access. Now I'm a lot less sure of this brand. But the money is already sunk into it.
https://home-assistant-guide.com/2020/11/17/tp-link-kasa-sma...
DNS over HTTPS says otherwise.
https://news.ycombinator.com/newsguidelines.html
Also, why are you not using the reply function?
The next step will be hard-coded DoH server IPs. Sly owners will NAT those to a transparent MiTM proxy.
Then device manufacturers will counter with certificate pinning for DoH. That will be "game over", and the device manufacturers win. (It'll be a double-win, actually. It will put a hard "expiration date" on the device's functionality when a link in the PKI chain expires.)
I believe the owner of a device has right to control the device's network traffic (and, more generally, control of the code running on the device). Business models that rely on taking away an owner's control of their rightfully-purchased general purpose computing devices are really rental models and should be handled as such.
I eschew these kinds of devices, use or create self-hosted solutions where I can, and just do without when I can't. It does make me a little sad that I can't get some of these cool "living in the future"-type devices, but I'd be sadder to have my home festooned with manufacturer-controlled surveillance and advertising delivery devices.
I wish there was a way to convince the average non-technical person of the merits of owner control. Given the enthusiastic responses in favor of allowing device manufacturers to mistreat owners I see from the Hacker News community, though, even convincing technical people is a lost cause. It feels like most people really want to be subjugated. It doesn't seem ratioinal.
I do recognize that the Hacker News community also includes some of the people who profit from subjugation of device owners. Their motivation seems rational (if not sociopathic).
If you're certificate pinning an IP address for use with your own software, you can just create a self-signed cert with expiration date set to 2999 or some commonly ridiculous date you don't expect your devices will live to.
In an alternate universe, "ability to control/mitm data going through your network" could have been argued to be a fundamental right such as "right to repair" and "right to be forgotten". Where is the EFF on this? Where is Stallman when you need him again? Why is Mozilla not fighting this instead of pushing DoH?! EU regulators? Anyone?
Consumers nearly always shop with price as a primary concern, and almost never have the sort of detailed domain knowledge to understand pitfalls like the ones discussed here.
We certainly do not want the government to control too many things and should err on the side of freedom, but the result of too little consumer protection by the government means that situations like this are an absolutely guaranteed outcome.
Educated consumers are a good and necessary thing to have, but that falls far short of correcting the issue. It is impossible for a single person to have expert domain knowledge in every single product category. I've been a software developer for 20 years, so (relative to the general population, not HN) I am an "expert" of sorts in this field, but I am assuredly not also an expert in automobiles, food safety, home appliance safety, airline maintenance, medicine, or any of the other things upon which I might spend money.
1^4 exposes an endpoint on the regular IPs (1.1.1.1/dns-query) and dns.google is just pointing to the 2 IPs, so you could hardcode those as well. Not that you can redirect it:
> Sly owners will NAT those to a transparent MiTM proxy.
And do what about the pinned certificate/CA?
It is possible to buy 58 inch dumb TV, connect that to a machine you own.
I wouldn’t be surprised if manufacturers start selling TVs that need to be activated online before first use, but I don’t know of any that do that already.
I doubt that (at this stage) TVs have something similar builtin. When they come with Alexa/GHome/... it’s usually the software and not an actual Alexa device built in.
The real problem will be integrated cellular connectivity with no option to disable.
How the hell is this legal???
I'm waiting on some high quality "dumb" TV. I'll happily pay more for not having to worry about all this nonsense and my sense is that I'm not alone (though most people will happily continue to buy non-privacy respecting brands for a lower price).
Another option is to buy a monitor not a TV, but again because of market scale you'll pay a lot more for a monitor that large. They don't sell enough to consumers for volume savings to kick in, and they are aimed at commercial use so there is at least a little more "make it good rather than cheap" incentive than there is in other markets.
In my case, anything with a TV tuner requires an expensive license, so that's another motivating factor, but whenever I use someone else's "smart TV", I'm always relieved that I don't have to deal with glacial UIs and injected ads.
User friendliness does fall behind a bit, I'll give that.
And, while I don't use the speakers, the TV's S/PDIF output is nevertheless handy for routing the audio output of whichever of the four HDMI inputs is active to the single S/PDIF input on my audio interface.
Finally, the TV has an RS-232 port that allows control of essentially all of the basic "TV" functionality, which was handy for setting up keyboard shortcuts for input switching, power, and brightness control; IME, monitor controls for such things that don't involve diddling with buttons on the side of the device itself are few and far between.
"Bitrate Up to 48 Gbit/s, as of HDMI 2.1"
To answer your question: -Everybody does.
1: https://youtu.be/4eSADWuZskk?t=231
I work in a classified military space where the security of our equipment has been verified; our 80 inchers are all NEC and work wonderfully
When mounted in airports and the like, they are also mounted in environments where the lighting is usually such (i.e., much too bright) that nearly any screen (LCD or old CRT's) would generally appear "washed out". So the effect you see may not be the screens, but instead may be caused by the environments in which you generally see them operating.
There’s of course a price difference between you $300 cheapo consumer stuff, and a $1000-2000 pro display.
I used to have these pro displays at home with Chromecast, works fine.
Those cost way more than dumb displays did back before there were smart displays. Look at the 40-inch/43-inch models. They're like $800. I bought all my 40-inch 4k screens for under $300 in 2016.
The insane price gouging in these "professional displays" cannot be explained by advertising subsidies. We weren't paying those prices for equivalent-spec dumb TVs back when those were available for sale.
This is also becoming increasingly problematic.
Unfortunately they no longer make them. The 43-inch Sceptres have a HUGE black space between the pixels, which you will totally notice if you try to use them as desktop monitors.
Also, 40-inch 4k screens don't seem to exist anymore. The 43-inch and above have a MUCH larger inter-pixel gap which I can easily notice when using them as a monitor. 50-inch and above are too big for desktop monitor use.
I think the panel manufacturers realized they torpedoed their high-end monitor market with the 40-inch 4k screens which is why they had to nuke them and make the 43-inch displays so crappy.
Do I need to void warranty and dissect a new piece of consumer electronics to remove the spy organ? Is that really an acceptable situation?
https://news.ycombinator.com/item?id=25275350
That's bullshit because that could get into a HIGHLY illegal issue on the manufacturer as they could join into a foreign network tampering with comms. And IDK on the US, but the fines on Europe on that are really high.
Endgame is the FCC forces consumer-data-control on the industry because it's the only way they can get the 5G/GPS jammer problem back under control.
Then comes the other big thing. How am I supposed to spend so much when I can't see the thing before I buy it, and there's not much in the way of reviews?
I'm just hoping my next TV doesn't complain much when I don't connect it to the internet; not worried about it finding other networks to connect to, because of where I live.
I just spent 3 minutes googling for dumb tvs and found lots of them instantly. Why bother with commercial displays if you can buy cheap dumb TVs at Walmart? Here's a review for one [0].
[0] https://youtu.be/394sDSOI9dU
And, of course, none or the fancy things like OLED or even local dimming/HDR.
Seems like an OK bet if you're looking for a basic TV though.
Let's face it, the devs implementing these devices run a scrum process, features get stacked upon features and no one cares about, let alone understands the security of the whole tool stack. It is only a matter of time before we have a bot net of smart tvs and roombas. And network owners will be held responsible.
See: https://github.com/CastagnaIT/plugin.video.netflix
Unless you mean buy a separate box, put Kodi on it and attach that to the TV
https://github.com/yuliskov/SmartTubeNext
Most smart TVs have built in web browsers, you can also try website like https://www.dnsleaktest.com/ to check your DNS.
If you have an Echo/sidewalk-capable device already, you can opt-out of allowing other devices to use your sidewalk in the Ring or Amazon app https://support.ring.com/hc/en-us/articles/360032524592-Opti....
Is there such thing as 55" Monitor? The whole TV industry needs some new thinking and innovation. Right now it is race to the bottom and everyone is trying to get some extra revenues from Data gathering. There are also a huge oversupply from LCD panel maker.
You don't connect your TV but use Apple devices instead. Uhm... okay. You should see the IDS log I'm looking at here. Apple !== no telemetry. All you are doing is putting all your eggs in one basket.
Another option is to simply never give your smart TV any kind of network connection.
1. Not join them to our networks 2. Stop buying 'Smart TV's' 3. Get panels and a smart box that you can control
I'm lucky enough to be able to direct ALL DNS through my router first. Nothing gets out without my say so. Not everyone has that capability, sadly, with home routers.
The solution provided by the OP is a solid one - another would be to purchase a decent router (such as a Mikrotik) and learn how to use it - much more powerful device for the same price, or sometimes lower, as a regular 'home' router.
Even DNS over HTTPS? Do you do packet inspection? Just blocking ports doesn't do much any more. I run an IDS/IPS and it blocks lots of DoH to Google. Apple devices are even worse.
1. Redirect all outbound DNS traffic to your own local DNS server (as described in the link in this post) 2. Return NXDOMAIN for well-known DoH domains [1] (as well as "use-application-dns.net" for well-behaving software like Firefox [2]) 3. Block traffic to well-known DoH providers by destination IP address [1]
[1] https://github.com/bambenek/block-doh [2] https://support.mozilla.org/en-US/kb/configuring-networks-di...
I mentioned Mikrotik previously - I use them myself.
Regulation should not be used to override clearly demonstrated consumer preferences or to force companies to produce products that few people want.
The first thing we need to do to have productive conversations about privacy with non-technical people is to stop pretending they are ignorant or unable to understand trade-offs. People know that their online activity is tracked. They know that their Alexa devices record their conversations. All of this has been on the news enough times that you'd need to be living in a cave to be unaware of it.
People know this, and they have chosen to purchase these devices anyway. Maybe it's not because they are stupid and need the state to protect them -- maybe they are capable of evaluating trade-offs and their choices ought not to be second-guessed by people who think they know better.
And then those same people complain about folks who won't vaccinate their kids, saying they're being selfish.
Without realizing they're doing exactly the same thing.
They are ignorant. They do not understand the trade-offs.
If they'd be presented a bill of what they're being overcharged through better targeting, ads, etc., the same way activity trackers show how many steps a user takes, things might change.
What I'd disagree is that people choose to purchase the device anyway, a non-tech-savy user will hardly get presented a non-smart device, wouldn't even know to search for this.
I think regulation should at least let you turn off features, e.g. it should be possible to use Airplay and turn off the app store the tv uses.
The article has convinced me to do exactly that and finally get a pfsense router to make the pihole more effective. I'll (try to) only allow each device to run the services I really want it to run. I doubt my partner, siblings, parents, etc. would be able to do that though, this needs a simple pfsense/pihole combo that runs well out of the box or regulation to protect consumers.
https://www.swedx.se/#horizontalTab2
That's good though! If you are one of the people who wants a dumb TV, congratulations! You get to benefit from lower TV prices, subsidized by all the other people who are buying smart TVs for the smart features. Just don't connect your new TV to your network, don't try to use the smart features, and pretend it's a dumb TV. It works fine.
Roku? Where the CEO outright said that they aren’t in the hardware business and they are trying to monetize via ads?
Google? Need I say more
Amazon Fire devices? See above with Google
AppleTV? Sure I have a couple. They aren’t trying to monetize with advertising. But the HN crowd is anti-Apple.
Kodi running on a Pi or some other low power computer is probably HN-friendly, although the usability isn't even close to as good as the Apple TV.
You can also chromecast and airplay pretty smoothly as well.
As far as usability, look at all of the comments mentioning hacks solutions instead of just ordering a commercial product and plugging it in.
I went one step further with my parents. I just bought them a Roku TV and called it a day.
This solution would definitely not work for DNS Over HTTPS (DoH), which I’m guessing will soon become prevalent in many devices. It also seems like DNS Over TLS (DoT) isn’t going to get as much traction exactly because it’s easier to block.
As other comments have said, (for those who’re able to do it) not configuring any connection for the device sounds like a good start, but even that has caveats about the device connecting to nearby open networks. So the best thing to do instead is to connect it to a network but not allow any communications to the Internet.
DoT is upticking, albeit at a non-boosted rate. The number of servers supporting DoT has doubled in the US (as in from 3 to 6).
1. Do not setup your TV, do not except EULA. 2. Get other setup, PC, AppleTV and use TV as dumb screen.
Issue solved.
For now. Wait until Amazon Sidewalk takes off.
https://www.amazon.com/Amazon-Sidewalk/b?node=21328123011
[0]: https://dnsrpz.info/
https://github.com/berrypatch/berrypatch
(I guess I've reached the inevitable "build your own package manager" stage of one's hacking career..)