API for B2G apps to clear their own cookie jar?

[Andrew Sutherland]

== Context:

The email app is implementing OAuth2 support for GMail. We do this just
like the communications apps by using window.open(authEndpoint, '',
'dialog') combined with manifest redirects support
(https://developer.mozilla.org/en-US/Apps/Build/Manifest#redirects) to
transfer control to a page inside our app that can do
window.opener.postMessage() with the fruits of the auth process when done.

A byproduct of this is that the user probably ends up with Google
credentials stuck in our app's cookie jar. User privacy expectations
dictate that if the user removes the account then they absolutely don't
expect that if they go to re-add the account that they won't have to
authenticate. :jrburke has worked around this by noticing that Google
still supports max_auth_age as a holdover from OpenID 2.0's PAPE
(http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html)
that allows us to compel the user to re-authenticate. However Google
suggests this is not really a supported avenue:
https://groups.google.com/d/msg/google-federated-login-api/lKxJf4cZEcY/00ulwERl04YJ

We do feel the work-around is sufficient for our purposes right now
because with the workaround an attacker would need to alter the code of
the email or access the cookies at a low level to make use of them.
But I'm definitely open to other concerns.

Note that we expect that the use case of "the user is getting rid of
their phone and wants to wipe it" will involve a factory/user-data reset
that will reliably clear all of the email app's state. We think that
mechanism is already sufficient for that use-case.

== Request:

It would be good if the email app could force itself to forget all of
the cookies in its cookie jar when removing an account. Because it's
possible that the authorization endpoint might bounce around and do
complicated things involving domains/origins we don't know.

I would expect that we'd do something like mozApps.getSelf() =>
selfApp.clearCookies();

https://developer.mozilla.org/en-US/docs/Web/API/Apps.getSelf
https://developer.mozilla.org/en-US/docs/Web/API/App

== Prior Art:

The current mechanism in place for resetting data appears to be a
nuke-everything system using observer notifications:
http://dxr.mozilla.org/mozilla-central/source/dom/apps/Webapps.jsm#4276

== Wow, so many cookies:
After setting up a single GMail account using OAuth2 without using
2-factor auth, the following cookies ended up in the email app's cookie
jar on FxOS v2.1. Introspection using sqlite3 knowing the appid:
sqlite> select baseDomain, name, expiry from moz_cookies where appId = 1067;
youtube.com|CheckConnectionTempCookie100|1410313049 (~6 months out)
google.com|NID|1426124249 (~2 years out)
google.com|SID|1473385049
google.com|HSID|1473385049
google.com|SSID|1473385049
google.com|APISID|1473385049
google.com|SAPISID|1473385049
google.com|ACCOUNT_CHOOSER|1473385049
youtube.com|SID|1473385049
youtube.com|HSID|1473385049
youtube.com|SSID|1473385049
youtube.com|APISID|1473385049
youtube.com|SAPISID|1473385049
google.com|LSOSID|1473385050
google.com|GAPS|1473385054
google.com|LSID|1473385054
doubleclick.net|_drt_|1410399455
doubleclick.net|test_cookie|1410313955

Andrew

[Frederik Braun]

I wonder what this should mean for other storages (IndexedDB,
local/sessionStorage) and settings (geolocation/gUM, popup, fullscreen)?

[Frederik Braun]

[Jeffrey Yasskin]

2¢: You don't really want to have packaged apps showing users a
password prompt for another service. It's a phishing risk, although
maybe your manual review process can catch that, and it's annoying for
users to have to re-type their google password every time an app wants
access to a google OAuth scope. The chrome.identity API isn't perfect,
but it uses a dedicated cookie jar for service logins, and then
transfers the OAuth token out using something like your redirects
support. Ideally, the identity API would use the same cookie jar as
the main browser (or OS), so that if users are logged into the service
anywhere, they don't have to re-type a password for any app. Both
solutions naturally solve the problem of accumulating google cookies
in an app cookie jar, since they make sure the app can never see the
sensitive cookies in the first place.

Sorry for intruding if the above was all obvious or has obvious problems.
Jeffrey

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Ehsan Akhgari]

How would the app know which cookies to remove, though? The solution of
nuking all cookies doesn't seem ideal, since the app may have other
cookies used for other purposes that it doesn't want to get rid of (that
may not be an issue for the email app, but it will be an issue for an
API callable by arbitrary apps.)

We currently have plans to implement support for app scopes so that URLs
of a specific prefix can be opened within their own app. It seems to me
that having a Google Account app that uses app scopes to handle all
Google OAuth requests and has its own separate cookie jar is a much
cleaner solution to this problem, and it will also address the issues
that Jeffrey mentioned.

[Andrew Sutherland]

On 09/10/2014 01:52 PM, Ehsan Akhgari wrote:
> How would the app know which cookies to remove, though? The solution
> of nuking all cookies doesn't seem ideal, since the app may have other
> cookies used for other purposes that it doesn't want to get rid of
> (that may not be an issue for the email app, but it will be an issue
> for an API callable by arbitrary apps.)

It's definitely a hack. But unless app scopes completely moot the issue
of app cookie jars, it seems like apps should have some ability to clean
that data out that otherwise accumulates until they're uninstalled. I
agree that since it's impossible to know what domains have gotten data,
it really needs to be the nuclear option that blows away all the
cookies, or at least those outside the origin described by the manifest.

An example use-case for this would be me lending my phone to someone.
They login to an account on some app, then remove their account.
Neither of us want any of their data in my phone. I know enough that I
could remove the app and reinstall it to make the data go away. While
some people might then uninstall the app because they don't want it, I
doubt many people would make the connection that they have to uninstall
the app to get rid of the private data pieces.

Perhaps instead the app should be able to trigger a clean reinstall of
itself. so mozApps.getSelf() => requestCleanReinstall(). The app would
be able to say, "hey, since you removed this account, I'd really like to
make sure all the data is gone. Is it okay to reset myself back to
defaults?" This could also be handled by a web activity as long as it's
guarded so nefarious apps can't interfere.

> It seems to me that having a Google Account app that uses app scopes
> to handle all Google OAuth requests and has its own separate cookie
> jar is a much cleaner solution to this problem, and it will also
> address the issues that Jeffrey mentioned.

Replace Google Account app with something that doesn't require every
mail server provider trying to use OAuth2 to create their own Firefox OS
app, and yes, that sounds right. For the record/(my ego :) I did think
of this one too, but since this is a FxOS v2.1-related fire-drill that
involves new l10n strings and precludes creation of entire new apps,
IMAP-OAuth2 cannot currently be generically used until discovery
(https://mail.mozilla.org/pipermail/tb-planning/2014-April/003245.html)
and dynamic registration
(http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20) are addressed,
and we would not want to use web activities that can be intercepted by
nefarious apps, this corner was definitely cut. Although I agree we
shouldn't be doing this in general, I think it raised an interesting
question about management of the data "owned" by the app in its cookie
jar but not actually owned enough to be able to manage it at all.

The chrome.identity API that Jeffrey mentioned, at least the
non-Google-specific stuff, seems like it could be a good basis for a
standardized approach to this flow:
https://developer.chrome.com/apps/app_identity#non
https://developer.chrome.com/apps/identity#method-launchWebAuthFlow

Andrew

[Andrew Sutherland]

On 09/10/2014 01:42 PM, Jeffrey Yasskin wrote:
> 2¢: You don't really want to have packaged apps showing users a
> password prompt for another service. It's a phishing risk, although
> maybe your manual review process can catch that, and it's annoying for
> users to have to re-type their google password every time an app wants
> access to a google OAuth scope.

Yeah, the phishing risk is a real concern. I'm going to go post to
dev-gaia about window.open(url, whatever, 'dialog')'s failure to let the
user see what origin they are dealing with.

And I agree reusing the credentials would be ideal. Unfortunately in
order to get the installed app or web app flows to work we needed
redirect magic that requires us to stay in our app-space by using
window.open. We did consider using the OAuth 2.0 for devices flow
(https://developers.google.com/accounts/docs/OAuth2ForDevices) that
would have let us use the main/system cookie stash, but that wouldn't
have let us return to our app at the completion of the flow and may also
have required the user to do the manual code entry (didn't see if we
could skip that by specifying it in the GET), so we bailed on that.

> Sorry for intruding if the above was all obvious or has obvious problems.

Not an intrusion at all! It's absolutely appropriate to revisit the
root issue in cases like this, which is also why I tried to provide
sufficient context so that people could do so. And the
"chrome.identity" API was a great pointer and I agree that I think in
general it is the right(tm) solution. Thank you!

And especially it's great if there are non-Mozilla developers[1] hanging
out on this list who can provide greater perspective/context/etc.
earlier in the process. A real danger of the dev-webapi list is that we
treat this as the great big ocean of Web APIs and standards when it's
not; it's a little harbor to publicly bounce questions and ideas around
before setting sail to the great working group lists of the world where
the standards stuff is actually happening.

Thanks!
Andrew

1: I'm inferring from your chromium.org mail address; could be wrong!

[Jonas Sicking]

On Tue, Sep 9, 2014 at 6:54 PM, Andrew Sutherland
<asuth...@asutherland.org> wrote:

> It would be good if the email app could force itself to forget all of the
> cookies in its cookie jar when removing an account. Because it's possible
> that the authorization endpoint might bounce around and do complicated
> things involving domains/origins we don't know.

Could you open Google in a <iframe mozbrowser>? That way you both get
the ability to control the UI, and you also get the ability to clear
the "browser cookie jar" for the email app.

Each app has two cookie jars. One for the app itself, and one for any
"browser content" that it opens using the <iframe mozbrowser> API. The
browser cookie jar can be cleared using the
getSelf().clearBrowserData() API.

/ Jonas

[Andrew Sutherland]

On 09/16/2014 08:08 PM, Jonas Sicking wrote:
> Could you open Google in a <iframe mozbrowser>? That way you both get
> the ability to control the UI, and you also get the ability to clear
> the "browser cookie jar" for the email app.

Aha! Yes, I think we can do this. Even if we lose the manifest
"redirect" magic, we can use the mozbrowser events to monitor the title
change with a redirect of "urn:ietf:wg:oauth:2.0:oob:auto " (per
https://developers.google.com/accounts/docs/OAuth2InstalledApp). And our
docs suggest we can still have mozbrowser as privileged instead of
certified, so as long as there are no gotchas there, we should ideally
be okay.

I think my biggest concern with this approach is that I think we need to
provide our own UI which inherently precludes leaving it up to the
system app to provide browser chrome and related informed task-switcher
UI. As I noted in dev-gaia and was raised here, it's unfortunate to
have our built-in apps training users to trust spoofable UIs. However,
it seems like https://bugzil.la/1066477 is not actually going to address
the spoofable nature of window.open(url, '', 'dialog') anyways...

Also, (rationalizing the extra privilege) email will probably need to
adopt use of mozbrowser at some point soon in order to get true-APZ with
HTML emails instead of our current manual transform: scale() approach.

Thanks much!
Andrew

[Fernando Jiménez Moreno]

On 10/09/2014, at 21:11, Andrew Sutherland <asuth...@asutherland.org> wrote:
> The chrome.identity API that Jeffrey mentioned, at least the non-Google-specific stuff, seems like it could be a good basis for a standardized approach to this flow:
> https://developer.chrome.com/apps/app_identity#non
> https://developer.chrome.com/apps/identity#method-launchWebAuthFlow

FWIW we are already working on this approach at https://bugzilla.mozilla.org/show_bug.cgi?id=1062001