Category Archives: English

All my non-Norwegian posts

OpenID Connect 3: Slack can be the identity hub of small organizations

(Technically, this is a blogpost about Oauth2 and not OpenID Connect)

Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy?

For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere. Access to private channels is often well managed as you don’t want random people in your limited conversations.

For many organizations, especially small ones, Slack may be the best option for authenticating your users on other applications. Unlike Google or other social identity providers, you can control who is a member of your Slack team, you can audit and confirm their profile information and you can restrict which channels they can access. The channel membership is a nice fit for application privileges, so you can say things like “this application can only be used by Slack users on the private channel #admin”

Slack implements Oauth2, which is a subset of OpenID Connect. This means that once you have the user’s access token, you have to make a Slack specific API call to get the user profile and other information, like their list of channels. So there is slightly more custom integration code than for full OpenID Connect providers.

For organization that already have a well established Slack team and no other identity manager in use (such as Active Directory), Slack may be your best source of trust for other applications. You can integrate with it using the standard Oauth2 protocol.

You can start your journey at my Boosterconf workshop in Bergen March 14th.

Posted in English, Identity | Leave a comment

OpenID Connect 2: Why I ❤ ID-porten

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Norway’s national Identity Provider

The advantages of using ID porten as an identity provider are considerable, but it comes with limitations as well. ID-porten is the identify provider supplied by the Norwegian government to all residents of Norway. It is (almost) fully compliant with OpenID Connect and is compatible with most tools and libraries.

When your user is authenticated with ID-porten, your application receives their national identification number (fødselsnummer eller d-nummer). This identity is generally safeguarded by two factor authentication and the user has been validated by personally showing their identification papers in a bank or police office. You can be very certain of the user’s identify.

The limitation is that even though you know the user’s identification number, you know very little about the user. You have to be authorized to use the national population register and do the lookup yourself to get their name and address. And even then, you don’t know what organizations the user is associated with and what authorization they have there. (This limitation is natural, considering the scope of responsibility of ID-porten)

So the dilemma is that you can be quite sure of who the user is, but you have no idea who they user is. 😂

(Some of this information is available in other national registers and as time goes by, it may be more accessible)

Furthermore, even though you know who your user is, you don’t know if you can trust them or if they are a crook. Most convinced criminals of course retain their right to use online banking and naturally they have ID-porten access. And that’s the way I think we should treat people, even those who have messed up in their lives.

Getting started with ID-porten is a bit harder than for other OpenID Connect providers, but this is mostly administration. First, not all applications are authorized to use it, of course, so you must contact Difi to get access. Secondly, ID-porten is very limited in terms for self service of application administration, so getting client credentials also involved soon emailing.

But once you have your application credentials, integrating with ID-porten is just as simple as any other OpenID Connect provider. As a matter of fact, I’ve made apps that work with Google accounts and re-targeted them to ID-porten with only changes to credentials.

Difi’s OpenID implementation is impressively accurate and robust, but there are still some issues you may run into in mobile app scenarios. (In technical parlance, response_mode=fragment doesn’t support response_type=code without a client secret, which is the easiest secure option for apps)

If you are providing services to Norwegians on behalf of local or state government, ID-porten is your mandatory identity provider. And you can use existing knowledge and tools for OpenID Connect to do so.

You can start your journey at my Javabin talk in Oslo this Wednesday.

Posted in English, Identity | Leave a comment

OpenID Connect 1: Microsoft Azure Active Directory

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master. As a developer, you owe yourself and your users to play with OpenID Connect before you ever implement a username+password.

You can start your journey into OpenID Connect at my JavaBin presentation this Wednesday, or my workshop at Boosterconf in Bergen.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Why Microsoft Azure Active Directory can enable cross-organization cooperation

The main advantage of using Microsoft’s Active Directory as an OpenID Connect provider is that you can validate your users’ association with specific organizations, whether it’s your own organization or one of your customers or suppliers.

While an identity provider like Google accounts or Facebook will supply the name of the user, this information is not at all validated. Just because a Google user is registered with the name “Johannes Brodwall”, there is no way of knowing if this is truly their name. But if you get the same name from Sopra Steria’s active directory, you can be a lot more confident.


Similarly, end user Identity providers like Google and Facebook can validate that a user had an address at some point in time. But when the same claim comes from active directory, you know that this email address was still active at the time of the authentication. Again a much more powerful claim.

Your trust is limited to your knowledge of the users organization, of course. The first time a user arrives from an unknown organization (“tenant” in active directory terminology) you basically know nothing about the organization and the user. Anyone can register an active directory with email addresses that resemble a legitimate organization.

A common misconception is that an administrator of the user’s organization must be involved in order to integrate with an active directory. This is not the case. Anyone can make an application registration that can authenticate users from any active directory. (This used to be called “multi tenant applications”, but Microsoft seems to be smoothing out a lot of the difference between multi tenant and single tenant apps now). But the user will be asked if they consent to your app getting their name, email etc.

The full power of active directory can be unleashed for organizations where the administrator gets involved. If you make an app that e.g. Sopra Steria wants to use officially, an administrator at Sopra Steria can authorize your app to get user details without explicit individual consent and can also authorize your app to receive information about users’ roles and groups. And the administrator can require their users to use Multi-factor authentication for your app and even audit user logins from their organization to your app.

This means that your active directory application will have to deal with both unknown organizations, known organizations with default configuration and organization where an administrator at the organization have set up your app.

Active Directory gives considerable power out of the box and if you’re willing to deal with the complexity, you can get even more.

And all it requires from the developer is to integrate with the fully standard compliant OpenID Connect protocol. This is as easy for Java developers as for .NET developers.

Stay tuned for my upcoming articles about ID-porten and Slack as ID-providers.

Posted in English, Identity | Leave a comment

Dirty Code Monday!

Lately I’ve been thinking about how easy it is to fall into the trap of not challenging our ideas about the code we’re working on. In order to challenge the default mindset of Clean Code, I recently proposed to institute Dirty Code Monday (a proposal that sort of got me into a bit of a big discussion).

Anyway, here is the report from the first successful Dirty Code Monday one week ago:

An unpromising start: I had done a code review with “Programmer A”‘s code on Thursday where “Programmer H” and I had pretty much rewritten all of it. Now we had to go through the results together. We all admitted that code review is not ideal for a Dirty Code Monday, but rules are rules.

The first bit of code we came across was this:

Notice the comment? // TODO: Find out if SSLContext.getSocketFactory is expensive an if so, cache. I sighed. “We really have to remember not to do premature optimization, or we’ll never find out if it is really slow or not.” “Programmer A” responded “What? I thought you said this was Dirty Code Monday! Let’s just do it!” And so we did. We cached the result of createSocketFactory in a static variable. Dirty Code Monday!

By now, I was starting to get my spirits up that we could actually pull this off. We glanced up at the on-wall monitor: Someone had broken the build. “Sorry,” said ‘Programmer K’, “I forgot that my commit also changed the backend.” ‘Programmer R’ chimed in: “Yay! Your turn to get cake, K”. “Not today,” said A, “Dirty Code Monday!”

‘Project manager K’ just mumbles “The cake is a lie”.

I continued the code review with A. Next up was this beauty:

“Hmm…” I said, “I guess that really should deal with DELETE and PUT requests, too. But it’s Dirty Code Monday.” We discussed a little and A mused “a switch-case could work here”. “Ugh! I say, I don’t like switch-statements. They kinda violate the OCP. Maybe. Maybe not here. But I still don’t like it.” He just looked at me and we both laughed.

“Ooooh,” I said. “Look at that repetition of the complicated stream() expression. Perfect!” ‘Programmer A’ was pleased as well “Dirty Code Monday is pretty okay.”

Perhaps you think our code wasn’t that dirty. I’m actually not that embarrassed about it. But changing our perspective helped us see other ways of working with the code than we were used to. Having a phrase like “Dirty Code Monday” was a fun thing for the team to talk about. I’d like to try it again today.

Happy Dirty Code Monday, everybody!

PS: The code in this article is actual production code. The whole team has approved the quotes attributed to them

Posted in Code, English, Java, Pair programming | Leave a comment

A canonical XML test

I recently did a few days of TDD training for a client. They asked me to help them test and refactor a class that created XML from an internal domain model. This gave me the opportunity to examine a bigger pattern.

I wondered where the domain model came from. Looking through the code base, I found that the same or similar data structures were dealt with many places. As often is the case, I also found a bit of code that parsed an XML structure and output the domain model. This made it possible to use my favorite way of testing mapping code: Round-tripping.

The general pattern: To test translation code, you can test the encoding and decoding as one. These tests will often give you a lot of bang for your buck, both in terms of readability and in terms of error detection rates. Their main limitation is that they may not work to exercise all paths of the code well. If this is a problem, you should supplement them with more fine-grained test.

As I have dealt with this sort of problem a few times before, I’ve decided to create my own XML library, Eaxy (as you do). I introduced the library in the tests, but the production code remained using a combination of DOM and JAXB. Here’s a reasonable reproduction of the test:

When I introduced this test to the existing code base, we discovered a few interesting things: 1. There were internal dependencies in the XML file that the developers were unaware of as all the canned test data consisted of huge files that nobody would read. 2. A field was decoded from base64, but treated internally as if it was still encoded, leading to doubly encoding it in the output. 3. The output structure was slightly different from the input structure.

The test, combined with coverage measurements, gave us enough confidence to refactor some pretty crufty code that the team relies on in the future. Round-trip testing can give you a lot of bang for your buck.

Posted in English, Java, Unit testing | Leave a comment

How to write better code

My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic.

First learn to collaborate

The most important skill we should teach is how to work well with others on a shared code base. In my career, it took me many years before I started getting good at this, but it had the most impact on my effectiveness. So this is where I want to start with developers who are getting ready to join the work force. On almost all projects we work on, our success will depend on others.

Working with others can be taught. Here are some techniques that have worked for me:

  • Pair programming. Good pair programming requires training, but there exists training styles like coding dojos and code retreats. Some of the best programming instructors in the world use pair programming actively as part of their training.
  • Code reviews. I work so much with pair programming that I personally give code reviews a lower priority. But many teams find great value in them.
  • Patience. When working with pair programming, it’s easy to get stuck in arguments. Our profession says almost nothing about interpersonal skills, yet we depend on them all the time. Try this: When pair programming and you see your pair making a mistake, wait to see if she spots it herself before breaking in.
  • Humility. I often get asked “how do I convince others to write clean code”. Of course, the question assumes that you’re right and they are wrong. Most of us are absolutely rubbish at the skill of changing our minds. When pair programming, if your pair want do something you think is wrong, try indulging them. At worst, you get the chance to teach them something. At best, you learn something yourself.

Unless you are in a situation where you write all the code yourself, collaboration skills are paramount. It doesn’t matter if you “know” what the code should look like if you can’t agree with your team.

Now, let’s talk about code!

If you are one of the people who skipped ahead to this section, please go back and read about collaboration. Seriously. Nothing I say about code will help you if you can’t work well with others.

Go ahead, read it again. I’ll wait here.

Good to see you back! Now let’s talk about learning to write good code. Of course good code is crucial to professional success. If the code base is better, you spend less time fixing bugs, you have an easier time changing the code in the future and your team will have a better time working with you. This is understood.

Learning to write good code is quite simple: You have to read code, you have to write code, you have to change code, you have to observe what is easy and what’s hard, and you have to delete code and start over again.

For the first of these points, great books help you to read code: Clean Code, Implementation Patterns, Refactoring, the Art of Agile, the Pragmatic Programmer, Practices of an Agile Developer, Design Patterns. I’ve enjoyed reading all these books immensely. These books will teach you considerations such as low coupling, high cohesion and simple design. They will teach you useful principles like Single Responsibility Principle and the Open-Closed Principle (although I find I almost never refer to the rest of SOLID). The patterns and principles teaches you words to discuss code with your team.

For the second of these points, Test-Driven Development is one great way to learn how to write code. I enjoy doing coding katas myself and often use them for teaching. But the most valuable skill when writing code is one I learned at code retreats (thank you, Corey Haines!). Learn to delete code you write. I don’t just mean refactor it to be smaller. I mean that for coding exercises, highlight all the files and press the delete button. I mean for production code, after spending a few hours working on a task, (occasionally) git reset --hard HEAD.

The hallmark of great code is how easy it is to change. Can you navigate in the code? Can you spot errors quickly? Do you know where to make a specific change? You can learn by reading about principles, but the most safe teacher is to expose yourself to more experience. (I’m planning to write a blog post on how principles sometimes, but not always coincide with good code). When you write and change code, reflect on how limitations of the code and your current skillset impedes the changes you want to make.

In short: Code more, listen to the code and listen to your peers.

Can you release smoothly

I almost forgot the #1 quality of good code: It has to be used! Release cycles of teams can vary from several times per day until a few times per year. If you can release your code at will, you can learn both about your code and your users. When the whole team learns that you will release again tomorrow, or next week, priorities of “now or later” gets easy. When you release only a few times a year, people get stressed and discussions get heated.

I’ve almost always find that team under-appreciate the value of spending time on build and deployment tools and scripts.

“Don’t do stupid stuff on purpose”

If you find code you’re unhappy with, it bears remembering that it is that way because it got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because of pressure to finish, because they wanted to go home to their family instead of sitting late in the office or maybe they just had a difference in opinion on what’s good code.

Not everyone agrees with this, “what about those who just don’t care?” After 20 years of working as a programmer, I have never encountered anyone who just didn’t care. I have encountered programmers who had different preferences from my own, I’ve encountered programmers who are delivering under short deadlines, I’ve encountered programmers who get praised for making appearant progress at the expense of writing good code. And I’ve encountered many programmers who don’t care as much as me about the code. Having other interests in our life is an excellent reason to spend less time polishing code.

But I’ve never encountered a programmer who just doesn’t care. Have you? I’d love to learn from your story.

Posted in Code, English, Pair programming | Leave a comment

Forget about Clean Code, let’s embrace Compassionate Code

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others.

Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies. I often leave the office 1-2 hours later than my co-workers after polishing some piece of ultimately meaningless code. This is time I don’t spend with my family. Because I’ve learned to care about Clean Code.

Some of the most unpleasant experience in my professional life have been due to disagreements of the Clean way to write some piece of Code. I know people that I respect professionally that could have been good friends if one of us hadn’t insisted on purity of code in some situation or another.

And I’m not alone. I’ve seen teams that are at conflict with each other because of different expectations of a programmers obligations. Often fuelled by the idea of Clean Code.

As I’ve grown older, I learned to stop getting upset about “Unclean” Code. In any real world code base there will be an uncountable number of unfortunate quirks, odd and ends. This is okay. Things are the way they are because they got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because they wanted to go home to their family instead of sitting late in the office or if they just had a difference in opinion on what’s good code.

I sometimes train teams in TDD, incremental design, refactoring and pair programming. I almost always have to spend a lot of time helping the team bridge their disagreements in a more constructive way. And often the ones who have read Clean Code are the most susceptible to this sort of conflicts.

Why do I bring this up now? Because the reason that the idea of Clean Code is unhelpful as a guiding principle came in stark relief last weekend. The reason is simply this: We get led astray when we follow a principle or a rule without reflecting on what it does to ourselves and others. Robert (Uncle Bob) Martin is the author of the Clean Code book and a prominent developer trainer. He often writes on obligations, the oath to defend and preserve the honor of the profession, and shames excuses for not doing TDD. For a long time, there has been a nagging feeling at the back of my head about this language of “honor”, “obligation” and “professionalism”. But I enjoy test-driven development, and I have experienced it as a more fun way to develop. I believe that developers should reject illegal orders. I agree with Uncle Bob on all of these specific points.

Only when he writes something that I strongly disagree with, does the hunch about Clean Code became clear. The last days on Twitter we watched Uncle Bob implicitly decry the violation of Godwin’s law rather than the internment of thousand children under conditions that Amnesty International compare with torture. In the following days, Uncle Bob fought back against his critics also stressing that he thinks the situation is horrible, “but…” not as important as “unhonorably” comparing others to Nazis. I think his priorities are horribly wrong. I responded “In light of @unclebobmartin’s recent tweets, ideas like Clean Code have started creating a bad taste in my mouth. Let’s just say “code”, eh? I’m officially instituting “dirty code Monday’s” to remember to question dogma, tribalism and things-before-people mentality.” Bob asked me to explain “why you decided to lead a boycott against the concept of Clean Code”. Thus this blog post.

I deeply disagree with his stance on this political issue. I respect that some people value rules and principles higher than individual fates. I do not value rules for themselves. Bringing this back to code: I don’t believe we should use TDD because it’s a professional obligation. Instead I use TDD when it makes my work more enjoyable. I don’t think we should refactor our code because it violates a SOLID-principle. Instead I sometimes reach to a principle to understand why some piece of code is hard to change or understand. I don’t want to shame people for writing Unclean Code. Instead I believe in having an honest dialog among equals about how we want our code to look. I don’t believe that professionalism should compel us to introduce tests for all untested code. Instead I believe we should prioritize which deficiencies we fix and which code monsters we allow to live out their lives in their part of the code base.

I want to accept my unclean code as battle scars to be proud of and to be humble about, not as failings to be ashamed of.

My friend Thorbjørn Sigberg writes If your agile transformation has only one goal, it should be “Do less boring stuff”. When Clean Code becomes a source of less boring work, I’m for it. When it becomes a source of frustration and guilt, I’m against it.

For me, the ideas of Extreme Programming that bring the greatest joy to my professional life and that of my team are ideas about the whole team, about pair programming and about focusing on the users. Uncle Bob acknowledges these elements of the programming practice, but hardly ever talk about how to do it well. I don’t agree with these priorities.

As Uncle Bob nominated me as leader of “the boycott of clean code”, I guess I should try to end with something profound. How about this: Your most valuable skill is to know what’s important. Code is not important. Principles are not important. Rules are not important. People are important. That means your users, your team, your family, yourself. To quote Joshua Kerievsky’s Modern Agile: Make people Awesome. Clean Code may help or hurt that goal. Learn to see the difference.

Posted in English, Extreme Programming, Non-technical | Leave a comment

A wicked Java trick to make the JVM forget to check exceptions

I’ve long time been a critic of the mechanism of compiler checked exceptions in Java. Whether you love them or hate then, one thing is sure: There’s situations where you don’t want to have to deal with them. The solution in Java is to wrap a checked exception in new RuntimeException(e) but this gives long stack traces without adding useful information. Sometimes, we just want to tell the compiler to chill.

As it turns out this is possible, through some wicked abuse of the type erasure misfeature of Java-generics. Seeing this in action is instructive for understanding the inner workings for Java. Let’s go!

Here is what we want:

Notice that the businessLogic() neither catches IOException or declares that it throws IOException. Instead, the softenException() method removes the checkedness of the exception. When we run it, we get the following stack trace:

Huh! The exception being thrown in the main method is a NoSuchFileException, which is a subclass of IOException – a checked exception! How can that be? Why didn’t any of the methods in the program have to declare throws IOException?

Here’s the trick:

The checkednessRemover method uses a trick that reveals a few things about the inner workings of Java. First, the generic type argument T is bound to RuntimeException in order to fulfill the contract of softenException. This means that the expression throws T becomes throws RuntimeException, which the compiler interprets as if there was no exceptions thrown.

But the statement throw (T)e; theoretically should evaluate to throw (RuntimeException)e;. Since e is a NoSuchFileException, you would expect this statement to result in a ClassCastException. But the way generics work in Java, the type information is removed by the compiler. So instead, the bytecode reads as throw (Exception)e;, which is fine.

So this strange trick shows that the Java compiler removes generic information from the compiled code and that checked exceptions is purely a feature of the compiler. There are no runtime verifications of checked exceptions.

Would I recommend using this trick in production code? I don’t know. It’s pretty weird and may not be that useful, but I do use it myself when I’m feeling wicked. If nothing else, I hope learning about has given you some insights into the inner workings of Java.

Disclaimers: (1) I read about this trick somewhere else, but I cannot find the source any longer. I thought it was Heinz Kabutz’ excellent Java Specialist newsletter, but I can’t find the source. (2) This is also implemented in Project Lombok as @SneakyThrows. If you are using Lombok, you should under no circumstance reimplement the trick from this blog. Use @SneakyThrows instead.

Posted in Code, English, Java | 3 Comments

The same risks in every projects

To avoid the big problems with projects, everybody recommends risk management. At the same time, I’ve rarely seen risk management practiced effectively. Do we identify the same risks and do we actually prepare to handle them? The ironic thing is that I think most projects have the same top four risks. In this blogpost, I explore these common risks. To avoid exposing my customers and colleagues, the examples given is based on hearsay and not actual experience.

The biggest risk: Is the problem even worth solving?

The biggest risk of a project is that the problem we’re trying to solve is not worth solving. The project may have uncertain costs and will only save the company an insignificant amount of money, or we may be creating a product that nobody is interested in paying for. If what we’re doing is not worth doing, it doesn’t matter how well we’re doing it.

Lean startup recognizes this risk at the center of the process. This is why the Minimum Viable Product is such a strong concept. This is a great idea if the project is about developing a product for a market.

What if the project is about delivering something that a customer ordered? What if your customer ordered something that they don’t need? Your contract may protect you financially, but you will still have wasted your time working on something insignificant.

As an example: Everyone wants to develop chatbots today, but do you know how much you are currently spending on your human customer services representatives? Is it even worth reducing this cost?

Will the proposed solutions solve the problem in a reasonable way?

Even if we know the problem is real, will our solution actually address it? In the example of the chatbot, we expect that our customers will get their answers from the chatbot, so they won’t bother our (expensive) human operators. But what if our customers always end up transferring to a human after all? Many chatbots are nothing more than fancy, less usable, FAQ databases, which may be cheaper to implement anyway.

Do we have the means to execute our solution?

Even if the solution would solve the problem if properly used, do we have the skills, data, customer relationships and market conditions to execute it well and without extreme expenses? In the case of our chatbot, the chatbot won’t do us any good unless we have the people who can train it and the data to train it with. As technologies are becoming increasingly specialized, it’s often much less available skills than demand.

Do we have the processes to deal with fundamental risks?

When a fundamental risk materializes on a project that has been started, it may be very hard to actually deal with it. We had a project at my company where it turned out that after putting in a few person-years worth of effort, we realized that there was no value to the project. It took us two weeks from the realization until we had discussed the discovery sufficiently that everyone saw the same situation and that we had described the situation in a way that made the top management able to make an informed decision to terminate the project and cut our losses.

We’re not always so lucky. In many organizations, the inertia of a project is so large that there is no understood decision process that makes us able to terminate the project once we realize it’s a waste of effort.

Dealing with the fundamental risks

The three biggest risks to the value of any undertaking are:

  1. The problem may not actually be worth solving
  2. The solutions we select may not actually solve the problem
  3. We may be unable to actually master the solution effectively
  4. We may be unable to terminate out-of-control projects

If one or both of the first two risks actually materialize for your project, your current undertaking is a waste of effort. If the third occurs, it costs more than it’s worth. If the last occurs, you will be unable to stop the bleeding. All projects have these risks, but they may materialize differently. What are your fundamental project risks?

Posted in English, Non-technical | Leave a comment

Privacy concerns everywhere, but don’t panic!

Recently, my organization reached a big goal and we decided to celebrate by taking everyone out for dinner. What happened was a GDPR nightmare. Or was it?

We sent out a Google Form with three simple questions: 1. What’s your name, 2. Are you coming to the dinner? 3. Do you have any dietary constraints?

But wait!

According to article 4 of the GDPR, “‘personal data’ means any information relating to an identified or identifiable natural person”. Is the dietary constraints personal data? It certainly can be!

Julie wrote: “I’m a vegetarian”. That’s certainly personal information. Is it lawful to collect it? Jason wrote: “I’m allergic to shellfish”. That’s actually medical information. Fareed wrote: “I don’t eat pork”. Did we just collect data about his religious belief? Both medical information and religious beliefs are considered special categories of personal data, requiring stricter basis for processing.

But it gets worse: Google Forms doesn’t guarantee that the data is stored outside the US. As long as the US is a rogue nation, especially when it comes to privacy, article 45 will probably never allow for worryless transfer to the US. And I have to admit that when it comes to transfer to rogue nations, I really don’t know what to do.

So, what the heck, right? What’s going on here? Is the GDPR making everything impossible?

Not at all, we just have to start thinking in terms of common curtesy in a time when massive amounts of personal data is in danger of being misused. Let’s fix these problems!

The biggest problem is Google, and we’re all holding our breath on this one. Is Google going to provide sufficient control to comply with the GDPR after May 25th? We all hope so. If not, perhaps we need to find another place to collect the data. (Hey, Google! Norway is a great place for data centers – why don’t you leave the sinking ship that is the US?)

Second, collecting the data is lawful if we get the of the data subject. Just add a checkbox saying “I consent that this information is used to pre-order the food”. We also have to provide transparent information to our hungry team members. “This information will be aggregated with the rest of the responses and used to place our order. It will only be read by Johannes. After the order is placed, the information will be deleted”. Remember to restrict access to the data as you promise and delete the data when you promise.

Yes, this means that you have to ask again for the next party. Don’t cry – that’s not that big of a hassle.

Finally, and most importantly, perhaps we should take a lesson from Data protection by design. Instead of asking if our members have dietary constraints, perhaps just ask the restaurant for the menu and ask everyone what they would like to order. A food order is (probably!) not personal data and then we sidestep the whole problem. Or we could just anonymize the dietary question.

What’s the point of this story?

Data protection is an everyday problem. It doesn’t just affect big IT systems. It affects all the small information streams within an organization.

But at the same time, data protection doesn’t require a project to carry out. It just requires you to follow a reasonable set of principles. It means you have to think about whether you have the consent of the person subject, whether you’re upfront about how the data will be used, whether you protect the data and that you consider whether you need personal information at all.

A huge disclaimer: I’m not a legal expert in any sense of the word. I may be grossly wrong in this article and I’d love to hear about it! Please comment!

Posted in English, Non-technical | 2 Comments