This does not need a special product. Any firewall will do, even a random consumer wifi router that has customizable firewall rules.
a) assign iot devices certain ip addresses
b) block all outgoing traffic from these

I have it done in a bit of more advanced way (VLANs), but thats not strictly necessary.

Also, note that this is the first time you cannot use your iphone headphones with your macbook.

Who uses an external drive for Time Machine? The only people I know who actually have a regular backup do it over the network either to Time Capsule or some kind of other NAS. I use Synology.

"So far it's been a matter of days since Apple released this computer and again we see a lag of devices."
It might be worth mentioning that the USB-C only "New macbook" was introduced a year and a half ago and is on its second iteration already.

At the same time the overheating problem would worsen threefold.

I play music in my car via bluetooth. I rarely charge my car.
I play music at home with a chromecast. I do not charge that either.
I use a wired headset in my office, but it it connected to my computer and I answer the phone through that.
All that with a phone that has a 3,5mm jack.

Hmm. A student has a phone with a dead battery at 09:30? In what universe?

You are talking about android specific forums, etc. I am talking about generel non-tech media. I stand by my statement.

Well, the fact that an ios vulnerability is newsworthy and android one is not, should tell you which is safer.

Well, I live on the other side of the planet. I have heard of Melbourne and know roughly where it is. I have never heard of Mildura which is 10x times smaller. Comparing the size of these blunders is like misplacing a toy truck vs a real motor vehicle.

It seems to be solved quite well on my 2014 Honda:
- qruise control keeps the speed, but lowers it if there is a car in front and keeps a configurale distance by automatically accelerating and decelerating (and braking if needed). It uses radar as opposed to Tesla's camera-only solution which is vulnerable to blinding low sunlight (which seems to be a possible culprit in this case).
- lane guidance steers to keep the car in lane if i switch it on. But if I let go of the wheel, it will soon give an audible and visual warning and soon disable itself.

This for me is unintrusive enough to use on a highway, yet it is strictly "driver assist" not self-driving, so I will not lose focus.

What do you mean "off the map"? There will be no such places.

Also - it is my understanding that most of the selfdriving car development is based on cameras - therefore a selfdriving car can continue on unmapped territories as well as with missing gps just as good as a human driver - using visual cues. If you need to give it instructions how to get to point b, you poke with a finger on a map or an arial photo on the screen and leave the immediate obstacles to the automation.

But all that aside - i mainly meant that the wheel is useless in an emergency situation.

I remember a quote from google selfdriving car team that there is no point in having a steering wheel in a self driving car, because the "driver" would never be able to take over in time to avoid any danger. Which makes sense. We should not switch to automated driving before we are ready to surrender all control.

You are advocating jumping on the VR bandwagon early as an opposite to being in your parent's basement?

You should really read up on some networking.

You are misguided if you think that just setting a private ip as a destination address the packet would reach from the internet to a NATted LAN. The router only routes packets to NATted subnets for which there are NAT entries - either from configuration or dynamic port mappings that usually are generated from NATting outgoing traffic. It would be dropped even without the SPI.

Do you mean that the attacker would forge packets to printer's tcp port 9100 as a forged answer to its outgoing DNS requests? That would again not work, as there is no NAT mapping in the router to printer's address port 9100 as a result of its DNS request unless the DNS request originated from port 9100...