Google and OAuth 2.0
Gervase Markham
Is this relevant to Thunderbird accessing Gmail?
Gerv
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Ludovic Hirlimann
> http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html
>
> Is this relevant to Thunderbird accessing Gmail?
>
>
Ludo
--
[:Usul] MOC Team at Mozilla
QA Lead fof Thunderbird
http://sietch-tabr.tumblr.com/ - http://weusepgp.info/
Joshua Cranmer 🐧
> http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html
>
> Is this relevant to Thunderbird accessing Gmail?
Ugh. We've WONTFIX'd adding OAuth 2.0 support to IMAP in the past. The
problem with OAuth is that the authorization steps are completely
separate from the low-level SASL steps in IMAP and friends, and the SASL
portion gives you no insight into how to perform the HTTP steps of
authorization (i.e., it doesn't tell you which HTTP server to talk to).
It's worse than GSSAPI in this regard because at least GSSAPI has a
standardized platform C API that allows you to pass off the
communication steps to the third party.
Oh, and IIRC, OAuth requires you to provision a "secret" identifier for
your application, which is rather hostile for open-source applications
since checking it into our public repository is not likely to go over
well. :-(
OAuth 2.0 makes some amount of sense if your application only cares
about talking to Google's server. For a generic IMAP client, it is
really hostile to your userbase. I find Google's attempt to make
traditional authentication steps (even relatively secure SASL steps?)
more difficult for users to use to be rather hostile to users and clients.
[Granted, they also seem to like the idea of locking you out of your
account if you try accessing it from a different country, as I found
much to my chagrin when I tried checking email in Toronto... or was that
Facebook? or both?]
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
Gervase Markham
> On 4/25/2014 10:52 AM, Gervase Markham wrote:
> Ugh. We've WONTFIX'd adding OAuth 2.0 support to IMAP in the past. The
> problem with OAuth is that the authorization steps are completely
> separate from the low-level SASL steps in IMAP and friends, and the SASL
> portion gives you no insight into how to perform the HTTP steps of
> authorization (i.e., it doesn't tell you which HTTP server to talk to).
> It's worse than GSSAPI in this regard because at least GSSAPI has a
> standardized platform C API that allows you to pass off the
> communication steps to the third party.
>
> Oh, and IIRC, OAuth requires you to provision a "secret" identifier for
> your application, which is rather hostile for open-source applications
> since checking it into our public repository is not likely to go over
> well. :-(
Would it make sense to comment on the blog post, raising these issues
(in particular, the problems for open source clients)?
Gerv
Kent James
> Ugh. We've WONTFIX'd adding OAuth 2.0 support to IMAP in the past
actually have some resources), Thunderbird would be a universal platform
for supporting all sources of streaming data, which would include both
public-spec IMAP was well as "Gmail". That doesn't mean that we have to
like each separate approach (as long as it is not clearly A Bad Thing).
But Gmail is so important that I don't think we have much choice other
than to support access through whatever access mechanism they throw at
us. It would be good to keep it separate though from public-spec IMAP so
that we are not encouraging proliferation of stuff that we don't believe in.
On OAuth itself I don't know enough to have an opinion whether it is
good or bad.
:rkent
Andrew Sutherland
> Oh, and IIRC, OAuth requires you to provision a "secret" identifier
> for your application, which is rather hostile for open-source
> applications since checking it into our public repository is not
> likely to go over well. :-(
From https://developers.google.com/accounts/docs/OAuth2#installed:
"The process results in a client ID and, in some cases, a client secret,
which you embed in the source code of your application. (In this
context, the client secret is obviously not treated as a secret.) "
The Firefox OS Gaia calendar app uses oauth2 for accessing google
calendar. You can find its code at
https://github.com/mozilla-b2g/gaia/tree/master/apps/calendar including
the secret it uses to talk to Google. Grep on 'oauth' for the good stuff.
> OAuth 2.0 makes some amount of sense if your application only cares
> about talking to Google's server. For a generic IMAP client, it is
> really hostile to your userbase. I find Google's attempt to make
> traditional authentication steps (even relatively secure SASL steps?)
> more difficult for users to use to be rather hostile to users and
> clients.
I think this is unfair. A user's Google account is potentially a
gateway to a mountain of personal and private information and a
username/password is a fairly blunt instrument. While it's very
possible to make a case that Google's application-specific passwords
should support scoping so you can say "this password is just for gmail",
that's effectively what their oauth2 implementation accomplishes, and
with arguably better UX since it allows Google to be the entity
describing to the user what abilities they are granting to Thunderbird
if the user says yes.
(Not that Thunderbird wouldn't try and describe what it needs/wants very
accurately, but in an adversarial system, you can't trust things that
aren't Thunderbird to be honest about what they are going to get up to.
And they are indistinguishable from Thunderbird for our purposes here.)
Andrew
Patrick Cloke
On 04/25/2014 12:35 PM, Joshua Cranmer 🐧 wrote:From https://developers.google.com/accounts/docs/OAuth2#installed:
Oh, and IIRC, OAuth requires you to provision a "secret" identifier for your application, which is rather hostile for open-source applications since checking it into our public repository is not likely to go over well. :-(
"The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.) "
The Firefox OS Gaia calendar app uses oauth2 for accessing google calendar. You can find its code at https://github.com/mozilla-b2g/gaia/tree/master/apps/calendar including the secret it uses to talk to Google. Grep on 'oauth' for the good stuff.
Magnus Melin
On 25/04/2014 17:52, Gervase Markham wrote:http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html Is this relevant to Thunderbird accessing Gmail?It looks like it - plz file a bug ..... Ludo
Joshua Cranmer 🐧
> On 04/25/2014 12:35 PM, Joshua Cranmer 🐧 wrote:
>> Oh, and IIRC, OAuth requires you to provision a "secret" identifier
>> for your application, which is rather hostile for open-source
>> applications since checking it into our public repository is not
>> likely to go over well. :-(
>
> From https://developers.google.com/accounts/docs/OAuth2#installed:
> "The process results in a client ID and, in some cases, a client
> secret, which you embed in the source code of your application. (In
> this context, the client secret is obviously not treated as a secret.) "
I know that Firefox was requested by Google to hide its Google API keys.
>> OAuth 2.0 makes some amount of sense if your application only cares
>> about talking to Google's server. For a generic IMAP client, it is
>> really hostile to your userbase. I find Google's attempt to make
>> traditional authentication steps (even relatively secure SASL steps?)
>> more difficult for users to use to be rather hostile to users and
>> clients.
>
> I think this is unfair. A user's Google account is potentially a
> gateway to a mountain of personal and private information and a
> username/password is a fairly blunt instrument. While it's very
> possible to make a case that Google's application-specific passwords
> should support scoping so you can say "this password is just for
> gmail", that's effectively what their oauth2 implementation
> accomplishes, and with arguably better UX since it allows Google to be
> the entity describing to the user what abilities they are granting to
> Thunderbird if the user says yes.
(Reads documentation a little more closely)
Okay, at the very least, Google's documentation is completely horrid: I
didn't realize that it was possible to recover the bearer token without
having to scrape UI from a webpage.
I don't disagree that external authorization mechanisms are necessarily
a bad thing. However, I think that OAuth fails to be an effective mechanism:
1. The mechanism is trivial to internalize: you need to be able to
control an HTML form and http[s] calls manually, which isn't a terribly
hard task for many applications [e.g., Thunderbird's current OAuth 2
accesses do this]. Once you internalize the authorization, you still get
the username and password and effectively complete access.
2. Critical authorization tokens are passed in plaintext on URIs. So if
you can sniff this URI somehow, even without full control over the
authorization, you can still do large worlds of hurt. And URIs are
generally handled far more carelessly than, say, POST data.
3. There's no standardized way to access the authorization mechanism. In
GSSAPI, to request access an IMAP access token, you load a platform
library [typically], and you call an RFC-standardized function with
RFC-standardized parameters that indicate that you're looking for an
IMAP access token. In contrast, the SASL OAUTH step just has the client
access with a Bearer token it got from... who knows? The server, pages,
request parameters, etc., are never hinted at in the authentication
step, so the only way you can know these values are to manually hard
code them for every site.
It's #3 that makes me so resistant to this feature.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Andrew Sutherland
> I don't disagree that external authorization mechanisms are
> necessarily a bad thing. However, I think that OAuth fails to be an
> effective mechanism:
> 1. The mechanism is trivial to internalize: you need to be able to
> control an HTML form and http[s] calls manually, which isn't a
> terribly hard task for many applications [e.g., Thunderbird's current
> OAuth 2 accesses do this]. Once you internalize the authorization, you
> still get the username and password and effectively complete access.
You receive a scoped-to-email access credential that is different from
the user's normal site-wide Google login credentials. Compromise of the
token is a pretty big deal given the importance of email, but it's less
bad than compromise of the entire account. But if it is compromised:
1) Google has a better chance of detecting the compromise and only
cutting off that specific token, rather than trying to lock-out the
entire account/etc. (Noting that they can already do this with
application-specific passwords. Those are just more dangerous. And
require even more manual intervention on the part of the user.)
2) Compromise of this token does not require the user to change their
password, it just requires them to revoke the access credential and have
Thunderbird request a new token.
> 2. Critical authorization tokens are passed in plaintext on URIs. So
> if you can sniff this URI somehow, even without full control over the
> authorization, you can still do large worlds of hurt. And URIs are
> generally handled far more carelessly than, say, POST data.
The URIs travel over https. If you can sniff the URI over the network
then you can sniff everything else.
If you're talking about Thunderbird being careless with URIs, then that
sounds like a Thunderbird problem, not an oauth problem.
> 3. There's no standardized way to access the authorization mechanism.
> In GSSAPI, to request access an IMAP access token, you load a platform
> library [typically], and you call an RFC-standardized function with
> RFC-standardized parameters that indicate that you're looking for an
> IMAP access token. In contrast, the SASL OAUTH step just has the
> client access with a Bearer token it got from... who knows? The
> server, pages, request parameters, etc., are never hinted at in the
> authentication step, so the only way you can know these values are to
> manually hard code them for every site.
As documented at
https://developers.google.com/accounts/docs/OAuth2Login#discovery,
Google exposes their openid data at
https://accounts.google.com/.well-known/openid-configuration
openid-configuration is documented in the IANA Well-Known URIs registry:
https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
Now, there is the big question of how to generically end up at the
accounts.google.com domain; that webpage says you should hardcode it. I
agree that that hard-coding is not great. It would be better if that
file was also accessible at
https://gmail.com/.well-known/openid-configuration (404). There is a
https://gmail.com/.well-known/host-meta from the webfinger experiments
from a few years back, so it seems possible to request that such a file
be added.
There is also the question of how we know what scope to use.
https://developers.google.com/gmail/xoauth2_protocol tells us to use the
scope "https://mail.google.com/". This is not an inherently obvious
transformation for an automated mechanism. Ideally this could also be
put in something under https://gmail.com/.well-known/.
So I would say:
1) It makes sense to work with Google to avoid anyone having to hardcode
Google-specific paths in their app. They provide SRV records for
_imaps._tcp.gmail.com, so they clearly are already trying to do this.
2) Gmail is already a special-case inside Thunderbird in many places,
oauth2 is not a Google-specific invention, and Thunderbird already has
an ISP database for this exact purpose (recently extended to provide
login URLs! https://bugzil.la/973005).
Andrew
nea...@gmx.de
> FWIW Thunderbird already includes OAuth2 code that is used (in order
> of history):
> - chat (for Twitter)
> - FileLink (for a bunch of things?)
> - Calendar (for Google Calendar)
>
> I forget whether we save the oauth secret key in a preference or in
> the account manager, but we store the consumer secret / key in prefs
> for Twitter. (Instantbird and Thunderbird have different keys here.)
>
> It'd be convenient in some way if we could only have to sign in once
> for all these uses...but that's probably a pipe dream.
extension (running with TB/FX/SM) each applications need to request it's
own keys. We store each key set to the individual PW manager.
And yes, the key exchange works with plain text as Gervase mentioned.
Guenter
Joshua Cranmer 🐧
> On 04/25/2014 02:47 PM, Joshua Cranmer 🐧 wrote:
>> I don't disagree that external authorization mechanisms are
>> necessarily a bad thing. However, I think that OAuth fails to be an
>> effective mechanism:
>> 1. The mechanism is trivial to internalize: you need to be able to
>> control an HTML form and http[s] calls manually, which isn't a
>> terribly hard task for many applications [e.g., Thunderbird's current
>> OAuth 2 accesses do this]. Once you internalize the authorization,
>> you still get the username and password and effectively complete access.
>
> You receive a scoped-to-email access credential that is different from
> the user's normal site-wide Google login credentials. Compromise of
> the token is a pretty big deal given the importance of email, but it's
> less bad than compromise of the entire account. But if it is compromised:
What I mean is that the page which Google uses to ask you for your
username and password is effectively under the control of the
application, so it can still be possible to intercept the password.
> If you're talking about Thunderbird being careless with URIs, then
> that sounds like a Thunderbird problem, not an oauth problem.
Thunderbird itself isn't impacted by this problem, but it is a potential
security hole in websites if they aren't careful.
> 1) It makes sense to work with Google to avoid anyone having to
> hardcode Google-specific paths in their app. They provide SRV records
> for _imaps._tcp.gmail.com, so they clearly are already trying to do this.
I'd rather see Google's documentation indicate how to discover the OAuth
information to use instead of giving you the hard-coded strings, and I
would like to see a solution rolled out before adding support for SASL
OAuth2 to Thunderbird. I've been made cynical so that I don't believe
it's going to get done until I see it get done.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Ben Bucksch
> http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html
>
> Is this relevant to Thunderbird accessing Gmail?
end of pure email protocols.
There are big ramifications here. For me, one of the primary purposes of
Thunderbird is to keep email an open and viable communication method,
and to preserve open standards that can be implemented by anyone. In
other words, one of the purposes of Thunderbird is to allow for other
clients as well, on all kinds of platforms, for all kinds of usecases,
not all of which are interactive (see e.g. Android app "SMS Backup+").
By supporting OAuth in Thunderbird, we make it more likely that Google
will make such obnoxious auth methods mandatory at some point in the
future. While it may be possible for Thunderbird to open a web browser
window, it is not possible for other clients. Any email client would
have to have a web browser, which I personally find ridiculous and
dangerous. More generally, right now, ISPs are limited to what the IMAP
standard allows, and to the specific purpose of email. If we open a
browser window and make auth dependent on that, it means that we hand
control entirely over to Google. Google can do in that window whatever
they want, and make completely arbitrary demands on IMAP users.
Currently, IMAP sets the rules. This would be over. So, I consider this
to be a very dangerous move for the freedom of email.
We cannot let a single provider do whatever they want. Even more so when
that single provider has 20% of the user base. Then it's all the more
dangerous, because there's nobody to keep them in check.
Although many people think that, I do not think that Internet == Web.
Email is a service of the Internet that is entirely separate from the
Web. If we allow IMAP login to depend on a HTML webpage and/or HTTP, we
have not only introduced a huge, and security-wise dangerous dependency,
but also removed the ability for automation. We then require a human to
log in.
Email != Web. We cannot allow email to depend on the web, or proprietary
auth mechanisms. Playing along here will be highly damaging to email and
the Internet. We need to insist on the email standards. This is
Thunderbird's mission.
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
Quote: ' "Embrace, extend, and extinguish" is a phrase that the U.S.
Department of Justice found was used internally by Microsoft to describe
its strategy for entering product categories involving widely used
standards, extending those standards with proprietary capabilities, and
then using those differences to disadvantage its competitors.'
That's precisely what's happening here. Google's strategy is to bring
everything to the web, and everything on their services and servers.
Including email.
They are
1. "entering product categories involving widely used standards" --
email, using gmail
2. "extending those standards with proprietary capabilities" -- OAuth
for IMAP, this is happening right now
3. "using those differences to disadvantage its competitors" -- because
soon you won't be able to use an email client without a web browser,
which is a huge disadvantage for most situations where IMAP/SMTP is
used. So why not use GMail web frontend straight? Email dead.
I don't care what rationale they use. Steps 2 and 3 are dangerous.
What are all the other non-interactive email clients going to do?
(FWIW, I don't buy that "security" argument either way. Forcing me to
enter a working phone number - *any* (!) number, BTW -, just to access
my own account, doesn't count as "security" for me, but as privacy
violation.)
Google knows they can't just cut off Thunderbird. The blog post didn't
say they will, it's vaguely phrased. This is power play, and they are
testing waters. But if they go ahead with this and require OAuth or
otherwise make using Thunderbird hard, we need to jump up and down in
the press and cry "foul". I'm not giving in.
We've seen all this with Microsoft. We've seen where this led us. Let's
not repeat mistakes of the past. Keep the big picture in mind. Our
opponents surely do.
I think it's very important for the future of the Internet that we
oppose such attempts "Embrace, extend, and extinguish". No matter from
which angle or with which rationales they come.
Ben Bucksch
> the page which Google uses to ask you for your username and password
> is effectively under the control of the application, so it can still
> be possible to intercept the password.
heh. That's a very nice point.
All that steems from the fact that OAuth was designed for websites: One
website wants access to webservices from another website. All the
choices - client secrets (kept by the server), entering the password on
the service site (protected by cross-origin barriers of the browser),
making it a webpage in the first place - make sense in that context.
Many of them make absolutely no sense in the context of desktop client
applications (e.g. Thunderbird) or even non-interactive processes (e.g.
sync).
Gervase Markham
> I think we should actively oppose this, because this is the start of the
> end of pure email protocols.
needs to be led by someone with a good understanding of how it works now
- which is not me.
But the sort of questions I would want to find answers to are:
* What does Google hope to gain by making this change? Is it an
anti-spam/anti-fraud measure?
* Can the additional data about logins that Google hopes to obtain be
obtained in other ways for IMAP?
* Why can't single-service passwords continue to be used instead?
* Do they understand the ramifications of the idea that clients of all
these protocols will need to contain a browser? (Is that actually so?)
* Are there any ramifications on open source software in particular?
(Seems from the discussion that the answer is actually no, but we need
to be sure.)
* Who are the other desktop email software providers, and what are their
opinions?
Gerv
Ben Bucksch
> But the sort of questions I would want to find answers to are:
>
> * What does Google hope to gain by making this change? Is it an
> anti-spam/anti-fraud measure?
anti-account-theft.
2. When that triggers, they demand a working phone number, where they
send an activation code. Strangely, that can be any phone number. They
pretend that's for "security", but the "nice" side effect for them is
that using a phone number, they can link the account to a real life
identity. Given that they also link the account to all searches I make
on Google, that's a privacy invasion for me. But for Google, that means $$.
3. Long-term, their goal is to move everything (Internet and offline) to
the web, and to their servers. They want to kill MS Office, email, phone
etc., moving it to gmail, google cloud etc. They are not doing all this
for fun, after all.
> * Can the additional data about logins that Google hopes to obtain be
> obtained in other ways for IMAP?
interest.
If a suspicious login attempt shows up via IMAP or SMTP, they can return
an error (in IMAP/SMTP) *with* an error message that mentions reason and
remedy, e.g.
"You are logging in from a new country. Please log in via
https://www.gmail.com first and approve this connection."
This is (more or less) how some German freemail ISPs do it.
This is a manual hand-over, but a) would happen only in really
problematic cases b) give them the same possibilities as now.
> * Why can't single-service passwords continue to be used instead?
> * Do they understand the ramifications of the idea that clients of all
> these protocols will need to contain a browser?
aware, but want to force that. They want to force everything to their
website, so they want all devices to have a webbrowser.
> * Are there any ramifications on open source software in particular?
with client software, and open source all the more. OAuth is designed
for websites, where the server can easily keep secrets.
> * Who are the other desktop email software providers, and what are their
> opinions?
Axel Grude (Axel)
Software Developer
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate4)
AMO Editor
Gervase Markham wrote, On 28.04.2014 16:58:
But the sort of questions I would want to find answers to are:1. They block login attempts from a new country. Presumably that's anti-account-theft.
* What does Google hope to gain by making this change? Is it an
anti-spam/anti-fraud measure?
2. When that triggers, they demand a working phone number, where they send an activation code. Strangely, that can be any phone number. They pretend that's for "security", but the "nice" side effect for them is that using a phone number, they can link the account to a real life identity. Given that they also link the account to all searches I make on Google, that's a privacy invasion for me. But for Google, that means $$.
3. Long-term, their goal is to move everything (Internet and offline) to the web, and to their servers. They want to kill MS Office, email, phone etc., moving it to gmail, google cloud etc. They are not doing all this for fun, after all.
* Can the additional data about logins that Google hopes to obtain be
obtained in other ways for IMAP?
You can't ask for a phone number via IMAP. But I reject that premise and interest.
If a suspicious login attempt shows up via IMAP or SMTP, they can return an error (in IMAP/SMTP) *with* an error message that mentions reason and remedy, e.g.
"You are logging in from a new country. Please log in via https://www.gmail.com first and approve this connection."
This is (more or less) how some German freemail ISPs do it.
This is a manual hand-over, but a) would happen only in really problematic cases b) give them the same possibilities as now.
nea...@gmx.de
> don't they already do something like this (I think you have to enable
> IMAP access through their web site first). The bigger issue would be
> if that would have to be done on every session (?)
key for your application with the first time you log into GMail. Getting
that you probably need to use a browser page, also Lightning hides that
process from the user.
That access key will be used to generate a token to work with your
mail/calendar. That token will expire after a certain time and your
application (mail/calendar) needs to generate a new token. Normally the
user should not notice about that for any session.
Guenter
Andrew Sutherland
* What does Google hope to gain by making this change? Is it an anti-spam/anti-fraud measure?
I've got a long-form response here because these are relevant issues to the Gaia email app that merit documentation, and I'm going to scavenge from this message to provide the documentation / rationale.
## 2 Factor Auth ##
Google wants people to use 2-factor auth (https://www.google.com/intl/en/landing/2step/). IMAP/SMTP-based clients need to continually establish new connections and perform periodic synchronization without direct user interaction. This requires some type of persistent credential.
(Without a persistent credential the user would need to continually enter a new password that is the concatenation of the user's actual password plus a currently valid code received via SMS or a Google Authenticator/TOTP[1] mechanism. I assert this is effectively unworkable in the face of establishing new connections. It also leaks the user's password, thereby reducing overall security.)
Use of single-factor authentication (just a password) that is used by both the user and all their applications is
OAuth2 is one of two ways Google currently uses to provide a persistent credential to applications. The other is "application specific passwords" (https://support.google.com/mail/answer/1173270?hl=en):
### OAuth2 / Account Permissions ###
OAuth2 can be used without enabling 2-factor authentication on an account. It provides a persistent, revocable credential that is explicitly scoped/controlled access to subsets of the user's Google Account. The requested access is described by Google to the user at the time of the request but it's a yes/no situation; the user can't authorize a subset of access to the account.
In my quick test just now, the explanations were presented as high level descriptions of the requested capabilities accompanied by little "i" icons to the right that pop-up more detailed descriptions when you click on them. When authorizing the currently Google Chrome-based whiteout.io app, the Google-hosted dialog I got listed the following requests with the given elaborations.
* View and manage your mail
** View, manage, and permanently delete your mail in Gmail
** Create, update, and delete labels
** Compose and send new email
* Know who you are on Google
** This app is requesting permission to associate you with your public Google profile.
* View your email address
** View the email address associated with your account
Note that since I was already authenticated to Google so I did not need to enter any credentials. And to reiterate, the page was served by Google in Google's origin with frame-busting, although they clearly support a mechanism for plugging in branding in a few spots.
A user interface to list existing authorized applications, their authorizations is accessible from the user's Google account's "Security" tab/page from the "Account Permissions" portion of the page. That portion links to documentation at this page: https://support.google.com/accounts/answer/3466521.
The page list capabilities grouped by Google product and reuses the top-level descriptions from before, but does not provide access to the tool-tips. So the breakdown for whiteout.io is:
* Gmail
** View and manage your mail
* Basic account info
** View your email address
** Know who you are on Google
A revoke button is provided and the date of the original authorization. No additional data/metadata is currently surfaced in the UI.
### Application-Specific Passwords ###
These are unscoped credentials that require that 2-step verification be enabled. The user manually creates an application-specific password from their Google account's "Security" tab/page in the "Password" section under "App passwords". The docs at https://support.google.com/mail/answer/1173270?hl=en do a great job of illustrating how it works, so I'll skip doing that.
These accomplish much of what the OAuth2 provided credentials provide, and it is my understanding that :BenB is okay with these and thinks they may be an acceptable workaround. Their deficiencies are that they:
* Are unscoped, which means that even though you may have created the password for Thunderbird to access your email, if compromised it could potentially be used to download all of your pictures that you uploaded via Picasa.
It's not immediately clear how Google handles these on the back-end. They could be clever and realize you only ever use them for email and then auto-scope them under the hood, or not. They could restrict them to API endpoints, or maybe if you type one into any interactive login prompt as your password it bypasses all 2-factor checks.
The biggest concern is that older versions of Android used application-specific passwords and on an Android tablet I upgraded Android was able to turn the application-specific password into a "Full account access" "Account Permission(s)". It is possible there were additional safe-guards in place like the device providing a sort-of secondary factor to prove it was the device on file.
I should point out that Google does have it in their power to make these credentials scoped. But then there's a new set of problems where the user doesn't set the right permissions for the app / the required permissions change / the user blindly pastes in some opaque set of permissions / etc.
* Bad UX, significantly worse on mobile than on desktop, though it varies on the mobile platform. Basically intractable on Firefox OS because of our lack of copy and paste.
* Makes it harder for Google to react to zero-days on software / web sites. One upside to OAuth2 is that since the application is required to claim to be a specific piece of software/website, Google has the ability to disable credentials on a per-application basis quickly across all their users.
For example, let's say it turns out that there's a buffer overflow attack on Thunderbird that allows an attacker to steal your credentials. Google could invalidate all of the Thunderbird tokens as soon as they find out and refuse to mint any new tokens for software that claims to be that version of Thunderbird. Thunderbird registers for a new secret and pushes out a security update with a fixed Thunderbird and that uses the new credential
Note that there are also downsides to requiring applications to register to get the not-really-secret secret key. It does not scale unless there's an effort to create a community registry of applications that other OAuth2 providers can pull from.
One could also make the argument that it makes it easy for Google to deny access to Thunderbird. But practically speaking, there's nothing stopping Thunderbird (or any client) from lying about what client it is. And also it's fairly easy for Google to fingerprint Thunderbird's IMAP/SMTP behavior if they wanted to systematically prevent Thunderbird from accessing their system.
* Can the additional data about logins that Google hopes to obtain be obtained in other ways for IMAP?
* Google wants your phone number. I just went to create an account from scratch, and while the form asks for a mobile phone number, the documentation linked to from the page at https://support.google.com/accounts/answer/1733224?hl=en says it's optional.
I think Google's rationale here is sound, but I do agree with Ben that Google may potentially do other things with that information that are not as much in the user's interest.
* Google's documentation explicit provides other mechanisms that don't require the mail client to also be a web browser / have a web browser. See https://developers.google.com/accounts/docs/OAuth2#device and the greater details at https://developers.google.com/accounts/docs/OAuth2ForDevices. However this is still OAuth2 and possibly even a somewhat Google-specific. Given that Thunderbird is unlikely to already have google.com credentials embedded inside it via cookie, triggers a different web browser for general web browsing, and the mechanism does now allow data to be passed back, this might be the ideal solution for Thunderbird.
In a broader contest responding to :BenB's answer here, I'll quote myself from https://bugzilla.mozilla.org/show_bug.cgi?id=849540#c20 (and omit a distracting point I retracted in a subsequent comment):
In terms of error messages, gmail actually already does this. They provide a structured specific error code that software can identify, plus they include human-readable text and a link to a support document. Frequently not the world's best support document, but a good starting point.
A big problem with these error messages is that most servers provide useless, unlocalized, confusing error messages so email clients have an incentive to not show the error message directly to the user.
* Why can't single-service passwords continue to be used instead?
* Do they understand the ramifications of the idea that clients of all these protocols will need to contain a browser? (Is that actually so?)
* Are there any ramifications on open source software in particular? (Seems from the discussion that the answer is actually no, but we need to be sure.)
From https://developers.google.com/accounts/docs/OAuth2#installed:
"The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.) "
* Who are the other desktop email software providers, and what are their opinions?
* The whiteout.io client (https://whiteout.io/) already does this, as alluded to above. While under development, they are notable in that you create or import a PGP key as part of the account setup process and the app will try and upsell your unencrypted recipients to adopt PGP. The app is in an early stage and is currently GMail-specific and operates as a Chrome app and unfortunately although you can install the app via the inline install mechanism (versus the chrome app store which does require the browser to be bound to your Google account), actual account setup does require binding to your Google account. Hopefully they change that in the future, but you can at least tell Chrome not to sync stuff with the server and to wrap it with an additional pass-phrase that is not your Google credentials.
Andrew
1: http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
Andrew Sutherland
Use of single-factor authentication (just a password) that is used by both the user and all their applications is
Google has done some really amazing work in terms of detecting compromised accounts/suspicious accounts and dealing with this situation in a way that amounts to fallback 2-factor. But it would be better for everyone if everyone was just using two-factor up front. It avoids problems, it helps detect problems (you know which oauth token leaked and therefore where the security hole might be), it makes it easier to recover from problems (don't need to change your password on all of your devices), etc.
Andrew
Joshua Cranmer 🐧
> * What does Google hope to gain by making this change? Is it an
> anti-spam/anti-fraud measure?
I think Google's goal is to be able to control the entire authentication
process rather than delegating it to the normal protocol authentication
(i.e., SASL) procedures. You might be able to argue that it's merely a
means to other ends, but I get the impression that Google is too fixated
on the OAuth 2 mechanism in particular to fail to ponder how best their
goals, whatever they may be, may be best served in the normal SASL
mechanisms. The more I think about the security implications of OAuth
2-via-SASL, the more I see it as ultimately a weakening of security
guarantees as far as IMAP is concerned.
Looking at OAuth 2 itself, it seems to me like a really, really insecure
variant of Kerberos. I'm guessing the main reason they don't want to
attempt to reuse prior art here is
a) They want to authorize the client in particular instead of the
mechanism of access (which to me is bogus).
b) Using Kerberos may be "too hard" for people (despite having
well-established, cross-platform support for at least a decade).
c) They want to eliminate the ability for the client to
control/intercept authentication (which OAuth 2.0 only appears to do).
> * Can the additional data about logins that Google hopes to obtain be
> obtained in other ways for IMAP?
It probably shouldn't be hard to get most of the same functionality via
Kerberos:
1. KDC servers can already be looked up via DNS SRV records.
2. SASL/GSSAPI already gives a well-defined mapping to look up how to
request a service ticket (e.g., imap/mail.go...@GMAIL.COM).
3. If they want to authenticate client id, they could arguably do this
by having users login not with Pidg...@GMAIL.COM but with
Pidgeot18/Clie...@GMAIL.COM.
4. Acquiring kerberos tickets is typically handled outside of the client
anyways (if you select GSSAPI as the auth option, we don't bother asking
for a password, although there is a bug on us popping up dialogs if the
ticket expired).
> * Do they understand the ramifications of the idea that clients of all
> these protocols will need to contain a browser? (Is that actually so?)
The main ramification to me is not that clients need to contain a
browser but that they need to encode gmail-specific logic with little
pretense of genericity. Note that the "contain a browser" portion of it
automatically implies in great detail that clients have complete control
over the authentication/authorization process anyways, one of the
reasons I think the security gains are rather illusory.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Magnus Melin
On 28.04.2014 18:16, Ben Bucksch wrote:
>> * Are there any ramifications on open source software in particular?
>
> incompatible with client software, and open source all the more. OAuth
> is designed for websites, where the server can easily keep secrets.
Being able to easily support flows where the clients that can't keep a
secret was one of the motivations for OAuth 2.0.
-Magnus
Ben Bucksch
> Lightning hides that process from the user.
> That access key will be used to generate a token to work with your
> mail/calendar. That token will expire after a certain time and your
> application (mail/calendar) needs to generate a new token. Normally
> the user should not notice about that for any session.
and then never again - can be handled differently than something that
can up at any random time.
How does that process work? All readable documentation I found about
OAuth speaks about webpages. That is: not HTTP URLs, but random HTML
served by Google, containing arbitrary challenges to the end user (e.g.
enter phone number, Google sending a code there, enter that code) that
only the allowed human can fulfill.
If tokens can expire and be refreshed by Lightning without (!) user
interaction, I don't know how that would work. Can you expand, please?
Patrick Cloke
If tokens can expire and be refreshed by Lightning without (!) user interaction, I don't know how that would work. Can you expand, please?
Ben Bucksch
Yup. That's the token expiry. "A few weeks" is a common expiry time for
"long" sessions.
This is exactly the kind of interaction that I find user-hostile and I
do not want to be standard experience for reading email.
It requires the app to have a web browser ready at *any moment*, which
cements the dependency. It totally destroys non-interactive processes -
worse: they silently break after a long time, after (!) you tested them
and assume they work.
Even more so if answering the auth window might involve getting my
mobile phone. Which I often do not have available at all when I work. I
can't do that even to make a bank transfer of thousands of dollars, much
less just to read email.
In theoretical terms, these are 2 "media breaks": Email app to web
browser, and web browser to physical phone. Since we introduced
computers, I've always been fighting media breaks, usually between paper
and computer.
Ben
Joshua Cranmer 🐧
> nea...@gmx.de wrote, On 28.04.2014 20:10:
>> Lightning hides that process from the user.
>> That access key will be used to generate a token to work with your
>> mail/calendar. That token will expire after a certain time and your
>> application (mail/calendar) needs to generate a new token. Normally
>> the user should not notice about that for any session.
>
> Expiry indeed is a core problem. One-time setup - if it's really once
> and then never again - can be handled differently than something that
> can up at any random time.
>
> How does that process work? All readable documentation I found about
> OAuth speaks about webpages. That is: not HTTP URLs, but random HTML
> served by Google, containing arbitrary challenges to the end user
> (e.g. enter phone number, Google sending a code there, enter that
> code) that only the allowed human can fulfill.
Google's OAuth documentation is extremely heavily geared to web
applications. It's confusing even when you know what you're looking for. :-(
>
> If tokens can expire and be refreshed by Lightning without (!) user
> interaction, I don't know how that would work. Can you expand, please?
The authorization procedure looks like this:
1. Client makes authorization request to Google.
2. Google does authentication using its own UI and pages.
3. Google sends client an authorization code.
4. Client uses authorization code to gain an access token and refresh token.
5. Client sends access token to actually get access [this is the only
part that actually goes over IMAP].
6. Access tokens expire after a "short" amount of time (hours?)
7. A client can obtain a new access token with its refresh token. This
is meant to be saved in long-term storage.
There's this gem of a note:
"Note that there are limits on the number of refresh tokens that will be
issued... You should save refresh tokens in long-term storage and
continue to use them as long as they remain valid. If your application
requests too many refresh tokens, it may run into these limits, in which
case older refresh tokens will stop working."
[which, incidentally, turns out to contradict earlier statements on that
page about refresh tokens. Google's OAuth documentation is less than
stellar.]
It's implied that refresh tokens both don't expire and will expire over
a "long" period of time, but the documentation is really vague on this
matter.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Ben Bucksch
> these are 2 "media breaks": Email app to web browser, and web browser
> to physical phone. Since we introduced computers, I've always been
> fighting media breaks, usually between paper and computer.
and bureaucracy happy. It should be the other way around. When you
eliminate them, usually huge productivity gains ensue. When you add
them, pain ensues. E.g. when I don't have my phone, but need to read
mail urgently.)
Ben Bucksch
> It's implied that refresh tokens both don't expire and will expire
> over a "long" period of time, but the documentation is really vague on
> this matter.
As Patrick said, the refresh token probably expires after weeks.
Even if it doesn't, Google may kill it for other reasons, e.g. you
changing IP addresses.
This, an app needs to be prepared to refresh (re-gain) the refresh token
and start from scratch at any time.
And yes, Google is *intentionally* vague. That's policy: They want to be
in full control.
That means we'd need to handle 4 different tokens: Auth token, refresh
token, access token. Plus the password that the user enters towards Google.
Any of them can suddenly go invalid at any time for any reason. If
you've ever implemented something like that, it's gruesome. Esp. given
that you need to be able to go back to UI at any time, and the
documentation and error codes are intentionally vague, it's hard to make
a proper design. Often, you can't even distinguish between expiry and
auth failure, due to collation of error codes, so it's hard to know what
to do, and you risk doing loops.
(And given that we display the browser and have control over it, we can
get the password, making the whole thing moot, as you pointed out. For
that exact reason, for me, token-based auth mechs are all security theater.)
Ben
nea...@gmx.de
> nea...@gmx.de wrote, On 28.04.2014 20:10:
>> Lightning hides that process from the user.
>> That access key will be used to generate a token to work with your
>> mail/calendar. That token will expire after a certain time and your
>> application (mail/calendar) needs to generate a new token. Normally
>> the user should not notice about that for any session.
>
> Expiry indeed is a core problem. One-time setup - if it's really once
> and then never again - can be handled differently than something that
> can up at any random time.
>
> How does that process work? All readable documentation I found about
> OAuth speaks about webpages. That is: not HTTP URLs, but random HTML
> served by Google, containing arbitrary challenges to the end user
> (e.g. enter phone number, Google sending a code there, enter that
> code) that only the allowed human can fulfill.
>
> If tokens can expire and be refreshed by Lightning without (!) user
> interaction, I don't know how that would work. Can you expand, please?
>
Calendar usage:
> http://www.reminderfox.org/remote-calendar-n/#accountgooglev2
Our implementation briefly described:
-- selecting GCal OAuth2 as the authorization methode for the Gcal (yes,
the old method also works!), you enter your Goodle account name (or
select it from dropdown) and request access .. which sends the
Reminderfox secret deatils
-- Google answers on a web page to indicate an application (Reminderfox)
asks for access. The user has to acknowledge it and gets back a code.
That has to be copied and the user switch back to Reminderfox to [Paste]
it into our extension dialog. That action -- in the background gets the
access and the refresh code which are stored to the PW manager -- and
finally offers the available calendar for that user.
-- after selecting the right calendar you can go with it.
-- normally if the token/access code expires we refresh it
transparently, so no user action is required.
-- in rare case that process fails, but Reminderfox offers a [Refresh
the token]. That's an action **without** using a separate web page, just
normal http calls.
Note: the process is the same for Thunderbird/Seamonkey and Firefox
Lightning does that first process to get the very first access and
refresh code a bit more elegant. I think Philipp (Fallen) could give a
more detailed description here.
Guenter
Philipp Kewisch
On 29.04.2014 18:17, Ben Bucksch wrote:
nea...@gmx.de wrote, On 28.04.2014 20:10:
Lightning hides that process from the user.
That access key will be used to generate a token to work with your mail/calendar. That token will expire after a certain time and your application (mail/calendar) needs to generate a new token. Normally the user should not notice about that for any session.
Expiry indeed is a core problem. One-time setup - if it's really once and then never again - can be handled differently than something that can up at any random time.
How does that process work? All readable documentation I found about OAuth speaks about webpages. That is: not HTTP URLs, but random HTML served by Google, containing arbitrary challenges to the end user (e.g. enter phone number, Google sending a code there, enter that code) that only the allowed human can fulfill.
If tokens can expire and be refreshed by Lightning without (!) user interaction, I don't know how that would work. Can you expand, please?
[...]
Lightning does that first process to get the very first access and refresh code a bit more elegant. I think Philipp (Fallen) could give a more detailed description here.
I think some things have changed, reading the docs there is now also an token info service that must be called. We don't do this. Anyway, most of the process we do can be found in <http://mxr.mozilla.org/comm-central/source/calendar/base/modules/OAuth2.jsm>. First we get an authorization token, then we can request an access token. The access token expires in given time (as stated in the response). When the access token has expired, we can refresh it using the authorization token without any user interaction. The user must only enter data when getting the authorization token.
More information on the general process is here: <https://developers.google.com/accounts/docs/OAuth2>. Here is info specifically on how it works for client applications <https://developers.google.com/accounts/docs/OAuth2UserAgent>. Note that some data needs to be pushed to the source repository. Please make sure it is properly obfuscated, as seen here <http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js#2855> and add a similar comment.
Philipp
Joshua Cranmer 🐧
> http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html
>
> Is this relevant to Thunderbird accessing Gmail?
This was brought up in the status meeting, and we resolved to reach out
to Gmail to clarify some questions. Here's the status of as right now:
1. The clarification from GMail IMAP folks is:
> The bottom line is that GMail would really like Thunderbird to use
> OAuth2 for imap/smtp/pop access. If it doesn't, there's an increased
> possibility that GMail will suspect the login attempt is unauthorized.
> If you keep using the same IP address, or have two factor auth turned
> on, you'll most likely be OK. Otherwise, the users run the risk of
> having to jump through some hoops to get imap access again (I don't
> know the exact details of that...)
2. I've made a post to the IMAP-protocol list about this topic (it felt
more relevant there than the Kitten working group):
<http://mailman13.u.washington.edu/pipermail/imap-protocol/2014-April/002243.html>.
From responses in the past 12 hours, it does seem like there is
agreement by client implementers that some of these issues need to be
resolved.
3. I've been told by both Bienvenu and Brandon that the OAuth people
have been brought into the discussion, although they haven't responded
publicly yet.
It looks to me that it will be possible to see many of the concerns I
have about OAuth discussed and addressed.
As a side note, it also looks like other IMAP servers are planning on
supporting OAuth 2.0. Outlook.com recently rolled out support for it as
well, and I think there was another server the name of which I don't
recall right now.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Onno Ekker
Ludovic Hirlimann
> http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/
>
if it's fixable then it won't be an issue. if it ain't then google will
probably back out.
--
[:Usul] MOC Team at Mozilla
QA Lead fof Thunderbird
http://sietch-tabr.tumblr.com/ - http://weusepgp.info/
Andrew Sutherland
> http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/
implementation of OAuth2 unless the OAuth providers decide to
aggressively mitigate this threat model, in which case it may hurt
Thunderbird's use case. The risk model for Thunderbird's account setup
would continue to be vulnerabilities in the autoconfig process allowing
an attacker to interpose themself as a persistent or transient
man-in-the-middle server.
The documentation available on the actual attack at
http://tetraph.com/covert_redirect/ is extremely limited given the
effort to build the website and post the same information multiple times
to different blogging networks, etc. But based on what is there, it
sounds like the attack is one of the familiar cases of making a
nefarious link look legitimate by using redirecting/link shortening
services hosted by a domain the user trusts. There may then be
secondary risks based on how much effort the OAuth provider put into
validating the application registrations. Since the authorization
screen will display this data and be hosted on (and look like it's
hosted on) the OAuth provider's website, it may cause the user to
believe the information is more trustworthy than it actually is. "Oh,
that first link looked sketchy, but now this looks okay, so I guess it's
okay after all."
The potential for the attacker to effectively never be showing their
origin in the process does contribute to the problem. The only
persistent UI that needs to exist is the OAuth provider's authorization
page. The attacker's server can just poll the server in the
background. Unfortunately the many possible OAuth flows where the
application can't keep a secret (ex: Thunderbird) and doesn't live as a
webpage in the user's browser means it's effectively impossible to
completely prevent the user from doing something dangerous under the
auspices of the client.
Total mitigation of this type of risk really depends on the user,
specifically:
- Be aware of what they're clicking on (sketchy / obfuscated link?), and
where they're clicking on it (sketchy website?).
- Be aware of the context of the request too. You are unlikely to
randomly need to reauthorize Thunderbird.
But existing apps can also help with this:
- Popup blocking logic may be helpful.
- Browsers could detect suspicious redirects. Unfortunately, the
ubiquity of link shorteners for good and bad reasons can complicate this.
- Browsers already have safe browsing mechanisms.
- Mail clients can integrate similar mechanisms, although there is the
problem of piercing shortened links leaking information that an email
has been either displayed or received.
- Help the user by establishing reasonable standards for safety. When
using OAuth2 in cases where it might be conducive to pop-up the
authorization in the user's web browser (ex: for Thunderbird), make sure
to first use chrome in Thunderbird to say: "Hey, we need to
re-authorize. Click [No, be broken for now] or [Yes, let's reauthorize
in the browser]".
Andrew
Joshua Cranmer 🐧
1. The OAuth working group is currently producing a document on dynamic
client registration. This satisfies one of my two principle concerns.
Reading up on ancillary information, Thunderbird was explicitly
mentioned as a use case. I've read the current draft, and my thoughts
are best summarized as:
* We may need to provision a public/private key pair for Thunderbird. I
don't know how secret this would need to be, but since a key pair is all
that's needed, it's a relatively simple matter to generate one locally
for developers. Perhaps even automatically ^_^
** [Note: keys here are JWT keys, if that means anything to anybody else.]
* There may be some slight issues with localization. There's provisions
for displaying localized strings, but it's not quite clear to me what
the recommended best practice is. Worst case scenario may require us to
carry several localizations at once.
* We'll get a client id and a client secret. May be useful for other
OAuth 2.0 uses in our tree.
* Yet another endpoint
I don't see any major issues, but I'll read it more thoroughly when a
last call is put out.
2. There was some discussion of the issues at the Internet Identity
Workshop, which apparently happened basically the week after this thread
started. This gives a little bit of background context on some of the
design choices, and Thunderbird is explicitly mentioned as the IMAP/SASL
dynamic client registration use case. \o/
3. Endpoint discovery is mentioned several times as a concern... and
mentioned several times as a deferral. I'm concerned that the kitten
[SASL] and OAuth working groups aren't necessarily talking to each
other, because there's an off-hand comment by someone that perhaps SASL
could elucidate the endpoint information, yet the OAuth SASL spec is in
last call and explicitly disclaims responsibility for endpoint notification.
I don't follow the working groups myself, but I've binged on their
archives for relevant details.
So, what should we be doing?
1. This has been discussed in another circumstance, but moving the OAuth
2.0 to shared code or toolkit is probably a good first step.
2. We ought to tweak our SASL code to not assume that SASL is
synchronous. This might also be an excellent time to attempt to
consolidate the SASL code into a better framework than DoGSSAPIStep1,
DoGSSAPIStep2, etc.
3. OAuth 2.0 as a SASL backend is almost certainly going to be in JS.
IMAP protocols are off-main-thread, and hence are forbidden from direct
JS access. We need to make sure that we do a main-thread-proxy here for
IMAP.
I'm guessing that usable endpoint discovery won't roll out for 6-9
months, which means we may need to temporarily hardcode the endpoint
locations for, say, gmail. :-( OTOH, it also depends on how quickly
Google or other providers roll out implementations of the current
standardized variants.
Dave Koelmeyer
Just looking at the Gmail account warning in this help doc:
My understanding was that by enabling the less secure apps setting for the Gmail account in question Thunderbird would continue to function with Gmail in the same way it always has. I created a free Gmail account myself a week or two ago, and by making this setting I can connect using Thunderbird fine. I also noted information from a Google developer on the matter at http://mailman13.u.washington.edu/pipermail/imap-protocol/2014-September/002326.html.
Is stating that it won't work at all until April 2015 not really accurate?
Cheers,
Dave
-- Dave Koelmeyer http://blog.davekoelmeyer.co.nz
Dave Koelmeyer
Just looking at the Gmail account warning in this help doc:
My understanding was that by enabling the less secure apps setting for the Gmail account in question Thunderbird would continue to function with Gmail in the same way it always has. I created a free Gmail account myself a week or two ago, and by making this setting I can connect using Thunderbird fine. I also noted information from a Google developer on the matter at http://mailman13.u.washington.edu/pipermail/imap-protocol/2014-September/002326.html.
Is stating that it won't work at all until April 2015 not really accurate?
Cheers,
Dave
Dave Koelmeyer
Benjamin Kerensa
The article can probably be updated to reflect users will need to toggle this on. Google did not have a lot of information earlier on I think when this article was created.
I think many will assume it just doesn't work unless they happen to stumble across the setting.