3 ms·

In other words, the problem is with describing secret information as "public".

by l0b0 6y ago

derefr 6y ago
GitHub phrases the permission as something like “This app can view your public email address.” The “public” there is GitHub distinguishing which of the email addresses associated with your account it is exposing to the app. One of a GitHub account’s email addresses can be set to be publicly shown on your GitHub profile. Other email addresses can also be associated with your account (for login/recovery), but these are private. The permission only allows the app access to the public one, not the private one. Really, it’s not the “email address” in the grant description that would properly be qualified by “private.” It’s the “your.” But granting the app permission to know the logged-in GitHub user’s numeric ID, isn’t part of any of the permission scopes, but is instead the base permission the app gets when you click “Accept” on the app binding request. The only thing the “view your email address” permission allows is for the app to look up the primary public email address (if one exists!) for the GitHub account with the ID it now already knows, given a successful OAuth callback. Technically, just having the GitHub ID is enough to SSO you against GitHub, in the oldschool OpenID sense of SSO (or to track you across the internet.) The implicit default scope of an app grant already breached the privacy of “your.” So the additional permission about emails doesn’t have to qualify anything, because it’s not giving anything still private away. It’s just protecting something actually public from being mapped to from the private credential the app, at that point, already has access to. It’s putting up a roadblock in one direction of a lookup that could be done entirely without the API (by scraping user’s profile pages for internal user IDs + email addresses, and building a table indexed by user ID.)

In other words, the problem is with describing secret information as "public".

by l0b0 6y ago

In other words, the problem is with describing secret information as "public".

GitHub phrases the permission as something like “This app can view your public email address.” The “public” there is GitHub distinguishing which of the email addresses associated with your account it is exposing to the app. One of a GitHub account’s email addresses can be set to be publicly shown on your GitHub profile. Other email addresses can also be associated with your account (for login/recovery), but these are private. The permission only allows the app access to the public one, not the private one. Really, it’s not the “email address” in the grant description that would properly be qualified by “private.” It’s the “your.” But granting the app permission to know the logged-in GitHub user’s numeric ID, isn’t part of any of the permission scopes, but is instead the base permission the app gets when you click “Accept” on the app binding request. The only thing the “view your email address” permission allows is for the app to look up the primary public email address (if one exists!) for the GitHub account with the ID it now already knows, given a successful OAuth callback. Technically, just having the GitHub ID is enough to SSO you against GitHub, in the oldschool OpenID sense of SSO (or to track you across the internet.) The implicit default scope of an app grant already breached the privacy of “your.” So the additional permission about emails doesn’t have to qualify anything, because it’s not giving anything still private away. It’s just protecting something actually public from being mapped to from the private credential the app, at that point, already has access to. It’s putting up a roadblock in one direction of a lookup that could be done entirely without the API (by scraping user’s profile pages for internal user IDs + email addresses, and building a table indexed by user ID.)