6 ms·

The obvious reason is that any local browser config pages cannot be SSL protected because the device can not provide a valid certificate for 192.168.0.33 or chr

by 05 8y ago

The obvious reason is that any local browser config pages cannot be SSL protected because the device can not provide a valid certificate for 192.168.0.33 or chromecast.local Phone app can use a custom TLS CA to make sure the stick was produced by Google and is not a rogue neighbor phishing for your WiFi password..

djrogers 8y ago
No, that's not how it worked - you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). You weren't browsing to any local devices...
- dragonwriter 8y ago
  > No, that's not how it worked Yes, it is; Chromecast activation has always used the Chromecast itself as the WiFi host; you have to do that to even set it up to use another network. > you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). TV apps can do that because the TV device is already configured to connect to a network. And both the app and your browser can connect to the same remote server. Chromecast activation can't work that way, since it occurs as a necessary prerequisite to connecting the Chromecast to a network.
  - RickS 8y ago
    (OP of complaint) This matches my understanding as well. 05's answer about security and rogue devices is a good one. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.
- TravisDick 8y ago
  I'm a little confused by this. If the chromecast didn't know my wifi password, how could it connect to google to receive any information / configuration? Mostly commenting because I want to know if there's some cool mechanism for getting around that! Thanks!
RickS 8y ago
Thank you for this answer. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.
- johncolanduoni 8y ago
  > For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change. Phishing by a random bad actor taking advantage of lack of TLS verification is far more likely than Google putting a sandbox escape in a phone app they distribute to steal information from you. I really hope most people's threat model doesn't match yours in this respect.
tinus_hn 8y ago
It is impossible to ‘make sure the stick was produced by Google’. That’s fake security which is even worse than no security.

by 05 8y ago

djrogers 8y ago

No, that's not how it worked - you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). You weren't browsing to any local devices...

dragonwriter 8y ago
> No, that's not how it worked Yes, it is; Chromecast activation has always used the Chromecast itself as the WiFi host; you have to do that to even set it up to use another network. > you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). TV apps can do that because the TV device is already configured to connect to a network. And both the app and your browser can connect to the same remote server. Chromecast activation can't work that way, since it occurs as a necessary prerequisite to connecting the Chromecast to a network.
- RickS 8y ago
  (OP of complaint) This matches my understanding as well. 05's answer about security and rogue devices is a good one. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.
TravisDick 8y ago
I'm a little confused by this. If the chromecast didn't know my wifi password, how could it connect to google to receive any information / configuration? Mostly commenting because I want to know if there's some cool mechanism for getting around that! Thanks!

RickS 8y ago

Thank you for this answer. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.

johncolanduoni 8y ago
> For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change. Phishing by a random bad actor taking advantage of lack of TLS verification is far more likely than Google putting a sandbox escape in a phone app they distribute to steal information from you. I really hope most people's threat model doesn't match yours in this respect.

tinus_hn 8y ago

It is impossible to ‘make sure the stick was produced by Google’. That’s fake security which is even worse than no security.