GitMask – Develop Anonymously
gitmask.com
gitmask.com
If I were that paranoid, I feel like I'd greatly prefer a tool that strips everything out on the client, then establishes a connection to your site via a Tor hidden service which then publishes the PR.
Another concern; isn't this a potential avenue for spam? How long before someone submits a bunch of spam PRs through the service and gets your Gitmask user account banned on GitHub as a result?
Spam is a potential issue. All PR's reference gitmask.com so maintainers have someone to message if they get flooded.
If there is a question about non-OSS code coming in from Gitmask in a lawsuit, the affected project will most likely have to discard and rewrite all those contributions.
Firefox:
> Private Browsing doesn’t make you anonymous on the Internet. Your employer or Internet service provider can still know what page you visit.
Chrome:
> Your activity might still be visible to:
> * Websites you visit
> * Your employer or school
> * Your internet service provider
Though I'd argue that Chrome's message is less explicit because of the "might still be".
I also seem to remember that Chrome at one point used slightly more playful language explaining that incognito mode doesn't protect you from people looking over your shoulder either but that no longer seems to be the case.
Print: https://imgur.com/UqSUUTA
On a faster connection it worked fine. Not sure what this spinner is (can't debug on mobile). Ordinarily I wouldn't bother much making my service accessible for those with extremely crappy connection, but given your service might be used by people on 3rd world countries, behind proxies and so on, it might be a good idea to simulate slow connections on your landing page :) Maybe adding a "close" button would solve
Some people also don't wanna run 57 (yet) because their favourite extension(s) aren't ported from <= 56 yet. So they stay on older versions. Current ESR (Extended Release, akin to LTS) is 52.
should be "its inventor"
Also, the H in GitHub is capitalized.
You should be aware code style is some times enough to de-anonymize a well know developer!
When coding style survives compilation: De-anonymizing programmers from executable binaries
https://freedom-to-tinker.com/2015/12/29/when-coding-style-s...
I think an unknown crator would be the only way to make something that wasn't "owned" by him/her in this case.
If you pay me to make a software product, does it mean that I always keep the copyright?
What's worse: GitMask would need to guarantee that any given PR meets these requirements and expose this status to the repository owner. This would make GitMask liable but they could escalate to the original author -- but that in turn would jeopardise the anonymity guarantees to a degree.
Imagine the following scenario:
1. Person A creates application X and publishes it under a non-permissive commercial license.
2. Person A uses GitMask to create a PR to an open source project Y of competitor B and includes source code from application X in the PR.
3. Maintainers of project Y merge the PR without being able to verify the identity of the author and publish the updated version.
4. Person A sues competitor B over the use of the source code from application X in project Y.
5. Competitor B blames GitMask for introducing the infringing code.
Now depending on what GitMask has done, this could result in different outcomes.
A. The status quo: GitMask provided no guarantees about the legal status of the code and retains no information about the author, so competitor B acted in negligence and is fully liable.
B. GitMask does provide guarantees but requires no guarantees from the author, so GitMask is at least partly liable. If GitMask retained any information about the author they can try to sue over violation of the ToS but good luck with that.
C. GitMask provides guarantees and requires formal guarantees from the author. GitMask is likely liable but they can hold the author accountable. In this scenario GitMask could demonstrate fraudulent behaviour, bad times for person A.
IANAL, TINLA.
For example, under Urheberrecht an author can always revoke the rights of the publisher, while under Copyright the rights are traded away and nothing remains with the author.
In Germany you cannot buy stock photos and use them however you want. The creator may sue you if he thinks he was not treated fairly.
Back to source code: No fear! If a programmer gives away source code knowingly under an Open Source licence, it cannot be revoked since the terms of publication are very clear. Still, there is no such concept as "giving copyright to a foundation" under Urheberrecht.
In general, Copyright protects the publishers, while Urheberrecht protects the creators.
In copyright, transfers from authors can be reclaimed, though there is a specific 5-year time window (starting 35 years after the grant, basically) for this to be exercised.
> In Germany you cannot buy stock photos and use them however you want. The creator may sue you if he thinks he was not treated fairly.
The US copyright system has a similar protection for creators of unique or limited physical works of visual art, but it doesn't protect against reproductions in derivative works or use of stock photos.
Yes and no. There is such a thing as an irrevocable usage right. But I'll concede that even an irrevocable right can be nullified under the right conditions (e.g. if the person granting it wasn't actually in the legal position to do so).
While the employee still has the creator rights he cannot exercise them since the content contains trade secrets.
Additionally, software is special cased in German copyright law (§ 69b): the employer automatically gets all exclusive exploitation rights. For patentable software an additional renumeration is mandatory.
Keep in mind that's only for regular employees. Freelancers are not considered employees so §69b doesn't apply (despite the part about "service relationships"). If licensing isn't part of the contract (or more likely: if there is no formal contract at all), the freelancer retains all rights and just grants a non-exclusive non-transferable irrevocable usage right.
So if you hire a freelancer and want something more than that, make sure to set up an actual contract approved by an actual lawyer.
See (German): http://www.it-recht-kanzlei.de/nutzungsrechte-individualsoft...
Yes, this is important to keep in mind. The "service relationships" part (Dienstverhältnisse) is referencing state employees.
I don't know whether most business people are aware of §69b at all but in my experience many people just hire freelancers without a specific copyright arrangement and are then deeply surprised when they find out they don't actually own the project they paid the freelancer to create for them.
If it's a throwaway project with little economic value for the company, they might accept the PR. Otherwise the uncertain copyright status would be a no-go.
Also curious how this does with, say, updating a PR.
Under the hood its pretty simple (and open source), just an AWS lambda squashing the commits and stripping metadata before pushing to Github. Potentially you could tie the commit to an IP address, but I'm not logging any of that info.
I'm not really sure how I can prove that the code I'm running is the code you'll find on GH though.
I think this attestation is something Amazon (and other cloud providers) could offer in the future - they're the only ones who can really prove it.
"I, Amazon AWS, do solemnly declare that the code running on {service} is {git hash}"
Honestly not sure there is a good solution for that.
As a maintainer myself, I can respect that. If the PR is important enough, I'm more than happy to merge it without knowing the author (with some additional tweaking if necessary).
Big projects? no.
But I sometimes submit patches to small projects that I've integrated into personal projects, and pretty much every patch I've ever submitted has been accepted without comment.
I set my git username and email to "<>" at the global level, which completely breaks githubs UI, and people /still/ accept the pull requests.
Simply having that easily accessible may got a long way.
Oddly enough, just last week I got in a row with someone else with exactly the same idea: https://www.reddit.com/r/programming/comments/7kp73c/anonymo...
GitHub put a lot of work into their anti-spam systems and this basically let's people bypass that completely. If I was them I'd shut it down right now.
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Just in case there's any data leakage.
Really? The only information I know of that gets into a commit is your name & email and the current time, and the first two have to be configured before you can commit.
If you're on a linux machine, usually it can't, so it pops up the "set your global user and email" prompt without committing things.
If you're on a domain windows machine though, often it can. When that's the case, it does the commit first, and then asks you to set the config explicitly. You then swear, change the config to be blank, and then go amend the commit you just made.
In any case, the whole thing is a pain that adds mental overhead I'd rather spend on programming.
I miss the pseudonym era of the internet. Uploading my nudes to Facebook so they can ID me is so dystopian.
It's 2018. Dick jokes and "your girlfriend" examples have no place in software engineering, not that they ever did. That holds doubly true for a project whose target audience potentially includes people who have reasons to protect their identity.
As potentially better examples: contributions to the bitcoin repository tend to result in spam from random people who think that the list of every contributor to bitcoin is the right list to send random cryptocurrency spam to. Or, you might want to contribute to the https-everywhere repository without revealing sensitive sites you're contributing entries for. ("Potentially sensitive" here could mean a wide variety of things, such as sites for sufferers of a particular medical condition, sites for organizations whose members regularly get targeted, etc.)
I'll take another pass at it.
How about a better example: contributors to the bitcoin repository tend to be targets of digital theft.
In any case, this is a tool I've wanted for a while. I have my own absolutely horrid workflow for stripping out the interim changes to github projects I work on and submitting back one atomic commit with no personal info, but it's a trainwreck and it makes me way less enthusiastic to make commits to projects on github.
I do really want something better, and this looks promising.
Side note: the Git project is enforcing the Git trademark now.[2] If you want to use "Git" for your branding, you'll need to get approval.
1. https://www.colbyrussell.com/2016/02/13/keeping-a-low-profil...
2. https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
> Don't just create one account for each contribution you plan to make through github.com, e.g., so that you don't have to worry about deleting them. Unless you're paying for all those accounts, this is also against the GitHub terms.
I've always created throwaway accounts in the rare cases where a maintainer won't accept an emailed patch. As for hosting/mirroring hobby projects, http://repo.or.cz is nice.
What part of GitHub does this person have a problem with? It's entirely unclear what they mean by social network. Is that like, showing the commits you make on your profile? Having a page that shows what you've worked on at all? This seems like good ways to be difficult to work with in open source projects for zero benefit.
> Is that like, showing the commits you make on your profile?
Yes.
> Having a page that shows what you've worked on at all?
Yes.
> This seems like good ways to be difficult to work with in open source projects
First, open source doesn't start and end with GitHub.
Second, I prefer not to publish anything to Facebook or Twitter feeds, either. That's a position that folks seem to find palatable. (In fact, it's one that programmers appear to be disproportionately sympathetic to.) I don't see why it shouldn't remain so if the subject of the conversation is GitHub.
> for zero benefit
Opting out of the same kinds of personal broadcasting on GitHub isn't "zero benefit" to me. And if it is zero-benefit, it means the service linked here is zero-value. I feel differently. We don't have to agree.
I didn't mean to imply it is, but if an open source project finds it easier to use one platform (such as github), trying to subvert that by emailing patches sounds like a very annoying thing to do. It seems similar to submitting pull requests to the Linux Kernel on GitHub, which explicitly requests that you submit patches on the mailing list.
I enjoy scraping GitHub user data and have found it a great goldmine of data.
95% of the time I can recover an email address for a user based on their commits, even when the email is not publicly visible on GitHub.
Very insecure.
Even though it's only static images and text!…
If you are a project maintainer on GitHub, how could you accept a PR from an anonymous user? Let's say you accepted it, and later some company said that the code from that PR is "stolen" from their code base, and that's true, how do you deal with that?
I hate the idea of having an identity on github. I don't want to be contacted for support, and I don't want my email being harvested by spam bots and recruiting agencies (both of which has happened).
I know a lot of smaller projects won't bother with CLA, but their maintainers can still assess the possibility of stolen code and act accordingly. If I'm a maintainer and the possibility of an incoming PR is stolen (the complexity of the PR, basically) is high enough, I would look at the information associated with the contributor (the GitHub account, the email address, etc.). If it's someone contribute a lot to other open source projects I would be more likely to accept it.
Actually on second thought, GitHub really should provide free CLA management service to all its users: you (as a project maintainer) can enable CLA requirement on your project, once enabled a GitHub-run CLA bot will ask new contributors sign a CLA in their first PR, and you can get all the signed CLAs when needed. If GitLab or BitBucket provide this feature before GitHub I'll move my projects over in a heartbeat.
"Just because you think DICSS is amusing, doesn't mean you want your boss to know about it. How about your SO?"
If you are writing code you need to hide from your SO you have some serious relationship problems.
If I really wanted to be anonymous on GitHub I'd create a "fake" account/would not use my name.
Please explain which part of this project ensures even less accountability than accepting code from a newly created GitHub account.
In addition, I would love to hear how you would hold someone introducing a backdoor through a GitHub PR accountable even if you know exactly who they are, where they live, and have a video of them opening the pr, and a signed confession.
The only difference is that GitMask invites more anonymous developers. Whether that is in the interest of other (anonymous and/or non-anonymous) developers and users is a matter of perspective, and case-by-case hindsight 20/20.
As for holding someone who's known accountable for their mistakes. That's the entire point of using your real name when it comes to professional work: it increases accountability.
Participation in discussions is a necessity for most interactions with an open source community.
EDIT: Just saying, if you link to a main page... Make it accessible. Most serious privacy advocates probably have JS disabled by default.