I think this interpretation is a bit too negative. Undoubtedly the companies want to spy on you, and with Thread 1.3 they were already perfectly capable of doing so - via your Thread border router, which connects to the normal LAN and can talk to the Internet (if you let it). Allocating Thread devices from global IPv6 blocks (GUAs) doesn't change that, it just removes the NAT between Thread devices and the border router.

Before Thread 1.4 the IPv6 addresses used by the Thread network were all ULAs - i.e. the devices were only routable locally and didn't have a global IPv6 address, so if you did happen to want to talk to your Thread devices over the internet, it was possible but the Thread border router had to do NAT for you.

With Thread 1.4 the border router can assign device IPs straight from the global IPv6 block assigned by your ISP, which means you can directly access your Thread device over the internet without the NAT provided by the Thread border router.

If you don't want to locally host your smart home automations (you and I do, but the average consumer doesn't) this can be very useful. It's also really helpful if you want to access your own devices remotely over the Internet and not need to bother with port forwarding.

IMO this fits perfectly with the philosophy of IPv6 - every device can have a globally routable IP address without needing NAT.

If you don't want your devices reaching out to the Internet (like I don't), the solution is to put all that stuff on its own VLAN with no Internet access (which I do).

I think this interpretation is a bit too negative.

You wrote a long message to say that you agree with me technically, but then said that it has good uses as well. I don't disagree with that, but the problem with these companies is - you give them one finger and they take your whole hand. Besides that,

If you don't want to locally host your smart home automations (you and I do, but the average consumer doesn't) this can be very useful. It's also really helpful if you want to access your own devices remotely over the Internet and not need to bother with port forwarding.

this implies that this is not possible with Zigbee. You can use your devices remotely with Zigbee, but it is fully governed by your Zigbee hub/coordinator. You can use Home Assistant, the IKEA hub, the Samsung SmartThings hub, Homey, etc. to control your Zigbee devices remotely. The very big, but relevant difference is that the devices themselves cannot connect to the mothership to do analytics or to lock away functionality. There were already some Thread + Matter devices that required talking to the manufacturer's servers to get all functionality (I think e.g. some Nuki devices, but I might misremember).

If you don't want your devices reaching out to the Internet (like I don't), the solution is to put all that stuff on its own VLAN with no Internet access (which I do).

Putting Thread + Matter devices on a different VLAN than e.g. your phone which you are commissioning it with is very fragile. So fragile that most Matter documentation just says "your phone needs to be on the same WiFi network as your smarthome hub". It is possible (I had such a setup for a while), but requires that you e.g. do allow mDNS advertisements across VLANs (since Matter relies heavily on mDNS). Since you are talking about average consumers, Zigbee will give them privacy without any extra work, whereas with Thread + Matter they have to set up their network in a way that their ISP-provided router most likely doesn't even support.

Thread + Matter has no point outside very large deployments and giving a bunch of companies the opportunity to start data mining your sensor data as well.

> If you don't want your devices reaching out to the Internet (like I don't), the solution is to put all that stuff on its own VLAN with no Internet access (which I do).

Or, if there is already a perfectly functioning open standard that just works and it's private by default (ZigBee) boycott the new standard created and forced upon us by BigTech and don't buy that hardware.