-
Notifications
You must be signed in to change notification settings - Fork 60
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
Comments
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: Lines 34 to 39 in 983e9c1
To use 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 |
@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! |
i personally would love this feature as optional and if the concern is about exposing repo/username e.g.
|
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). |
Proposal
Why?
Implementation
repo:status
scope. Currently, this action uses just thegist
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 therepo:status
scope if they chose to use the optional private activity.The text was updated successfully, but these errors were encountered: