glevin@ for privacy assessment.

afakhry@, do you have any additional docs, beyond the long email thread from last month?  Any updates?  Or you can just grab me for a chat any time (give me a little advanced warning, so I can reread the email and get back up to speed).

There are no updates other than that email thread. Sure, let's chat in person whenever you're available.

Feel free to add me to the chat as well if it's not too convenient for the two of you

We will send the GAIA ID as it never changes. The GAIA cookie and the OAuth token can change for the same user.

This is fine from a privacy perspective.  Further, I chatted with others on the privacy team, and we agree that it's fine to include all multi-signed in Chrome OS users in the feedback email picker, if you want to include that feature.

Thanks, Greg! +weifangsun@ who was considering to add the ability to include all signed in users in the FB email drop-down.

Any update on this, Ahmed? 

Hopefully I can get to it next week.

yyushkina, is sending GAIA ID sufficient?

mgarisson - this is actually a question for the Feedback team. Is sending GAIA ID sufficient or do you need Chrome to send the GAIA cookie and/or OAuth token?

+sling for his take

We'd like to get the cookie/token to our server so we can determine who the user is server-side like we do for all of our other flows.  Is that feasible? 

I don't know yet, I need to take a look at the code, I'm not familiar with authentication stuff. But I was told that the GAIA cookie and the OAuth token can change for the same user, which is why I'm asking why we need something that can change. I was also told that there are many GAIA cookies, which cookie is the one referred to here?

Re: #14

> We'd like to get the cookie/token to our server so we can determine who the user is server-side like we do for all of our other flows.

Why isn't Gaia ID sufficient for that?

Diminished trust about the identity of the user submitting feedback if we can't verify it on our server.  If that's the only thing possible, then we'd have to check with security/privacy to make sure that we can use the unverified gaia ID / email address to contact the user based on the feedback they send.

Re #15 - Would you get the cookie based on the user signed into the Chrome browser?  Is that available to you?  I don't know a ton about Gaia cookies but it would be the set of cookies that are generally made available to the browser after the user logs in.  We use Apps Framework's libraries to figure out who the user is (both for OAuth and Gaia).  I'd reach out to the Gaia team for more info.  

Note that the server side needs to be updated as well, because Chrome's submit endpoint doesn't care if the user is signed in.  This should be a straightforward change.

I'm also not familiar with GAIA and I'm not sure what would be the best thing to send with feedback reports to enable you to achieve your goal.

Adding msarda@, and rogerta@ from GAIA.

Agree with comment #17 about diminished trust.  The feedback form already has a drop down with email address, and sending the gaiaid does not help to authenticate.  I'm assuming that when the original bug report says "authenticate the user" it mean that in the strict sense.

This is a programmatic api so oauth tokens are better suited than cookies.   I can think of two options:

1/ send a signed JWT for the user
2/ send a "https://www.googleapis.com/auth/userinfo.profile"-scoped oauth access token

The latter can be easily retrieved from the chrome oauth2 token service:

   https://cs.chromium.org/chromium/src/google_apis/gaia/oauth2_token_service.h?l=158

Is the feedback sent to google over https?

Thanks. I will investigate option 2.

Yes, I believe it's over https: https://cs.chromium.org/chromium/src/components/feedback/feedback_uploader.cc?type=cs&q=%22%22https://www.google.com/tools/feedback/chrome/__submit%22;%22&l=19

+jamescook@

I noticed you added this API: https://cs.chromium.org/chromium/src/extensions/shell/common/api/identity.idl?type=cs&q=getAuthToken+f:.*%5C.idl&l=27

Is that something that we can use here in the Feedback app?

That API only exists in app_shell, not in chrome. It was a stub I added a long time ago while working on the cancelled Envoy/app_shell project. I added it because the real identity API was too complex to refactor out of //chrome (since app_shell can't use code in //chrome) and Envoy/app_shell had relatively simple needs. This impl might have also skipped user prompting, since the user would have already granted permissions during Envoy setup.

I'm not sure where you're running the feedback app here. If you are in chrome you should use the real chrome identity API.

https://cs.chromium.org/chromium/src/chrome/common/extensions/api/identity.idl

Thanks James! It seems that we can use the chrome identity APIs, but it requires that the app manifest be updated with a "client_id": https://developer.chrome.com/apps/app_identity#update_manifest.

What would that be in our case?

I'm not sure what your client_id would be, sorry.

I see references to client ids in other manifest files for chrome apps, but I don't know if that's per-app or per-project or what.

https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/genius_app/manifest.json?type=cs&q=f:json+client_id&sq=package:chromium&l=44

You might need to talk to someone more familiar with identity. I barely understood how oauth tokens worked when I touched that code, and I've since forgotten. :-(

afakhry@: are you writing a chrome app or just C++ code in chrome?  If the latter, you don't need a client id.  Use the method I linked to above.  The code flow would be something like:

1/ get a pointer to the token service:

  Profile* profile = ...
  ProfileOAuth2TokenService* token_service =
      ProfileOAuth2TokenServiceFactory::GetForProfile(profile);

2/ get account id of signed in user:

  SigninManagerBase* signin_manager =
      SigninManagerFactory::GetForProfile(profile);
  std::string account_id = signin_manager->GetAuthenticatedAccountId();

3/ request an access token:

  OAuth2TokenService::ScopeSet scopes;
  OAuth2TokenService::Consumer* consumer = ...you need to implement this...
  scopes.insert("https://www.googleapis.com/auth/userinfo.profile");
  token_service->StartRequest(account_id, scopes, consumer);

Thank you for the detailed explanation. I can do it in either js or C++, but seems C++ is easier that way then.

For the scopes part, sling told me that the server accepts only API_SUPPORTCONTENT: https://cs.corp.google.com/piper///depot/google3/java/com/google/userfeedback/receiver/gaia/ReceiverGaiaModule.java?rcl=163780185&l=72.
Is it something I add instead of "https://www.googleapis.com/auth/userinfo.profile", or along with it?

You can add multiple scopes as needed.  For example, if you want to also validate the email address you'll need to add "https://www.googleapis.com/auth/userinfo.email".

I was suggesting the "userinfo.profile" scope because the server could then fetch "https://www.googleapis.com/userinfo/v2/me" to validate the user.  From the code you linked to, seems that the server only accepts API_SUPPORTCONTENT?  If so, my suggestion won't work unless the server side changes too.  I guess you should ask the server folks what scope(s) they want on the incoming requests to help validate the user, and then make sure to request those scopes from the token service.

+dgupta@ for the server expected scopes

- Question for the GAIA folks:

I found an example where the OAuth token is added to the URL request as a header with the format "Authorization: Bearer <token>". [1]

Is this the canonical way of sending the OAuth token with the request?

[1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/upload_job_impl.cc?type=cs&q=UploadJobImpl::CreateAndStartURLFetcher&l=313-314

- Question for the privacy folks:

Please let us know whether or not it is OK to send the OAuth token inside the feedback data (similar to how we send the email address). This is very important as the implementation will vary greatly. The problem is that feedback reports are uploaded at a later time than the time they are created. By that time, all we have is a file on disk containing the report data. The report can get sent much later than the time it was generated due to server or network errors. By the time the report is actually being sent, it could be that a different user profile is signed in, so we need to account for that edge case. Whereas if we can just stick the OAuth token inside the report data, we can do so at the time of the report generation. If not, then we'd have to send it with the request at the time of the upload similar to above.

Fly-by question: Do you need to authenticate the user or simply record the identity? if the latter (say, because you trust the mechanism used to report) you could probably get the user's email instead of an OAuth token which would limit damage in case of exposure/leak.

We need to record the identity (gaia ID, email address where available).  However, we also need to trust that identity as Feedback also supports the ability to contact the user that submitted the feedback.  It would be bad if some malicious user sends an identity like someexec@google.com and we start sending comms to that email address about their feedback.  To get that trust, we need to authenticate the user at submit time.  We are not interested in recording the OAuth token.  We just need to record the gaia user ID and email address it translates to.

Re #31: sling, thanks for answering! We recently changed the feedback app that it's no longer possible to insert some random emails. But yes, a real malicious user may find a way to overcome this limitation.

I suggested an oauth token for the reason sling@ mentions in comment #31.  Only someone who has properly authenticated with gaia can mint a valid oauth token for their account.  The server can then use it to fetch the email address and/or gaia id, so neither needs to be passed in directly with the feedback.  sling@: does that work for you?

Note that the oauth token is kind of a shortcut.  The better way to do this would be generate a signed JWT on the client and sending that to the server.

As long as we get the feedback report and the oauth token in the request to our servers so we can translate it to the user, we should be fine.  The token shouldn't be a field in the feedback report.  I believe OAuth tokens are sent in the request header and there are standard libraries in Apps Framework that does the auth for us.

I'm not familiar with what "signed JWT" and if that's another way to do it, we'd have to figure out how to support that on our servers.

sling, Is there a way to authenticate the user with the feedback server and generate some kind of ID that is recognizable by the server that we can stick in the feedback report?

This will simplify the logic a lot, since as I mentioned earlier, the feedback report might get sent at a much later time than the time it was generated, which by then the currently logged in user might have changed.

Though to be fair, feedback reports are "usually" sent later only because there is no network at the time. In which case, we won't be able to authenticate either :)

This will cover the cases where we have enough network bandwidth and speed to authenticate but not enough to send the full report with the logs.

afakhry@ - cros-pdd currently says,

"The feedback (open text description of the issue) also includes optionally:
[...] Email address of the signed in user [...]"

Could you be sure to add a suggested edit to go/cros-pdd to include any new info that ends up being sent here?  Thanks.

Also, after our chat yesterday, I was unclear if you had any outstanding privacy questions.  If any come up, you can ping the chrome os privacy team while I'm out.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ff0cdb15ac019795ce27d433542407b50a9a439

commit 7ff0cdb15ac019795ce27d433542407b50a9a439
Author: Ahmed Fakhry <afakhry@google.com>
Date: Tue Aug 22 20:11:45 2017

Send OAuth token with Feedback report

Add the authentication header to the feedback report upload request
to help validate the identity of the user. Make sure only one report
is sent at a time.

BUG= 724676 

Change-Id: I3adccc07d93e34ed94b2cb2ae9dd835dcdfac2d7
Reviewed-on: https://chromium-review.googlesource.com/609683
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496419}
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/BUILD.gn
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/chromeos/BUILD.gn
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/chromeos/app_mode/kiosk_diagnosis_runner.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/chromeos/system_logs/touch_log_source_ozone.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/extensions/api/feedback_private/chrome_feedback_private_delegate.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/extensions/api/feedback_private/chrome_feedback_private_delegate.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_profile_observer.cc
[add] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_uploader_chrome.cc
[add] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_uploader_chrome.h
[add] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_uploader_factory_chrome.cc
[add] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_uploader_factory_chrome.h
[rename] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_util_chromeos.cc
[rename] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/feedback/feedback_util_chromeos.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/chrome/browser/ui/sad_tab.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/BUILD.gn
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_data.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_data.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_data_unittest.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_report.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader.h
[delete] https://crrev.com/fb9560052a9606bedad51935f042f80102399362/components/feedback/feedback_uploader_chrome.cc
[delete] https://crrev.com/fb9560052a9606bedad51935f042f80102399362/components/feedback/feedback_uploader_chrome.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_delegate.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_delegate.h
[rename] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_dispatch_unittest.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_factory.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_factory.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_uploader_unittest.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_util.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/components/feedback/feedback_util.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/extensions/browser/api/feedback_private/feedback_private_api.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/extensions/browser/api/feedback_private/feedback_private_delegate.h
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/extensions/shell/browser/api/feedback_private/shell_feedback_private_delegate.cc
[modify] https://crrev.com/7ff0cdb15ac019795ce27d433542407b50a9a439/extensions/shell/browser/api/feedback_private/shell_feedback_private_delegate.h