No, it can be commandedfrom the Internet - big difference. It never has a direct connection to the Internet and even that is entirely optional and a hard opt-in (buying more hardware).
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!
As far as I know only Apple does the local network stuff. If a device is Alexa or Google Home compatible, it talks directly to some cloud service from the manufacturer on the Internet which then talks to Google or Amazon. So it connects directly to the internet, and moreover there is the additional attack/privacy surface of the manufacturer's cloud service.
Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).
We're still talking about the light bulbs, aren't we? Bulb --Zigbee--> Zigbee Gateway --WiFi/eth--> LAN. If further integration is desired, an Internet gateway can be used (could be a Google/Apple/Amazon box thing, but could also be a Pi with HomeAssistant!). How that gateway connects to the Internet is up to it - but at no point is either the lightbulb or its LAN gateway in any way connected to the Internet. Therefore, neither the bulb nor the gateway pose a direct security or privacy risk. All the security is offloaded to the gateway and you are entirely free to chose the vendor of your Internet gateway or indeed opt for none at all (and possibly use a VPN if external access is desired)
foobar33333 said "The gateway also does not connect to the internet", which cannot be true, because connecting to the internet to speak to a manufacturer-provided cloud service that then speaks to Google is required to integrate with Google Home. That's how it works. The IKEA gateway has to talk to an IKEA cloud service. If you think otherwise, please link to the Google Home docs that explain how that could possibly work, because I can't find them.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.
Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.
If that sounds stupid, congrats, this is why they call it the internet of shit.
This is why HomeKit is superior: when you’re in your home, it doesn’t need WAN to function. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Wifi —> iPhone.
When you’re away from home, iCloud will be used, and no IoT vendor systems come into play. This means that all IoT devices can be kept offline and limited to your LAN. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Hone Hub (Apple TV or iPad or HomePod) —> WAN —> iCloud —> WAN —> iPhone.
See, I have in fact set this up in the past, although not with IKEA lamps, but some other cheap Zigbee-compatible ones. The Zigbee-LAN gateway (along with all the other WiFi devices) sat on its own VLAN with no Internet access at all and a HomeAssistant box had access to both the IoT VLAN and the main one (that had Internet access). The HomeAssistant instance was configured with a dev account to work with Google's crap, but the devices themselves only ever talked to it, not Google or any vendor-provided server.
EDIT: Perhaps the terminology got somewhat twisted around here: when I talked about the LAN gateway, I meant specifically the thing that does Zigbee-LAN "translation". Now, that same physical box might also have the capability to work as a Zigbee-Alexa or Zigbee-Google transaltor, which would require a vendor server as you said, but those options are, well, optional. You can certainly disable them and use something like HASS or openHAB as the bridge to whatever cloud service you wish. Same way that my home router has a built-in VPN feature, but I don't use it because I run a VPN server on my NAS instead.
Of course, if you set up Home Assistant you can firewall them off the internet. That's how I do it too, with an IoT VLAN. It's not how these devices are intended to work, and not how they work if you just follow the manufacturer's instructions for Google/Alexa integration. You're replacing the vendor's cloud service with Home Assistant, effectively.
For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.
My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.
>If a device is Alexa or Google Home compatible, it talks directly to some cloud service
This is how some IoT devices work. As far as I can tell. IKEA has no servers or infrastructure for their devices. And the Apple/Google hubs manage everything for them.
IKEA has to have servers for their devices to integrate with Google Home and Alexa. That's how those systems work. Only Apple offers direct local connectivity as far as I know.
These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.
I don't know how the IKEA hardware works. However it is not true that Alexa has to talk to a cloud service to integrate with all IoT devices.
I know this because I run some local Raspberry PIs that pretend to be WeMo devices and I'm able to control them without any cloud connections from the PIs. The echo discovers the WeMo devices via upnp.
This has been a thing for quite a while[0].
I believe you are correct that Google Home has no local network device control.
The IoT device can certainly work like that. The comment is specifically talking about Google Assistant support, which as HomeAssistant users have experienced, does require cloud server access even if this seems unnecessary in cases when the devices are only being controlled within a local network.
> No, it can be commanded from the Internet - big difference.
Big difference from what?
You do realize that the vast majority of remotely exploitable security vulnerabilities are in software which can be commanded from the Internet, right?
Source?? I'm quite certain that it's much harder to exploit something that you can't even send a TCP packet to. If the device is only directly connected to the hub (amazon/google/apple box) and the hub is only connected to the cloud service, how would you even send a payload to the device, even if an exploit existed?
You could exploit the cloud service directly and gain control of the device, but that's like stealing the security guard's master keys - you can't call that a vulnerability in the door lock, can you?
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!