Wi-Fi sensibility: Not really risky, but not really needed

Windows 10—bear with me—has shipped, but this column isn’t about the new operating system, which has received generally positive reviews from our friends at PCWorld and elsewhere. Rather, it’s about a feature that started receiving attention a few weeks before release and more on the ship date: Wi-Fi Sense.

Wi-Fi Sense allows Windows 10 users to connect automatically to open Wi-Fi networks, as well as to share access to Wi-Fi networks for which they have passwords. The former isn’t controversial at all: iOS allows carriers to set up automatic connections to networks they run or partner with as of several releases ago. Many apps for mobile devices and computers also allow this.

The latter could be a problem. The case has been both overstated and understated, and it’s tangential to you if you don’t use Windows 10 (including Windows 10 Mobile), but you’ll still be subject to Windows 10 users who have access to any networks you run or use.

Senseless Wi-Fi lends

A Windows 10 user logged into a Microsoft account with Wi-Fi Sense active (which is on by default, but can be turned off) who is given or has a password to a Wi-Fi network that uses “personal” style protection can opt to share access to that network with anyone in her or his Outlook.com contacts, Facebook friends, and Skype contacts. The system doesn’t share “enterprise” flavors (such as the dominant WPA2 Enterprise), which require individual user certificates or user-and-password logins.

Any Windows 10 user can access networks from other Windows 10 users who include him or her in their contacts unless they disable the feature. The proviso is that one can only use shared Wi-Fi network information if one has already shared a network. If someone never participates by using Wi-Fi Sense to share, that person never gains access to contacts’ shared network.

Microsoft’s implementation sounds reasonably clever. The Wi-Fi password is both encrypted and sent securely from a user’s Windows 10 system joining the network. However, this relies on Microsoft managing the encryption keys. Microsoft notes, “Your contacts don’t get to see your password, and you don’t get to see theirs,” and while that’s true, the password does need to be decrypted within Windows 10.

Microsoft only allows first-degree sharing—the person connecting to a network can share only with their friends, and those contacts cannot share in turn with others. It also requires that for each network joined for which a password is entered, that a user must agree to share it, and can choose over which social networks the Wi-Fi network is shared.

(Earlier reports either said or implied that the default Wi-Fi Sense setting not just opted users into being able to use it, but automatically shared joined networks. Colleague Ed Bott put the kibosh on that.)

This prevents an actual network effect, in which sharing a network would quickly cascade across six degrees (whether Kevin Bacon is involved or not), so that every Windows 10 user would have access within a few weeks to every shared network by any Windows 10 user. Microsoft’s design prevents that.

Windows 10 also puts in a kind of local firewall for users who access a network through Wi-Fi Sense, which is very similar to the Guest network feature added to Apple base stations a few years ago. Locally available resources—like computers, home-sensing devices, printers, and the like—can’t be reached because Windows doesn’t provide network routes to them.

Sense and Sense’s ability

Microsoft’s approach is better thought out than the advance word led me to believe. At each opportunity for access to be spread farther or potentially expose network users, they’ve clamped it down. However, it does introduce risk by allowing first-degree acquaintances of those who have password-based access to a given network and who choose to share it.

As with all such risks, the question is how useful is that vulnerability to exploit, and how much effort would it take? Malware targeting Windows 10 could potentially intercept or decipher passwords delivered for network access. (The passwords must be locally cached in some fashion, because without Wi-Fi network access, Windows couldn’t request the encrypted form on demand to connect to the network in question.)

And while Windows 10 blocks access to local resources, it’s possible again that malware could bypass that resistance, and that block doesn’t exist if someone recovers the password. However, on balance, it seems unlikely that there’s a good vector to exploit that would harvest enough passwords or network access that were useful enough assuming malware could be developed to do so, because the value of a Wi-Fi password is only in your physical proximity to a network. A Wi-Fi password doesn’t help with a remote network break in.

Apple chose a very different approach with syncing Wi-Fi passwords. Starting in iOS 7.0.3 and OS X 10.9, enabling iCloud Keychain copies Wi-Fi passwords among all devices that use the same iCloud login and likewise have the keychain feature enabled. This is nice at coffeeshops: I’ve logged in using a password on my iPhone, and then my laptop automatically connects a moment later. Passwords are protected using encryption information particular to you. Even though it’s synced via iCloud, Apple lacks the pieces necessary to decrypt those items. (This is distinct from photos, contacts, and the like that can also be viewed at iCloud.com, which by necessity Apple has to decrypt to show to you.)

Microsoft provides a couple different opt out methods. Windows 10 users can disable the feature (Settings > Network & Internet > Wi‑Fi > Manage Wi‑Fi Settings). As soon as a Windows 10 user turns off Wi-Fi connection sharing, all of that person’s entries are no longer available to contacts, and vice versa.

And there’s an opt out at the base-station level, if you want your network to remain unusable by Windows 10 people you know. Microsoft says add _optout anywhere in the network’s name, such as Glenn Home Network_optout or even Hey_optout_this_network. That’s similar to Google’s _nomap option to prevent a base station’s inclusion as a data point in Google Location Services.

An AirPort base station user can make this configuration change by launching AirPort Utility, selecting the base station, and clicking Edit (enter its password if prompted). In the Wireless tab in OS X, rename the network in Wireless Network Name. If you have multiple base stations with the same name for roaming, rename all of them identically.

This is a hassle, because the changed name means that all of your devices that connect to the base station have to be re-associated to the new name, and the password entered again for each device, except those synced via iCloud Keychain after you enter the first one.

Obviously, changing a network’s password will prevent the shared version from working until the sharing user updates the connection, if they’re even given the new password. But it has the same problem of requiring re-entering the password on routinely connected devices.

Should Microsoft have deployed this feature? I suppose. It seems like guest networking, widely available on Apple and non-Apple Wi-Fi routers, is an easier solution. For users who are capable of entering a password correctly and choosing to share it, enabling guest networking on a modern router doesn’t seem impossible difficult and it’s easier to control or change.

It has such a feel of a marquee feature that sounds good, but in practice offers very little to the most likely users. But it doesn’t seem to open up networks to easy exploitation or on any real scale.