The Google permission request list is too long, or unexplained

[straylightlabs]

┆Attachments: Screen Shot 2017-03-24 at 7.37.12.png | Apple_Support_Appt.ics

[straylightlabs]

➤ Ryo Kawaguchi commented: https://app.asana.com/0/54354912735119/54354912735119 https://app.asana.com/0/290290152316163/290290152316163 Let's discuss it here.

I'm for dropping "phone numbers" and "street address" just to make the list shorter to change the impressions that users get.

We could also delay "calendars" permissions until the user opens Guests page.

For context: email: Used for internal ID basic profile info: Full name and profile image calendar: used to create calendar entries for guest registration phone number: used to prefill profile edit form street address: used to prefill profile edit form

[straylightlabs]

➤ Ryo Kawaguchi commented: We may want to ask every member to have at_straylight.jp address if we want to manage their calendars. now that I think about it, I totally understand not wanting to expose your private calendar. Although we say ethos of the community is trust, leaks happen usually unintentionally. Or we may provide an option to the users whether they want their calendars be automatically managed or they do it manually from iCal link or something.

[straylightlabs]

➤ Anuraag Agrawal commented: +1 to restricting to email and profile info, which seems to be the standard list when using oauth login in general. I think you don't need calendar either, if you send a confirmation email with a .ics file attached, Gmail will automatically add it to calendar.

[straylightlabs]

➤ Ryo Kawaguchi commented: Cool. I didn't know iCal support modification and cancellation, too. Would an event be automatically added without the user opening the email? I'll test it later but if you know the answer already ..

[straylightlabs]

➤ Ryo Kawaguchi commented: One thing to note is that we are not just building a guest registration page. We want to be building more online tools over time for various community events, and a platform that supports it.

[straylightlabs]

➤ Anuraag Agrawal commented: It got automatically added without opening it when I saw it recently - it was for an Apple Genius Bar reservation. But I'm not sure if there is a whitelist of services that are auto-added there might be.

[straylightlabs]

➤ Anuraag Agrawal commented: I attached the ICS file that came from Apple Genius Bar

[straylightlabs]

➤ Ryo Kawaguchi commented: Thanks Rag :smile:

[straylightlabs]

➤ Ryo Kawaguchi commented: Rag, could you plz take a look? https://github.com/straylightlabs/straylightportal/pull/24

[straylightlabs]

➤ Taj Campbell commented: would like to discuss this more, ie concerns vs conveniences of pulling this. I think more explanation is probably better than disabling these permissions and creating extra steps elsewhere

[straylightlabs]

➤ Anuraag Agrawal commented: I think it's a security best practice for services not to ask for non-essential permissions and for users not to grant them. As Ryo said, the worry is bugs, and it's good to limit the scope of bugs. I'm data-security conscious and can't risk a bug deleting random events from my calendar. And I think teaching this sort of security-mindedness is probably beneficial to the community as well.

[straylightlabs]

➤ Taj Campbell commented: no doubt, also want to understand how we can keep user flows simple. there are design changes that can be made on both ends

[straylightlabs]

➤ Taj Campbell commented: eg maybe we can have a straylight account create all events rather than require any calendar permissions, and still keep the ui flows the same

[straylightlabs]

➤ Taj Campbell commented: sorry typing all from phone. my suggestion would be: keep all profile permissions (ie automatically fill profile with address phone etc) require no calendar permissions by having all events created by a 3rd party account, eg straylightone@gmail.com if we can't use an internal alias/group (otherwise new accounts on straylight org cost $50 per year which seems silly if this is the only function of another account)

[straylightlabs]

➤ Anuraag Agrawal commented: If the profile permission is just to prefill a couple of fields, again I think it's a wrong security decision for a user to grant permissions for such a minor convenience. It's better for users to be using the browser's autofill function which keeps things safely siloed and can be used on any website out there - we can add an explanation and tutorial of autofill in the library. At my previous company I realized just how important a library of security training is so this sounds like a good start :D

[straylightlabs]

➤ Taj Campbell commented: I'm not sure I agree with the profile data, as i think those permissions in fact exist exactly for this purpose. what is the security risk or scenario you are concerned about?

[straylightlabs]

➤ Anuraag Agrawal commented: Access tokens end up in JavaScript usually, making them pretty accessible to XSS. It's why I'd treat them even more sensitive than the DB, which is remote and much harder to hack. My concern is the token, if handled normally would have access to PII well after the registration flow ends. An XSS or such may not happen now but who knows when - weak tokens have lower risk.

I think it would be reasonably secure if it is possible for us to remove scopes from a token without the login flow. I'm not sure if it's possible but I think it might since it does support the incremental addition of scopes. In that case, we just need to have a message under the login button like "We request access to your phone and address to prefill inputs in the registration flow. We immediately remove access to the data when registration is complete. You can always check out the access straylight has at https://myaccount.google.com/permissions and revoke it at any time."

[straylightlabs]

➤ Anuraag Agrawal commented: I can't edit, maybe since I'm on mobile, but would also add something like "Your security is important to us - we remove..."

[straylightlabs]

➤ Taj Campbell commented: thanks for explaining. feel free to make the changes you see fit for the interim (eg removing unnecessary permissions that are poorly explained). I'll follow up more on Monday for additional UI changes that might help optimise the user flow in the future.

[straylightlabs]

➤ Taj Campbell commented: or if you'd like, the suggested messages also sound fine if you want to add them in, and I can try to help refine later

[straylightlabs]

➤ Ryo Kawaguchi commented: I'm going to remove phone number and address scope for now. I'm curious how many people actually have phone numbers and physical address registered with google account. At least I don't, it turned out, either for straylight account and personal one. I have phone number registered for account recovery purpose, but this doesn't count as profile information so can not be retrieved through Google People API.

You can test what you get using this page: https://developers.google.com/people/api/rest/v1/people/get resourceName: people/me requestMask.includeField: person.phoneNumbers,person.addresses

[straylightlabs]

➤ Ryo Kawaguchi commented: For guest registration page, I believe we can use robot accounts as Taj suggested.

Internal) owner: robot account calendar: Straylight One calendar attendees: [] allow_guests_modification: false

External) owner: robot account calendar: A new calendar owned by the robot account attendees: [host, guest] allow_guests_modification: true

[straylightlabs]

➤ Ryo Kawaguchi commented: While I figure out how to do the above, let me just defer the calendar scope request to guest registration page, so at least profile edit and billing can be completed without authorizing calendar scope. I will implement the above asap.

[straylightlabs]

➤ Ryo Kawaguchi commented: I'm so happy to see a thread like this BTW. Thank you Rag :smile:

[straylightlabs]

➤ Taj Campbell commented: decision here was to reduce profile data request, and move over calendar registration to a bot account. re-assigning to ryo