I believe that Apple uses something similar to their "Handoff" mechanism, described in the "Apple Platform Security Guide" [1]. This uses Bluetooth Low Energy out of band paring to establish a shared key. I believe it uses the same identity keys as iMessage to establish the shared key - so you can only offer to share the WiFi password with someone you've been talking to over iMessage and you will see the name of the person you are going to share it with. Sharing the WiFi password is secure from eavesdroppers.

The Bluetooth-less mechanism for WiFi only is an absolutely terrible idea and implementation. It actively leaks the network password to anyone listening. I refuse (and return) any device that requires me to connect it to my IOT network in this way. One can usually detect if this is the setup mechanism by looking at the instructions: (1) Download an App, (2) do something to the bulb (power cycles usually) (3) Setup happens automatically! I think some network stacks don't let non-privileged apps send broadcast addresses, so perhaps the scope of this damaged mechanism is limited.

It is better if the ESP8266 is put into a low power Access Point (AP) mode and configure that way - but due to this (usually) not being an encrypted WiFi session, there is also a risk of leaking the network secret unless a way to do a secure key exchange is bootstrapped in the html form or API. Both of these are possible if Javascript is enabled or via an App API. The instructions for doing this might also include downloading an App, but it also ought to require finding and connecting to a setup AP first.

I guess the best way to kill the "leak the password" mechanism is for a better mechanism to be created and incorporated into something like Tasmota or other public IOT ESP8266 codebase so it can be copied.

[1] https://help.apple.com/pdf/security/en_US/apple-platform-sec...