The business with the reset count tracking isn't necessarily as creepy as the shovelware/adware apks in the default image, or the serious information leak in activesync in the other Motorola thread.
I'm guessing the firmware update downloader sends some sort of hardware identifier, plus a firmware flash counter, to the update server. This would be the obvious way to prevent re-updating a device that reset itself or was manually reset after a firmware update hosed the system, which would trap the user in a loop. A (device id,firmware revision,reset count) table somewhere in the motosphere isn't exactly PRISM.
Outside a tiny number of hardcore custom ROM tweakers, 21 resets almost certainly indicates some sort of problem.
Resets also often change the android ID that much software uses to identify phones. So resetting may mean you have to opt-in to the beta testing again since it appears you have a different phone from some methods. It's pretty nuts this guy expects everything to work as normal when he reset the thing 21 times over. Resetting even once is a rare thing that many services won't be tested with.
Something not working because he reset actually proves why it is useful for custom support to have data on resets. Not that I would expect any hardware use data to be protected if I opted into a beta testing program. The whole point of that is to see how the hardware handles beta software.
Often with these programs the updates are just sent out at a certain time, so it's entirely possible to just miss the update period. Heck, I've seen that done with production updates, let alone beta ones. A friend with a Droid from Google IO didn't turn it on for a couple years, missed an update which was no longer available, and missed the termination of the free service to boot.
Upon turning on the phone and registering it on the network you must agree to the EULA. The only difference between your phone and a MOTOBLUR device is that you don't have a user created login. A random login is created for you to optimize the setup experience. If you don't connect any social networking applications your phone doesn't connect with our servers.
It involves a hardware ID, and a profile that is created when the device is initially synced. It may also send a "firmware flash counter" but it wouldn't be necessary.
I don't think so. I think his claim was that the hardware phones home under the Motorola firmware, and that the EULA hadn't spelled that out clearly, and that Motorola had not been as forthright as they should or that they may even have been deceptive.
Comments
The business with the reset count tracking isn't necessarily as creepy as the shovelware/adware apks in the default image, or the serious information leak in activesync in the other Motorola thread.
I'm guessing the firmware update downloader sends some sort of hardware identifier, plus a firmware flash counter, to the update server. This would be the obvious way to prevent re-updating a device that reset itself or was manually reset after a firmware update hosed the system, which would trap the user in a loop. A (device id,firmware revision,reset count) table somewhere in the motosphere isn't exactly PRISM.
Outside a tiny number of hardcore custom ROM tweakers, 21 resets almost certainly indicates some sort of problem.
Resets also often change the android ID that much software uses to identify phones. So resetting may mean you have to opt-in to the beta testing again since it appears you have a different phone from some methods. It's pretty nuts this guy expects everything to work as normal when he reset the thing 21 times over. Resetting even once is a rare thing that many services won't be tested with.
Something not working because he reset actually proves why it is useful for custom support to have data on resets. Not that I would expect any hardware use data to be protected if I opted into a beta testing program. The whole point of that is to see how the hardware handles beta software.
Often with these programs the updates are just sent out at a certain time, so it's entirely possible to just miss the update period. Heck, I've seen that done with production updates, let alone beta ones. A friend with a Droid from Google IO didn't turn it on for a couple years, missed an update which was no longer available, and missed the termination of the free service to boot.
This makes a whole lot more sense than "We don't want you to get the firmware because you've been naughty"
Mark explained it.
It involves a hardware ID, and a profile that is created when the device is initially synced. It may also send a "firmware flash counter" but it wouldn't be necessary.
But the OP said he was using cyanogenmod before, is he claiming that the hardware phones home even when he's not using the motorola firmware?
I don't think so. I think his claim was that the hardware phones home under the Motorola firmware, and that the EULA hadn't spelled that out clearly, and that Motorola had not been as forthright as they should or that they may even have been deceptive.