Live data from Hacker News

Smart-TV blocklist for Pi-Hole

perflyst.github.io

231–240 of 246 posts

Re: Smart-TV blocklist for Pi-Hole

#231
post #226
post #154

Earlier quoted context omitted.

Please don't throw the word "FUD" around, especially when you didn't understand the comment. GGP did mean HDCP 2.x (DRM to encrypt the signal between display and device) which is often not supported by commercial displays. Unless devices detect a compatible, DRM-protected display, devices will refuse to play UHD content made by the movie industry.

This is true, of course, but modern commercial displays typically do have modern hdmi and hdcp specs so it shouldn’t be an issue. Even 12 year old NEC p-series (used at airports, usually) have hdcp.

To stream 4K from commercial services you need HDCP 2.2 or later. This was only introduced in 2013 so a 12 year old TV will not have full HDCP 2.2 support. It might have 2.0 (released in 2008) but that won't enable 4K streaming from a commercial service.

All streaming services require HDCP 2.2 support throughout the device chain. Because commercial displays aren't intended to use on-device streaming services or be used in consumer environments they often lack HDCP 2.2 support. While they might support HCDP 1.4 or 2.0, that will only support FHD content either streaming or disc-based. It's fairly difficult to find specs on commercial displays about their HDCP support level.

Re: Smart-TV blocklist for Pi-Hole

#232
post #230

Earlier quoted context omitted.

Who do you think was pushing for the DNS-over-HTTPS standard? Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Patrick McManus Mozilla Email: mcmanus@ducksong.com * https://datatracker.ietf.org/doc/html/rfc8484

If DoH didn’t exist, a device manufacturer could trivially reinvent something equivalent. DoH isn’t the problem.

They could also do that with out DoH, they dont because it is not "trivial" and prone to all kinds of downsides.

DoH is the problem here, as it hides things from network operators making it harder to block ads, spam, and other items at the network level under the guise of privacy, when in reality DoH's actual goal is to further centralize the internet into approved gate keepers like CloudFlare and Google.

Re: Smart-TV blocklist for Pi-Hole

#233
post #204
post #179

Earlier quoted context omitted.

Yes and it is better that google and cloudflare do that collecting under the guise of protection... People really are gulible aren't they... DoH is a not or a privacy feature. It simply changes who is collecting your data and makes it harder for responsibile network operators to protect their users under the guise that the big tech companies are really protecting the users from the network operators and "big bad ISPs…

Google and Cloudflare don’t sell data on dns queries per their privacy policies. Verizon does.

I see this common response, but that is not really a valid rebuttable. Companies do not need to sell your data to violate your privacy, in the case of google their entire model is selling their TARGETING, not the data. That is still a violation of privacy. The fact they did not "sell" it to a 3rd party to form the customer profile changes little.

In the case of cloudflare, it is going to be interesting how they continue to justify the free public services to institutional investors now that they are public. I have a feeling there is going to be some strong pressure to either cease the free services, or find away to monetize them which likely will involve some kind of usage of that data maybe not selling per say, but some other kind of targeting or something to add to the profitability of the company.

I am no more comfortable with cloudflare having my data than I am with google or verizion, I have never used any of their DNS services

Re: Smart-TV blocklist for Pi-Hole

#234
post #152

Earlier quoted context omitted.

The ability to wirelessly transmit to a TV on the LAN, without the ability of the TV to connect to the internet is valuable to me.

VLANs (if using Ethernet) or separate wireless network with no access to the internet nor your LAN (LAN->TV is OK, TV->LAN is not) is the only way to go. Anything else is a game of whack-a-mole that you're likely to lose.

I have extra networking hardware. I wasn't aware I could have LAN->TV but not bidirectional communication. Is there a source you know of better than googling on how to achieve this, since you seem to imply it's different than searching about VLANs since it's wireless.

Re: Smart-TV blocklist for Pi-Hole

#235
post #234

Earlier quoted context omitted.

VLANs (if using Ethernet) or separate wireless network with no access to the internet nor your LAN (LAN->TV is OK, TV->LAN is not) is the only way to go. Anything else is a game of whack-a-mole that you're likely to lose.

I have extra networking hardware. I wasn't aware I could have LAN->TV but not bidirectional communication. Is there a source you know of better than googling on how to achieve this, since you seem to imply it's different than searching about VLANs since it's wireless.

Technically you'd need bidirectional communication once a LAN->TV connection has been established. What I meant is to restrict connection establishment to only LAN->TV but not the other way around.

In terms of configuring firewalls/etc, it really depends on your equipment, however in most cases there's already a catch-all rule to allow any established & related traffic so you only need to add a rule to allow the initial connection establishment from LAN->TV.

> since you seem to imply it's different than searching about VLANs since it's wireless.

When it comes to VLANs, the idea is that the Ethernet port of the TV should either be connected to a managed switch that will tag any incoming traffic on that port with a VLAN tag before sending it upstream to your router (so it can tell what it is, since at that point it'll be arriving via a port that also has trusted LAN traffic), or connect it directly to the router and have that router's port not be part of the LAN bridge.

You don't have VLANs in wireless, instead you just create a new network - however the access point itself will need to either tag all traffic from said network with a VLAN tag (so again your upstream router can differentiate between that and trusted LAN traffic arriving over the same port), or if the AP is incapable of VLAN management then dedicate it to the TV network and connect it to a managed switch or dedicated port on the router as described above.

Re: Smart-TV blocklist for Pi-Hole

#236
post #152

I don't get it. Also down below there's even a whole comment chain about how "hard it is" to buy a dumb TV. Why bother with all this blocking, just disable the surveillance entirely. Change your wifi password, don't give the new one to the TV, and use a computer as input. A TV is a big dumb monitor, full stop.

The ability to wirelessly transmit to a TV on the LAN, without the ability of the TV to connect to the internet is valuable to me.

[deleted]

Re: Smart-TV blocklist for Pi-Hole

#238
post #233
post #204

Earlier quoted context omitted.

Google and Cloudflare don’t sell data on dns queries per their privacy policies. Verizon does.

I see this common response, but that is not really a valid rebuttable. Companies do not need to sell your data to violate your privacy, in the case of google their entire model is selling their TARGETING, not the data. That is still a violation of privacy. The fact they did not "sell" it to a 3rd party to form the customer profile changes little. In the case of cloudflare, it is going to be interesting how they conti…

Google doesn't sell targeting based on DNS queries.

> I am no more comfortable with cloudflare having my data than I am with google or verizion, I have never used any of their DNS services

It's not either/or. If you use Cloudflare or Google DNS and it isn't encrypted then Verizon has it too. With DoH they don't.

Re: Smart-TV blocklist for Pi-Hole

#239
post #234

Earlier quoted context omitted.

I have extra networking hardware. I wasn't aware I could have LAN->TV but not bidirectional communication. Is there a source you know of better than googling on how to achieve this, since you seem to imply it's different than searching about VLANs since it's wireless.

Technically you'd need bidirectional communication once a LAN->TV connection has been established. What I meant is to restrict connection establishment to only LAN->TV but not the other way around. In terms of configuring firewalls/etc, it really depends on your equipment, however in most cases there's already a catch-all rule to allow any established & related traffic so you only need to add a rule to allow the init…

My naive solution was going to be to assign the non-internet devices a smaller subnet with a bad gateway, and have all the "bridging" devices have IP addresses in that subnet, but with the real subnet and gateway. I'm sure VLANs are superior, but if you could tell me what's dumb about my idea I would appreciate it.

Meanwhile, do the VLANs allow the "enumerate devices" style multicast to come down from the regular LAN and be responded to?

Re: Smart-TV blocklist for Pi-Hole

#240

Earlier quoted context omitted.

>They would need to have a fallback in case people block DoH. How do you block DoH?

Blackhole 8.8.8.8, 8.4.4.8, 1.1.1.1, and 1.0.0.1. Technically, the provider could use something else, but are they so worried about ad blocking that they’ll run BGP anycast themselves?

Add 9.9.9.9, and the other IP. Besides 4.2.2.2 and 4.2.2.1. Also the IPv6 equivalents. There's almost an infinite number of DNS servers.
Post reply on HN