Sasha Romijn

How the GitHub contribution graph is harmful

Update 20 April 2016: GitHub has removed the streak statistics from GitHub profiles. They had replied to my ticket earlier already, saying they would not remove the entire graph now, but that they were thinking about options to address my concerns. I think this change is a great improvement.

A common well-being issue in open-source communities is the tendency of people to over-commit. Many contributors care deeply, at the risk of saying yes too often harming their well-being. Open-source communities are especially at risk, because many contributors work next to a full-time job.

Therefore, it’s important that we, as a community, guard against over-commitment, and stimulate contributors to take steps back, small or large, when they feel the need to. That is vital to the long-term well-being of contributors, and therefore vital to the long-term well-being of the community as a whole.

In early 2013, GitHub introduced Contributions. Amongst other things, this includes the contribution calendar/graph. A calendar which rewards people for doing work on as many different days as possible, generally making more contributions, and making contributions on multiple days in a row without a break.

Stepping away from our work regularly is not only important to uphold high quality work, but also to maintain our well-being. For example, I personally do not generally work in the weekends. That’s completely healthy. I take a step back from work and spend time on other things. But in the contribution graph it means I can never make a long streak, even though I do work virtually every day except weekends. So the graph motivates me to work in my weekends as well, and not take breaks.

When I see someone with a 416 day streak, it means they haven’t taken a break for a single day in over a year. Although everyone can make their own choices, it makes me very worried about their well-being. Being based on git activity, which can easily backdated, the graph is also trivial to spoof – so not all long streaks may be real.

Any mechanism in our community that motivates people to avoid taking breaks and avoid stepping back, can be harmful to the well-being of contributors and is thereby harmful to open source as a whole. Even though it was probably introduced with the best intentions. If our interests are really in supporting open-source long-term, this graph should be removed or substantially changed so that it no longer punishes healthy behaviour. At the very least, we should not reward people for streaks. For example, what if we would give people achievements for taking breaks instead of working non-stop?

I sent a summary of the above to GitHub, publicly tracked in an isaacs/github issue.

Announcing Happiness Packets

This week I spoke with my friend Mikey Ariel at DjangoCon Europe 2016 on Healthy Minds in a Healthy Community. One of the exciting projects we announced in this talk is Open-source Happiness Packets.

On stroopwafel rain

I’m one of the organisers on Django Under the Hood, an in-depth Django conference in Amsterdam with 300 attendees. My main task is everything which involves dealing with Dutch people.

Organising conferences, especially with a volunteer team, can be incredibly stressful. There’s venues, speakers, sponsors, tickets, budgets, foods, parties, hotels, flights, communication on websites and social media, artwork, posters, attendee support, code of conduct and much more. There are always things that almost go wrong during the conference, that are quickly fixed behind the scenes.

Conferences are fairly short, and I’m doing this with an amazing team. So as stressful as it is, I feel like I can deal with it. And when I can’t, I feel like it’s ok to ask for help, and it’s ok to step back.

But most of all, the stress organising conferences involves and effort it requires, and all the things that almost went horribly wrong, are all worth it for me and probably many other organisers, when I get an email from an attendee like this:

I feel totally overwhelmed, surprised and very, very grateful. Thank you for caring. You are unbelievable. You are a bunch of craziest, the most positive people I’ve met. You inspire me to give back to community even more. I wish I could express properly what I’m feeling right now…

May it always rain stroopwafels on you. But not all the time, that could be inconvenient. Only when you feel like having stroopwafels. Or someone that you like feels like having stroopwafels. Or you just want to make it rain stroopwafels.

Sending hugs, you crazy, amazing people!’

We got this mail from an attendee which we were able to help with a problem they ran into. And this wasn’t the only email or tweet like this. Being able to make people feel like this, is why I love organising Django Under the Hood.

If you’ve ever organised events, or worked in other fast high-stress situations, you might know that the team is everything. It is so important to feel like you can ask for help or step back. Even if you don’t have to. Because even when you need help, when you need to step back, even when you sometimes flake, even when you make mistakes, you are probably much more appreciated than you think. Especially the Django community is full of friends that are loving, caring and supportive. That’s why I am still there. And almost all of us sometimes flake and we all make mistakes. And our community is here to support us when that happens.

Yay, you made it!

In the Django community, we already do great work in that area, by creating a positive atmosphere in which everyone feels great. With posters that make people feel just a bit more welcome. With a slack channel so that attendees can talk even before the conference start and make plans to do things together, which especially makes a difference to people that are more shy and/or come alone. We try hard to make everyone feel like they’re a part of this community, and that we’re delighted to have them with us.

Why it matters

Unfortunately, the reality of contributing is too often still like this:

But the feeling that you made a difference, that your work matters and and has value, and that the people that you work with happy to work with you, is an awesome feeling. And not just an awesome feeling, but an important feeling as well. It helps us feel like we matter, that we’ve made a positive change, and that people care. It gives energy.

Whether it’s code, supporting the DSF, helping to build small or large events or anything else. These feelings can all have substantial effects on people struggling with self-esteem, burnout or anxiety, or anyone leaning towards those. Which applies to so many of us.

I can certainly say that for me, seeing emails and tweets like the one I read out makes a huge difference, and we feel our community would be an even better place if there would be more of that. Because even we don’t always let people know how much we care about them. Therefore, I’m proud to introduce:

Open-source Happiness Packets!

The thing is, openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you prefer, but of course, we encourage you to share your name, but it’s completely optional!

We’re tremendously excited to see where this will go and where we can take this together. We’re fairly sure you have people in your community that you are grateful too or admire, and we’d like to ask you to send a happiness packet to two or more of them right after reading this post. We know it can feel a little awkward at first, but we’re sure you’ll make a big difference to both yourself and who you’re sending it to.

Further reading

We also published all resources we used for this talk, that you might find helpful.

Why you should speak (at Djangocon Europe)

In early June, Djangocon Europe is held in Cardiff, Wales, and the call for papers is still open until the 18th of March. The aim is to not only have familiar names in the schedule, but to achieve a good mix with first time speakers as well. There are even speaker mentors offering to help. However, if you’ve never spoken in public before, or rarely, it can be a quite daunting to submit to a conference as large as Djangocon. I’m a fairly experienced public speaker, and hope to dispel some of the doubts you may have about submitting. Much of this will apply to other conferences as well.

Read on →

Crypto weaknesses in the Ectual energy meter

A while ago I was a mentor at the Apps for Energy hackathon, where energy company Enexis had a demo setup of their Ectual energy meter. A customer can hook this device up to their existing energy meter, and it’ll read out energy usage every 10 seconds and make that available to apps or other services.

10-second energy data of homes is very sensitive, as it can say a lot about the inhabitants and their lives. So security for this data is essential. Fortunately, all sensitive data is encrypted with AES-128-CGM. The key is derived from an app password set by the user, which also means that if they change their password, all old apps will instantly lose access. However, the crypto is significantly weaker than it could be: some of the choices in the crypto make it significantly easier to find the password. Although the actual viability of such an attack is difficult to determine, the margin of safety is awfully small, and there are missed opportunities that would make the design dramatically stronger.

Read on →

Vulnerability in Apple portal compromised iOS keychain access groups

When writing web applications, we make use of the many features of browsers to improve the experience, like javascript validation. But convenient as they may be, we can never ever rely on these features when it comes to protecting the data of other users. The browser is entirely controlled by a potentially malicious user, which means that whatever the browser does, our systems should be designed not to allow harm to any other user. The browser is not your friend.

A little while ago, I discovered a vulnerability in the Apple provisioning portal, where developers register App IDs and provisioning profiles. The portal made the mistaken assumption that it could rely on the browser. The impact was that any developer could submit an app that would be able to read the Keychain entries created by another app if the other app used Keychain access groups, a commonly used and widely recommended feature.

The end result is that it allowed any iOS developer to create an app that passes App Store validation and could read the secrets stored by specific third-party apps, such as Dropbox, PayPal or the Google Authenticator. I first noticed this vulnerability was fixed on October 10, 2014, over one year after my initial report to Apple.

Read on →

Why and how I get 100% test coverage for my Django projects, and you should too

Automated testing has become axiomatic in the Python community. The Django tutorial, for example, explains testing Django projects before even explaining how to deal with CSS. A common measurement for tests is test coverage: the percentage of lines, branches or files of the code that are executed when the tests are run. How high this number should be is a frequently debated subject, but general consensus is to aim for 90-95%, with 100% being utopian unrealistic and not worth the time it may take. Some don’t care about test coverage at all, because high test coverage doesn’t guarantee the tests are any good.

"100% test coverage by @bloerwald"

For my own projects, I’ve adopted a new rule: all code must have 100% test coverage. I am not done done until the unit tests have 100% coverage. How is this not utopian, unrealistic, and a waste of time? Because I count test coverage after exclusions. Although even that won’t help you to catch every scenario.

Read on →

Phishing out iOS URL schemes

In iOS, there are limited options to communicate with other apps. One of the most common choices is custom URL schemes. Like Safari picking up most links beginning with http:// or https:// (http(s) being the URL scheme in that case), opening a URL with the facetime scheme starts a FaceTime call.

Many third party apps that want to offer integration into their app do this with URL schemes. There are several lists of apps and their URL schemes. Using URL schemes is a good choice. It’s officially supported, and it’s trivial to integrate into an app. If I would want to open the Schiphol Airport venue in the Foursquare app, I would do:

UIApplication *app = [UIApplication sharedApplication];
NSString *path = @"foursquare://venues/4a84e798f964a520defd1fe3";
NSURL *url = [NSURL URLWithString:path];
[app openURL:url];

URL schemes are just like normal links, so you can also include them in a website. If you have Foursquare installed and are reading from iOS, this link should open the app, showing Schiphol Airport.

As a developer, it’s simple to register a URL scheme as well. There is no registration required with Apple. All you have to do is declare it in your Info.plist:

Now, hold on there: I’m not actually the maintainer of the foursquare app. What happens when both their app and mine claim to respond to foursquare://, and both are installed on a user’s device? Apple writes:

Read on →

The definitive guide to cookie domains and why a www-prefix makes your website safer

Restricting access to cookies is essential for security in many web apps. For example, the session ID, the secret token used to identify a particular session, is typically stored in a cookie. Cookies have several important settings. Previously, I discussed the secure flag. This time, let’s dive into the cookie domain.

The cookie domain is an important security feature, probably even more important than the secure flag. It tells the browser that this cookie must only be sent to matching domains. Matching however, can happen in several ways. Perhaps domain is a bit of a misnomer: this can be any host name, like

With this in mind, I did some digging into the exact workings of cookie domains, and was surprised to find this less straight forward than I had expected. And, it turns out Internet Explorer’s RFC-incompliant behaviour makes it safer to host your websites with a www-prefix, so instead of

Update: this post was updated on April 9, 2014, to reflect that Internet Explorer misbehaves with domain-less cookies, as learned from this blog post. Previously, I concluded that a www-prefix makes no difference, with this new knowledge, a www-prefix is safer.

Read on →

Why your certificate authority rarely matters, and expensive certificates are not safer

When you deploy HTTPS, you’ll typically need to get an SSL certificate signed by a commonly trusted certificate authority. Certificates and authorities come at many different pricing levels with many different validation depths. A common misconception is that more expensive certificates provide better security. In reality, your choice of vendor rarely matters, and more expensive certificates do not make your website safer.

Read on →

But where is the decryption key?

Encrypting sensitive data is usually a good practice. You’ll see many organisations, like Dropbox, advertise this as part of their offering:

Or Apple iCloud:

This means that your data is protected from unauthorized access … when it is stored in the cloud. iCloud uses a minimum of 128-bit AES encryption …

Using strong AES for this situation is a good choice. There are some other technical details to be considered, like the block cipher mode. However, a more fundamental question is missing. The technology used, be it AES or DES, is only half the story when we wonder about the security of data. The other important question is: where is the decryption key?

The nature of encryption of data means there is always someone or something holding the decryption key. If nobody has the key, nobody can decrypt it. And to someone with the decryption key, the encryption method is largely irrelevant, as with the key, the data can be effortlessly decrypted.

Read on →