Glenn's broken record is: let's talk about security on the local link: I've written about this before, but it's worth repeating. None of the municipal Wi-Fi networks I've read about have any consideration for security over the local link. They all imply that there's either no security risk or those with interest in protecting their passwords for POP email and other unencrypted services use a VPN (virtual private network) to tunnel all of their vulnerable data inside an encrypted stream that's not vulnerable over Wi-Fi or even wired Internet.
This explains Google VPN experiment. If it's unreasonable to expect everyone on a muni network to use a login name and password over Wi-Fi (using WPA Enterprise), or if it's impossible to have Wi-Fi bridges preconfigured with this authenticated method, then most users will be sending their data in the clear along with lots of passwords. (My co-authored Take Control of Your Wi-Fi Security ebook just out has a section detailing precisely the kind of data that's passed in the clear by default, and what's encrypted.)
Fundamentally, supporting encryption requires more homogeneity or it incurs a large support expense. Providing users with bridges that are preconfigured to use encryption would be the easiest method as it would circumvent the security issue. But those who don't want to use bridges, or who are using the Wi-Fi in public places, still need some kind of client software that works on their platform (including Linux, FreeBSD, Windows 98SE, etc.), and that's simple to support over the phone.
The local link is the weak link because if the traffic is sent in the clear, an enterprising young thief just drives around, sucks down lots of data, extracts unencrypted POP passwords (which are often the same as a user's password elsewhere), along with anything else the user sends in the clear, and is off and running on fraudulent activity and identity theft.
In fact, it's so obvious that it's a given that the first time that a large-scale unencrypted local link Wi-Fi cloud powers up that there will almost immediately be this kind of behavior resulting in criminal acts.
Thus the Google VPN. If Google runs the municipality and throws in not just free usage but also free VPN service, then it sidesteps security. If you ask Google about security if they win the bid for installing San Francisco's network, they'll say, we offer every visitor and resident a free VPN to bypass that problem. Not all SF Wi-Fi users may decide to use the VPN or understand how to install it, but Google wins the argument by offering a powerful and free method for those who can manage it.
Configured correctly, locally subnetted computers and other devices are still reachable, while all Internet resources pass through encryption.
I've made this argument before only to be told by people who blame the victim and expect far too much especially from the average currently unconnected user that users should employ application-specific encryption methods, such as POP over SSL and SFTP. Yeah, right.
Securing the local link in a simple, free, and default method is the only way in which a municipal network won't become the basis of massive fraud.
We should of course be doing both. All ISPs and all corporates that provide email services should be encouraging and perhaps enforcing the use of POP3 and SMTP AUTH over SSL/TLS[1].
And incidentally, it's about time the email anti-virus companies understood TLS. The most common reason for TLS failing to work is an antivirus package on the client.
I believe it's helpful to clarify that a VPN at a minimum gives you data privacy--but what about the other elements (authentication and data integrity)? It's important to note that discussions of security needs to encompass all of the above.