Comment 21 for bug 1069531

Could be missing something but believe the solution was:
"So the solution seems to be to remove an old Google Account that was configured with a(n application-specific) password and add a new one with OAuth2 using your regular password (+ phone code) and allowing Ubuntu to access your account."

If so, doesn't that imply that a user would be forced to set-up 2-step verification if they were not using it already? What about users that don't have a phone to use with 2-step verification? From the instructions on Google, understand that you can generate an application specific password for Ubuntu and not require a phone, but what about other applications that involve a Google account; would you not require a phone for those?

Is this a correct assessment - if not, please could you expand upon the solution?

For info:
* Removed all accounts, checked seahorse and ensured any stored information was removed.
* Re-created the Google account only.
* Seahorse stores two entries, one containing the account password (right click > properties shows "signon-type: 1").
* The other entry appears to be urlencoded (right click > properties shows "signon-type: 3").
* Unable to see from seahorse source code where signon-type is returned from or what it suggests about the data stored (not a programming expert, did find the approximate place in seahorse-gkr-item-properties.xml where the graphical elements are defined, cannot see where the application gets the data though).
* Have attempted to urldecode the information stored, wasn't able to do this completely cleanly, and due to security concerns will not paste the whole string into this comment.
* However, basic layout of data stored appears to be:
Tokens<random_string>.apps.googleusercontent.com timestamp Py refresh_token Token <random_string>Expiry

A little research suggests this data may be being stored for use when creating an OAuth token, see also:
http://code.google.com/p/google-mail-oauth2-tools/wiki/OAuth2DotPyRunThrough