Comment Re:There is no way your data doesn't make it into (Score 1) 77
DUH. That's the play. They force you into a "service" as an "opt out." Then - oh, the free tier is insufficient. Or the free tier JUST GOES AWAY and then they're holding your computer hostage.
I doubt it. I'd bet it's more of a problem of feature parity with OS X. Even though Windows has backup and restore, it still gets ragged on for not handling device moves or replacements as nicely -- even though the main problem is users and/or app developers not turning it on. I'll bet that first MS offered the feature and left it to users to discover and enable, but hardly anyone did. Then they started nagging people to turn it on, and most still didn't. So now they're turning it on by default.
I saw this same story play out on Android (when I worked there), firsthand. Backup was added to provide feature parity with Apple and to reduce user complaints about lost data. But approximately no one turned it on. In Android there were actually two obstacles, because out of abundant concern for privacy the backup solution required both app developers and users to opt in. User opt-in improved when users were nagged to enable it at setup time, but then they were annoyed that when they restored a backup hardly anything was restored because hardly any app developers opted in. Eventually apps were opted in by default (app devs can still opt out, but most don't) and the feature became somewhat more functional -- except for apps that were broken by it because app developers didn't expect to have their app and its data suddenly appear on a different device.
I had a front row seat to this saga because the component I owned (Android Keystore) was a significant motivator for requiring apps to opt into backup. The problem is that Keystore's core purpose is to provide hardware-backed cryptographic key material which is permanently and irrevocably bound to the device (and is strongly guaranteed to be wiped on factory reset). When an app that uses Keystore keys has its data restored from backup and then tries to load one of its Keystore keys, it gets a null pointer. If the app developer didn't check for null, that turned into a NullPointerException, and if they didn't catch the NPE, their app crashed. Net result: after a restore, most banking and many other apps crashed on startup because one of the first things they do is try to use their keys to authenticate to their servers.
I designed a key backup and restore scheme but my scheme would require app developers to opt into key backup on a per-key basis, at key generation time, because adding any automatic backup/restore solution would have broken the fundamental security property of Keystore. The scheme was moderately complex because it tried very hard to make it impossible for Google to ever access the backed-up secrets, and it relied on some internal server infrastructure whose sole purpose was to make it possible for Google to store data it could not access. That infrastructure was expensive, fragile, high-maintenance and not much used so it was at risk of being turned down because the teams that used it couldn't afford to maintain it. Strongly authenticating the new device and the user before releasing secrets was also tricky. At the end of the day, I never launched the Keystore B&R scheme (though vestiges of it remain visible in the Keystore secure key import scheme, which was designed for B&R but is useful on its own. Specifically, the import format includes a "masking key" field that isn't really useful in the normal import flow, but was crucial to the scheme that kept the secrets impenetrable to Google).
At the end of the day, app developers eventually fixed their apps to deal with being restored, mostly, and forcing users to make a backup/no-backup decision during device setup generated high adoption. Android B&R works fairly well today (except where device OEMs screw it up), though people still complain that the whole system isn't as smooth or as seamless as iOS', I think mostly because Android apps can opt out, but iOS apps can't (AFAIK).