Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional Private Activity #13

Open
HPaulson opened this issue Jun 4, 2020 · 4 comments
Open

Optional Private Activity #13

HPaulson opened this issue Jun 4, 2020 · 4 comments

Comments

@HPaulson
Copy link

HPaulson commented Jun 4, 2020

Proposal

  • Personally, I love this gist updater. I've been using it for a bit now, and find it fairly useful and unique. However, I work on closed-source projects much, much more often than open source ones. I'm sure that many others could relate. For this reason, I think it could be super beneficial for this action to include an option for displaying recent activity in private repos.

Why?

  • I think that this could be a very large benefit. Having optional support for displaying private-repo activity could be super cool to users who want to display it, and out of the way for users who don't wish to display it. Many GitHub users may work on closed-source projects, where they still have a community and would wish to display their overall activities on a gist. Similar to how GitHub allows private contributions to be accounted for in your "Contributions" tab, however it is not mandatory. This would be a very nice option to have, especially since private-repos are now unlimited and free on Github Orgs and Individuals, and will be used more often in the future than before.

Implementation

  • Using the GitHub API, you could easily accomplish this using the repo:status scope. Currently, this action uses just the gist scope to edit gists, and needs an access token anyway. With this feature, you could simply implement it by using the same access token they already provide, but requiring the repo:status scope if they chose to use the optional private activity.
@JasonEtco
Copy link
Owner

Hey @C0braD3v! Thanks for opening this, and for the clear, descriptive write-up - really helps me understand what you're thinking.

In terms of implementation, it would be changing this:

activity-box/index.js

Lines 34 to 39 in 983e9c1

// Get the user's public events
tools.log.debug(`Getting activity for ${GH_USERNAME}`)
const events = await tools.github.activity.listPublicEventsForUser({
username: GH_USERNAME,
per_page: 100
})

To use tools.github.activity.listEventsForAuthenticatedUser. So from a technical perspective, it's a pretty small lift.


That said - I think this would be a dangerous change. Private repos are private for a reason - the activity within them is not meant for public visibility, and is often sensitive and confidential. This would provide a really easy way to make a bad mistake and expose private information to all of GitHub. It's certainly already possible by querying the data manually and sharing it manually, and all the way to copy-pasting issues/PRs/code and sharing it yourself. Within GitHub, even repository names are treated as users' confidential information, we'll never surface the names of private repos that you can't see.

My overall feeling is that if you can't share the activity itself, it shouldn't be possible to show that it exists. If it helps, a specific example would be if you were interviewing for another employer, and they asked you to open a private repo called <username>/name-of-company-interview - that'd show up on your profile, even if you weren't expecting it to. That's a dangerous possibility, and one that's safer to just avoid entirely.

@HPaulson
Copy link
Author

HPaulson commented Jun 4, 2020

@JasonEtco Hey, thanks for the quick reply!

This is why I had mentioned this as a totally optional feature. Here’s a use case that may make some sense, and for me, is my use case and thought process:

My company has a fairly large project what we develop for our users. We wish not to share the source code of this project, as others could easily rebrand it which we don’t want. However, we do encourage our community to be involved in the development process - and be able to see what we’re working on. For this reason, we use webhooks to currently display activity in our repos to our users, even though they’re private. This hasn’t been an issue thus far, and I couldn’t see it being one in the future. In fact, it’s been a nice benefit for users to be able to see update progress, what we’re working on, and give input on what’s being completed and when.

This being said, however, I do understand your security concern. This could be a major issue for some cases as you mentioned. Even though this would be totally optional, someone could forget they have it turned on, and leak information they don’t intent to. My proposal to fix this issue would be simple: Have a list of whitelisted private repos. In this case, the user would select repos they want to include in their activity, and only activity from those repos would be displayed. From a technical standpoint, this should be very easy to implement, as you could simply filter through activity and only use data from those whitelisted. What are your thoughts on this? Personally I think it would 110% solve the issue of making a mistake, especially on the example you mentioned. You obviously wouldn’t whitelist your interview repo, so that activity wouldn’t show. And if you did, then you gave full knowing consent to allow that project to display, since you whitelisted it by typing it out manually. Don’t see any margin of error here.

Thanks!
~Hunter

@iamaamir
Copy link

i personally would love this feature as optional and if the concern is about exposing repo/username
we can simply replace those with Private Repo

e.g.

  • Commented in Private Repo
  • Created PR in Private Repo

@JasonEtco
Copy link
Owner

Ooh I like that approach. I'd be open to a PR that redacts any titles in private repos; though, I'm not sure if the API in question returns the repository's privacy, and I don't think we should be making followup requests for each repo (although that's probably also fine).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants