Tuesday 14 April 2015

IP Addresses Are Not Smoking Guns

I am concerned by the recent landmark case by "Dallas Buyers Club" where details of iiNet customers who allegedly downloaded their movie will be disclosed.

There has been a lot of discussion in the media about the case, but I haven't seen any that look into the issue with any level of detail. From their perspective, it is an open and shut case. That is, once the names and address are handed over the game is up. I don't think it is, but before I can draw any conclusions, I need to explain how the technology works.

Whenever someone downloads via bit-torrent, they need a '.torrent' file that describes the files for download. The bit-torrent client software understands this file and obtains a list of IP addresses that are seeders and peers. A seeder is a computer that is able to send you part of the download (in this case, the movie file you think is Dallas Buyers Club). A peer is a computer wanting to download part of the file.

You can see how this technology is far from clandestine: each computer needs to know the entire list of other computers' IP addresses so it can either send or receive part of the download. Movie companies can pretend to be a downloader and watch all the IPs that connect. In this case they grouped together the 5000 odd IPs that iiNet own and put forward a case to find out the identities.

IP addresses are, by themselves, not that helpful in identifying someone. They are allocated to companies in 'blocks' - and the large ISPs have 100's of 1000's of addresses. You can determine who 'owns' your IP address (go to www.whatismyip.com for example). Lawyers representing Dallas Buyers Club did precisely that, using the seeders and peers IP addresses.

In the past, iiNet argued they shouldn't have to divulge this information and they protected their clients. Now that the courts are forcing them to comply, how do they link an IP with customer information?

ISPs like iiNet charge customers on usage - e.g. number of Megabytes per month. To measure usage, they need to map IP addresses to usernames/accounts. This is the mechanism that lawyers can get names and addresses.

IP Address (1.2.3.4) ---> iiNet ---> Your Account

Whenever you log in, ISPs like iiNet assign your broadband connection an IP. Sometimes it's always the same (called static) and other times, it's from a pool of available remaining IPs (called dynamic). This means that your connection has an IP address, not your computer.

If you are like most households, you have more than one device that connects to the internet. You only have one IP address though. This is the first issue - iiNet cannot tell what specific computer did the download. This is the equal of charging the head of the household for a murder just because it was at their house - based on no more information.

The second, less spoken about issue, is iiNet cannot tell the exact location of where the connection was. Most iiNet customers could use one-another's account by changing their username and password. The IP is assigned to the account, not the location. This is a massive leap of faith - just because a gun you own is registered to your address, doesn't mean any crime committed with it was at your house.

The third issue is most home routers have Wifi so their phones can connect without being plugged in. This means people could, without permission, connect and use your internet connection. Are you liable for someone breaking into your house, taking your knife and committing a crime with it?

In conclusion, while this landmark case is disappointing, I cannot see why anyone would pay up. The onus is on accuser- I realise it's a civil, not criminal, case so the bar is lower, but yet there are that many holes in the approach it's hard to imagine it making any difference. They would need to seize computers and find the files to be able to do that. You can subvert this by encrypting your hard-drive (ensuring your computer is off when they seize it) or destroying the hard-drive before the seizure.

I am not advocating for piracy, but I am of pointing out the flaws in the technical approach of drawing a conclusion of guilt based on an IP address. I am also not a lawyer- take these comments like you would of someone pretending to know what they are talking about.

Sunday 12 April 2015

Monolithic Applications - Why Understanding The Business Matters

I've been thinking a lot about how to make a monolithic application useful in the long term. I subscribed to the view that systems have a usable life and once they are at the end you get rid of them. It's a reasonable perspective that still has merit. That is, until you get into the real world. There is no reason to believe that the lessons you learnt from the system about to be thrown out won't repeat. Or worse: you end up with 2 dud systems and no way forward. Many decisions were made in good faith, often with the idea that the team would go back and clean the mess up.

Many of you have experienced this story first hand: a business adds more and more to an application and at the same time cuts corners. The business ends up with what they want right now, but not what they want in the future. It becomes complicated to manage, new versions take longer to come out and if key developers leave it becomes a slippery slope. People begin the ask the question: are we getting value out of this system?

It's a great question to ask. A fundamental question. Every business should ask it even if they think the answer is yes. Once they ask the question raise a mirror at the business - the system is reflecting the business. Sounds like a cop out? It is, but that is the problem. More often than not, organisations schedule their development work via a steering committee. This committee rarely has more than one person on it who is technical. The asymmetry results in decisions without understanding the implications on the long-term value of the system. It is up to that single person to articulate abstract concepts and win time and effort to projects that don't appear to have any value.

So how do you get around it? You need to understand the business, but more important you need to understand where the business is heading. If you understand where the business wants to be in 12/24/36 months you can plan and win support for projects that supports the business in its goals. This means there needs to be openness between the head of IT and CEO.

By understanding the business I don't mean every single operational detail. I mean the "Operating Model" as defined in Enterprise Architecture. If you are staring at this and have no idea what that means then start searching. You already intuitively know what operating model your business is, but you may not be making decisions to support it.

Let's say that you are clear on the operating model of the business and the decisions you have made over the past year in development supported that model. Then you read an email by the CEO. About a restructure of various business units with the goal to increase cross-selling opportunities. A completely different operating model. And it's happening in three months.

This could just be bad luck. Perhaps you could have done nothing to foresee this restructure. That is unlikely. Often restructures and changes like this don't happen in a vacuum and there are many signs. This is where understanding the future of the business becomes critical. Businesses want systems to change quickly and you can give the illusion of it being quick if you start the changes early. Small, incremental changes - between other "now" projects.

So this is where we come a full circle. I have in the past blamed others for why systems are monolithic and bulky. I understand now that the responsibility of heads of IT is not to just manage projects or lead teams. They must know the business model to the degree where they can make suggestions of a more optimal model. The previous example about the cross-selling opportunities is what a CIO should be recommending. This vision will be welcomed by the executive and projects scheduled to make it happen. The monolithic system can be undone.