Legal pitfalls for developers
Hon, Kuan
Coding can involve legal pitfalls for developers' employers or hirers, and even for developers personally. For example, the proposed EU General Data Protection Regulation would introduce requirements for data protection "by design and by default", including security by design/default, and the concept of "privacy engineering" is rapidly gaining traction. After discussing the role of law and contract terms (including international/global aspects), this session will outline some main points to watch out for in relation to intellectual property rights to software and data "ownership". Then it will move on to its main focus, namely key legal issues for developers regarding data protection/privacy, particularly in the context of websites, mobile apps, cloud and IoT. However, many compliance issues can also give rise to business opportunities. Some free resources for technology law advice/information will also be discussed.
 I'm Kwan Hon, and welcome to Legal Pitfalls for Developers. This is me, four hats, four clouds, and two weasels. I have several hats. I am a lawyer, but I've also got a degree in Computing Science. The other two hats are that I'm a practitioner. I'm a consultant lawyer to a law firm, Pinsen-Masons, but also I'm an academic. I'm a researcher at Queen Mary University of London. I've worked on four cloud law projects, including the Microsoft Cloud Computing Research Centre, which is a collaboration with computer scientists at the Cambridge Computer Lab. I have been the primary author of eight out of the 14 chapters in this cloud computing law book by OUP. The two weasels are that what I say represents my own opinion and not necessarily that of any organisation I'm associated with, and the second weasel is that this is just general information, not legal advice. So the purpose really is to raise awareness of some issues. There's no time to go through everything in detail. It's just so that you're aware of some of the issues you might be coming across. So first, I'm going to talk about law in dealing with lawyers and then some key pitfalls with intellectual property. My main focus is going to be data protection, legal issues, and if there's time for questions at the end, we'll have that otherwise please catch me during a break. Now, as developers with software, these are the main areas I'm going to cover. There could be more, of course, but the main areas are you create software, you use your software, you might allow other people to use your software on certain terms. So in terms of laws and lawyers, I'm just going to go through the laws and what they are, even though it might seem fairly obvious. Laws are just rules that are enforced by the government and backed by the government. So the rules could come from legislation or legal codes. They could be created by judges in common, what's known as common law systems like England and North America, rather than civil law systems which rely more on legal codes and less on the judges. The enforcement systems can include courts, regulators with sanctions such as jails and fines, damages, injunctions, stopping people from doing something or making them do something. Now, the role of contract is very important in law and basically a contract is just an agreement between parties who's going to do what, what happens if they do or if they don't, etc. which the state is willing to enforce. It's just a state backed agreement, but it's important. It's really important to note that each country has laws on the validity of contracts. So just because Alice and Bob agree something doesn't mean it's going to be contract. They're criteria which have to be fulfilled before the law will recognize it as a valid contract that it will enforce. And furthermore, even if the overall contract is valid, there might be some part of it that laws are going to say are not valid, they won't enforce it, they're not legal. For example, there are a lot of laws about protecting consumers against unfair contract terms. So certain terms might be considered unenforceable as against consumers. Even the contract overall is a valid contract. In terms of what, well, I like illiteration, so I phrased it as dues, deals, disputes and decrees. So dues, your rights, what's due to you? IP rights, other rights, there's obviously lots of actors that can be involved, deals, your contracts. Disputes, what happens if things go wrong and decrees or dictates, compliance requirements on you where you have to comply with, for example, requirements on notifying breaches. In terms of the what, there are multiple laws that can apply. So in one situation, you can't just say, oh, well, one law applies to this situation. There are many laws that could apply, including the laws of different states. So different countries' laws could apply to the same situation at the same time. And the way I think of it is for each law, you think about multiple boxes. There's a box for the scope of the law in what circumstances it'll apply. There's a box for exceptions to the law in what circumstances that it not apply. What are the consequences if that law does apply, et cetera? And then you have to look at each box and say, for this particular situation, is it going to fit in that box? And bear in mind that in law, the boundaries for these boxes are fuzzy. And they change. They can get bigger. They can get smaller, et cetera. So that is what makes it difficult. You can have multiple boxes and the boundaries are fuzzy. And then you have to repeat this for every law that might be relevant. It is also particularly difficult because laws are behind technology, for example, copyright law. So basically, this is what lawyers have to deal with. So multiple overlapping boxes where the boundaries are fuzzy and they can change. They can get bigger or smaller. New boxes might be added or taken away. They can change around. And that's why some lawyers get the big box because they have to deal with these sort of complexities. Now, why do you care? Obviously, it's your rights. It's your remedies. But it's also your risk management. You have to manage your legal risk. And the issues for you may be different compared with the issues for your employer or higher. Sometimes you might have opposing interests. So bear in mind they might be different. I'm mostly going to be talking about the issues for your organizations. So managing legal risk, I think of it as a risk pyramid because legal risk affects reputational issues which can affect public trust. And the reality, though, is that organizations don't necessarily comply for the sake of compliance because legal risk is part of the overall business risk. So there might be strategic issues or commercial issues, revenues. Is it practical to comply with particular laws? And organizations balance that against the risks of detection of a breach and forcing the law, one of the sanctions, if it's enforced. So I'm not advocating or advising that you do not comply with laws. No lawyer can do that. But basically, it is up to the organization to make its own decision. And sometimes there are hard choices. An example, not of hard choices but of noncompliance, might be media organizations who deliberately invade the privacy of celebrities to try and get more traffic, sell more newspapers, whatever. And they take the chance that they might get caught and get fined. So another reason why it is important to talk to lawyers is that laws are not necessarily logical. Just because something is logical doesn't mean it's legal. Just because something is illogical doesn't mean you don't have to do it. Sometimes the law requires you to do things which are actually not very logical or not very sensible. And a very important issue, which I don't think many people realize, is that laws don't necessarily mean what they say. You could read a statute, you could read a case from a judge, and you think, oh, yes, this is what it says. But actually, words may have different meanings from what it says on the page because the law says so. The legislation actually defines something particularly. Or a judge has interpreted certain words just to mean something other than what it actually says. So that's a very important point. And also, laws are not always technology neutral. It seems that actually, laws are enforced more harshly against things digital, like with copyright law or website vandalism, than with things in the non-digital world. So the point about using lawyers is that lawyers know about all these peculiarities and idiosyncrasies. They can translate them into practical advice. And of course, you could rely on the insurance policy, perhaps. If they get it wrong, they advise you wrong, you might be able to sue them. Because if you do it yourself and you get it wrong, you're kind of stuck with that. In terms of how, obviously, it always helps to give lawyers lots of money. But really, it's communication and information. That's what's important. And when you're communicating with lawyers, bear in mind that there are different mindsets between technologists and lawyers. So technologists tend to think in binary, in black and white. But lawyers tend to think in analog, in shades of gray. So it is quite, you have to bear this in mind when you're communicating with lawyers, the different mindsets. As far as lawyers are concerned, there isn't such a thing as certainty. That is why lawyers always say it depends. Because it does depend on interpretation, on context, the individual situation, and things are much more a matter of probability than of certainty in law. So in terms of information that you give to your lawyers, you've got to make sure, particularly for deals and projects, you communicate what you're trying to achieve, exactly what you're trying to do, exactly what sort of data you're trying to handle, and how you have to explain the technical model and the business model properly. And it has to be a proper two-way communication. And an important factor, again, to bear in mind when you're communicating with lawyers, is that there is an issue of jargon or terminology. Often, lawyers and technologists can use the same words to mean different things or different words to mean the same things. And then you're going like that instead of like this. And examples I like to use are, from the cloud context, SLAs. Most people here would probably think SLAs means the contract. But actually, to lawyers, SLAs is just one subset of the contract. It's just the service levels bit, not the rest of it, like liability, choice of law, et cetera. And this is a consumer, I mean, NIST says a cloud consumer, whereas to lawyers, that would be the cloud customer. Consumer is the individual end user. Now of course, it is quite difficult because with laws, every country has their own law. The internet is global, but laws are local. So this can cause a lot of problems in this century. And the thing is, even with regional laws like EU directives, EU legislation, et cetera, actually there are differences within individual countries. And then we have things like federal systems, for example, in the US states, Germany with its states, then that makes it even more complicated because they could be different. So you have multiple different jurisdictions to consider, and you have to think about which individual countries or states are relevant to your particular situation. You might think, OK, well, let's put it in the contract to say the laws of England and Wales are going to cover the situation. I want the courts of England to deal with any disputes. But actually, again, like I was saying before, there is an issue of validity. Some contractual clauses may not be valid. So you might say you want, the parties might say we want this law to apply, but the courts will say no, it doesn't. For example, in France, a man sued Facebook, Facebook said it's California law that applies, and the court said no, that's not valid. You can hear the case here in France. So there are mandatory rules in lots of countries which apply here. And there's also another important point, I think, in practice, which is the difference between claimed jurisdiction and effective jurisdiction. So a country might say there is a ban on wearing T-shirts at conferences. But if it's a country on the other side of the world and you're not in there, then they can claim that all they like, but they can't actually apply it to you. And they don't have effective jurisdiction over you. So in terms of countries that are relevant, the factors, I think if this is a target test, it's not a particular rule, it's just the way I put it as a target test. So what's your target market? Which countries are you targeting? That's where you have to be concerned about their laws. Where are you a target? Which countries could target you because they have effective jurisdiction over you because you have physical assets there, people or operations, et cetera. Take for example the EU internet gambling CEOs. They were in transit in the US. And then the moment they were in transit in London and US soil, they were arrested because they had a physical presence there. And the physical connection is very important in lots of laws. Other connections are possible such as an organization being incorporated in a particular country, for example. So it is important to listen to your lawyer's advice, communicate with them properly about where the relevant countries might be and see what they say about which are the most important countries to consider. There's also a question of impossibility, particularly with multinationals. Sometimes if you try to comply with the law of country A, you're breaching the law of country B, and then you have to decide which law to break. So that's a really difficult situation. You do need to talk to your lawyers as soon as possible. It is the false economy to wait. I've done research on cloud contracts and the negotiation of cloud contracts. And I've had in-house lawyers saying to me, look, they are thrown a contract and told, it's going live next week. Just have a quick look and you'll see if there's any legal issues. And that's too late for them to do anything about it if there are going to be legal problems for your company from the contract. So please do remember to involve your legal teams at an early stage. Of course, you need to consult lawyers plus plus or lawyers sharp. You need lawyers who have subject matter expertise, expertise in technology law. You wouldn't want a GP or a bowel surgeon to operate on your brain. And similarly, you wouldn't want a high street practitioner or a general commercial lawyer to advise you on IT law. You also need to consult lawyers who have expertise in the relevant countries because all countries' laws are different. And you want to make sure you get somebody who's going to give you solutions and ways to do things rather than saying no, no, no to everything. So that's just a canter through lawyers. And now talking a bit about intellectual property. Intellectual property rights are property rights of intangible property. But again, they are just government backed rights to control or monopolize the use of intellectual property. And the main ones, I'm sure you've heard of are copyright, patents, database, right, trademarks, et cetera. And again, different countries have slightly different rules on intellectual property rights. When does the right arise? For example, with copyright, it arises automatically once the work is fixed, recorded, written down. Whereas with patents, you have to apply and get your application granted before you have that right. So the scope of the right may differ. The duration, how long you have that right, how is that property right transferred or licensed, et cetera. What acts are restricted? What's considered infringement of copyright? What are the exceptions that are allowed? What acts are allowed and not considered infringement? So of course, you'll all have heard a lot about licensing, permissions to use certain intellectual property. And there's an overlap between licenses and contracts, but they're not technically exactly the same. So for software, let's look at the creation part. Code, you're going to write code, you're going to be in some applications using other content like graphics or music. So who owns software? Well, with code, the main intellectual property rights that are relevant will be copyright and patent. I'm mainly going to talk about copyright because it's the main one. I mean, patents are less common. It is possible to patent software where it's part of a larger thing. You can't patent software as such. And in some countries, it's easier to patent software than others. But copyright is the main thing. So is there a difference if you're an employee or you're a contractor? If you are an employee of a company and you write code, who owns the code? Generally it's going to be your company, not you. If you're a contractor, you're hired to write code for another company. Actually, you will own the code. Even if they paid for it, they don't own the code. You own the code. So they've got to make sure that they do something, put something in the contract to ensure that actually you will assign the ownership of the code to them. So there is a big difference between employees and contractors. And with side projects, if you're an employee and you're doing a side project at your own time, who owns the code? You might find that your employer tries to say it owns the code. What about joint ownership when there's collaborations? If you've got lots of people involved as is common, then actually they might all own the code jointly. And the ownership may not be in proportion to the extent of the contribution. So really what you have to do is make sure that you've got a contract in place at the outset that deals with the things. For example, if you're going to be working for a company, but you know you're going to be doing side projects and you want to make sure you own the code, make sure you put that in the contract. Or if you want some code that you do in your work to be yours and not the companies, make sure that's in the contract at the start. And similarly for companies which are hiring contractors, if they want to make sure they own the code and not the contractor, they've got to make sure they put that in the contract at the start. So I put timing as a very important point. You have to do that at the start. It might be too late to do it afterwards. And again, bear in mind different jurisdictions have slightly different rules. So another aspect, if you are creating software, is could you be infringing other people's rights? For example, if you're using other people's code in your code, and bear in mind that just because code is publicly available doesn't mean that it's free from copyright. Public does not mean free to use. That's an important point under copyright law. Of course, there are also issues if you're using open source code. There could be lots and lots of talks on open source code alone. A small example is if you're using open source code, and you modify it, you're supposed to contribute your modifications back to the community. And there's this question about, well, okay, you take open source code, you modify it, and then you run it in the cloud, offer it as a service. You're not distributing it, so therefore you're not obliged to contribute it back to the community. And that's how the aphero license was born, to try and get around that. It doesn't actually work, but it's trying to do. And bear in mind that even APIs may be copyright. So in the EU, interestingly, again, regional differences, in the EU, the Court of Justice has said that you cannot copyright APIs. However, in the US, the judge initially who actually does some programming said, no, you can't copyright APIs, but then the appeals court said, yes, you can copyright APIs. And the Supreme Court has refused to hear the appeal, so we're kind of stuck with that in the US. So that underlines the point I said where every country, every region may have differences. And there are many ways in which you might risk infringing copyright, for example, not just copying, but modifying, distributing, communicating to the public, et cetera. And it's not just copyright that could be relevant. There are other IP rights like trademark, and there might be other legal rights like data protection. And of course, bear in mind, it's not just your code you have to think about, but anything else you incorporate in your app, like graphics, music, et cetera. There might be intellectual property issues with those that you have to think about. I wanted to say a bit about data ownership. I think it's a fallacy. People keep talking about who owns your data, it's your data, et cetera. Number ownership is just a government-backed rule. Ownership of intellectual property, even physical property, depends on laws. In medieval times, lords owned land, but serfs didn't strictly own land in that same sense. They couldn't. So it's all dependent on the laws as to ownership. So really, with data, you don't own data, you can control the use and dissemination of data through laws like intellectual property law, copyright, et cetera, and other laws might be relevant like confidential information, misuse of private information, et cetera. But practical control is also very important. And as for personal data, I will come to that. So really, with software, there are a number of issues. The main one that I want to concentrate on next is exploiting the software. If you want to make your software available for other people to use. And you might be concerned about your rights and liabilities in this context, which might depend on the channel of distribution. So the model is relevant. Are you licensing? Is it a contract? Are you going to... The method is important. Are you going to be using online terms and conditions? To what extent is that actually enforceable? And what about the channel? Are you going to go through cloud, through app stores, where there might be developer agreements that bind you, et cetera? What's your liability for things like bugs and security holes? What happens if people want to sell their software secondhand? And there's a lot of laws, particularly on protection of consumers. I just mentioned briefly one because it's quite new. Consumers Rights Act came in in the UK a few months ago. It's under a directive which is going to apply across the EU. And it applies to digital content, which is sold to consumers, not just apps or games, but even a website content. If you're delivering a website design, that could be digital content, a supply of digital content. Interestingly, there are fewer rights for the consumers where the service or the sale is for free or personal data rather than when it's paid for with money. And of course, if you're trying to sell your software as a service or on media, there are laws that you'll have to think about which are applying generally like on marketing, advertising, et cetera, what information must you put on your website for consumers, what do you have to put in your emails, et cetera? So not going to go into that. That's all general business stuff. Coming to the use of software internally, where you might be creating software and then using it internally to process personal data or other data and inputting, sorry, and getting output. Well, for developers, it's probably slightly less relevant when you're using software internally because it's mainly the person using the software who will have the risk, whether they're using software produced internally or software that they got from externally. For example, if they use software to process copyright third party material, then they will be at risk there. Or to process personal data, they have to comply with data protection laws. But there are issues like if software is used to process data, where did it come from? Is it properly sourced? Is it legally sourced? And with personal data processing, what happens if the software wasn't properly secure? So another point I want to mention is that the channel matters. The legal issues can actually depend on whether you're using cloud or not. If you've built a SaaS app on PaaS or IaaS, then actually the legal issues may be different from when you're just building an application and deploying and hosting it in your own data centers. Just some examples. For example, with copyright, which countries' laws apply may depend on where the work was recorded or created. So if you're using a server that's in a different country, then maybe the laws of that country may apply rather than your laws. With database rights, sorry, that should say database rather than data. But I've told you briefly about the EU database right. It's a special right created under EU law. Well, it's only an EU right. So again, if you're trying to create a database but you're using a server in the US, do you get an EU database right? So location does matter a lot with law, physical location of servers. Or similarly, if you're running patented software, some countries recognize software patents, some don't. So you're running a software which is actually under a patent. But if you run it in your own country, you might be okay. But if the server you're using it on is in the US or some other country where that software is patented, then maybe you'll be in trouble. So actually the location of your servers again does matter. And of course, with cloud, a lot of people are concerned that the cloud provider has access to your data and there might have to be contractual restrictions. So even if you're using internally the software or app you've created, but you're using a third party provider, PAS or IS, you have to be concerned about the contract with the provider. Normally, the contract is going to be on the provider's own standard terms and you don't have any choice about it. The scope for negotiation is very limited. But there are legal risks, especially with personal data. And I did some research on the negotiation of cloud contracts a few years ago. And the top three issues that came up were liability and disclaimers of the provider, for example, for data integrity or disaster recovery, service level agreements, and security and privacy. So again, another important reason to involve external lawyers early to deal with these issues. And of course, it's not just legal issues that are relevant, practical issues may also be important and they're related. For example, as regards the risk of lock-in or exit. OK, you might put in the contract that there has to be a minimum time period that you get to retrieve your data after the termination of the contract. But also, of course, it's important to test beforehand whether the data and how portable the data is, how can you get it out, how portable is your code, et cetera, to a different platform and to implement backups. If you are using a third-party cloud provider, PAS or IAS, to offer your own SaaS service to your own customers, then you've still got the same issues regarding your contract with the IAS or PAS provider as before. But you have even more issues because, of course, you have the risk of liability to your own customers and you've got your contract, your own customers that you have to think about. And there is a question mark about the viability of these back-to-back contracts with your own cloud provider, maybe with third-party data-centred providers, et cetera. Because if you have certain liability under your contract to your customers, but you can't actually get the same liability sort of back-to-back from your provider, then you are kind of pigging in the middle, you are exposed, but you can't actually claim back from your cloud provider. So again, it is very important to talk to your lawyers about this sort of thing. And now moving to the main area I want to focus on, which is data protection, there are lots of laws on data protection and privacy. Some of them may overlap, but basically there's a whole patchwork. You've got the ePrivacy directive, which is the source of the infamous cookie law. Same focus is the data protection directive, but things like the EU Charter of Fundamental Rights, Convention of Human Rights, cases which have evolved laws on misuse of private information, et cetera. And again, different countries may have different applications. This is an and, not all. I can't emphasize enough. It's not just one law that applies. Many, many laws from many countries could apply to your situation, particularly if it involves the internet. But this overlapping application and liability is important, because if something goes wrong, then whoever is trying to sue you may just pick all the laws they can and throw all of them at you and say, I'm going to sue you under this, under this, under this, under this. So all of them could apply, and they may all need to be considered. Now I want to talk a bit about the cookie law under the ePrivacy directive. It's not just about cookies. It's mainly this directive about communications privacy, such as breach notification requirements for telcos, and again, with national differences. This is, I don't know whether this is, you've seen this. It's fairly well known because there has been a lot of criticism of the cookie law and an organization called SightBeam put out some graphics. This is one of them showing how it doesn't actually necessarily help privacy, but has caused a lot of panic and a lot of money spent. The origins of the law, well-meaning privacy advocates and octogenarian lawmakers who couldn't use a mouse, probably something in that. And to be fair, you could say this doesn't just apply to the cookie law. It could apply to other laws as well. And beyond the EU, for example, in the US, there's been talk about the judges who have to rule in cases about mobile phones and about video games, but they don't even have mobile phones and so on. So there is an issue about lawmakers' understanding of technology, which is quite important because it affects the laws that affect us all. And of course, the fact that it might actually help very, very little people who benefit from a law that tells them a website uses cookies. And even Outlaw, which is a website associated with Princeton Masons, is a technology news website called the Cookie Law, breathtakingly stupid, but it is the law. And I just wanted to clear up some misconceptions about the cookie law because people call it the cookie law, but actually it's not just about cookies or even tracking cookies. It's broader than that. And it's not just about organizations or businesses. Individuals can be caught by the cookie law. It's not just about computers or browsers or websites, but other devices as well. And it's not just about personal data, unlike the Data Protection Directive. It's not just about storing data. It also includes access to data. And it's not just about things happening over the internet. A USB stick with software in it, which could read or access information, that could be caught by the cookie law. And the penalties, well, some people aren't worried about the penalties, but I think they're increasing in Spain. 4,000 euros for a jewelry retail chain. In the Netherlands, 25,000 euros. It was a public service broadcaster. EU regulators, generally, they did a cookie sweep in 2014. So as a result of that, France have actually been in contact with, I think, 20 companies saying you've got to comply with the cookie law. In Belgium, the Belgian Data Protection Authority sued Facebook in court under the cookie law and under data protection laws, and actually won. And you've probably heard about the 250,000 euros a day fine that they were imposing on Facebook before Facebook decided to change their systems. And there are exceptions where the cookie laws do not apply, but they're very, very narrow, like essential cookies, such as a shopping basket or a login cookie. They're very narrow. So really, the cookie law is about stopping storing information or accessing information on the terminal equipment, not just computer, of a user subscriber unless the user subscriber has been given information about what you're doing this for, why you're doing this, and they've consented. So it's not just about cookies and websites. It actually affects mobile apps, IoT, et cetera, et cetera. Maybe consent will be easy to get with an app, something with a signed up form, registration only sites. But there are lots of difficulties with this law, like who's responsible for complying? If you have a website and you use third party analytics or you use a social plug-in, is it you that's responsible for getting consent? Is it the analytics or social plug-in provider who's responsible for getting consent? Even Europa, this is the website of the European institutions, European Commission, Council, et cetera. They've got various pages talking about Google Analytics, but they're quite inconsistent in the way they talk about that. And it's quite interesting that Google, in the middle of last year, about AdSense, they actually, I think some of you might have come across these changes, they actually said, if you are a publisher using AdSense on your website, in your apps, it is your responsibility not theirs to get consent. Now whether that's right or not, difficult to say because if it's your responsibility, then you might, in order to say what the data is being used for, you might have to go into their code and figure out exactly what it's doing and what it's collecting, et cetera, et cetera. So this is quite difficult. So it's a major issue as to how you can comply. How do you get consent? For example, at the strictest extreme, you could have a mobile light box on a website, user can't do anything until they consent, but you pause the cookies so no cookies are set until they consent. Is implied consent sufficient? Is that, in some countries, it might be in others, it won't be. Now there's a lot of guidance that's been issued, including by the Article 29 Working Party, which is EU regulators, data protection regulators collectively, in the UK, the Information Commissioner. They use a tool called Civic Cookie Control, but different countries, there might be different issues. The Interactive Advertising Bureau has produced guidance last year. The Belgian Data Protection Authority, who I mentioned sued Facebook, they recommend social share privacy as a tool for pausing cookies before making sure they're not set until the user consents. Canil, which is the French Data Protection Authority, they use Peewick for analytics rather than Google Analytics because they think, again, that's better. And Europa, the European institutions website, they even have a cookie consent kit on there. So I've compiled some links to tools. It's slightly updated. I haven't a chance to update it properly, so you can have a look at Bitly Cookie Law links if you want. But a difficult and important point to note is actually you've got all these guidance out there, but just because you comply with it doesn't mean you're guaranteed to comply with the law because it may take a court to say exactly what the law means before you know you're compliant. A lot of people have been using banners, but in the Belgian Facebook case, the court said, I don't like the way they've used the banners. Not sure that's good enough. So it is quite difficult. You do need to take advice and you need to look at the practicalities as well. I mean, some of the guidance on cloud, which I haven't put there, but the regulations guidance on cloud is frankly, I think, impossible to comply with. So the Data Protection Directive, this was, this took five years to come through. It was proposed in 1990 and adopted in 1995. It's a directive, not a regulation, which means that it only takes effect as law in a particular country when that country passes national legislation to adopt it into law. And there are differences. For example, mainly what I like to say, with security. In the UK, the Data Protection Law has four lines on security. In Italy, it's about four pages, including stuff on access controls, et cetera, et cetera. So it can be quite different. And this law applies not just to the EU, but also the European Economic Area, EU plus Iceland, Liechtenstein and Norway. And currently there is a draft Data Protection Regulation, which is intended to modernize the laws, but I'll talk about that later. And for those who are interested in the difference between the EU and the EEA, I produce a Venn diagram, EFTR, et cetera, et cetera, bit.ly slash EU hyphen Venn for anybody interested. So this is not to scale, but this is just to show that data protection in the legal sense is not the same as data protection in the IT sense. In the IT sense, data protection might apply to data that's not personal data under the Data Protection Directive. Under the Data Protection Directive, data protection only applies to personal data, but there are technical and organizational security measures that have to be taken in relation to personal data. So there is an overlap, but it's not necessarily the same as IT data protection. And of course, the Data Protection Directive is relevant to lots of areas. Remember this is in addition to the cookie law, not instead of websites, mobile apps, cloud sharing data with third parties, et cetera. So the basic principle is that the Data Protection Directive regulates the processing of personal data with some exceptions such as household use. So your personal address book with the contact details of your friends and family, that's exempt because that's household personal use. Big hole, national security, law enforcement. So it's important to note that processing that's regulated under the Directive is not the same under the legal and IT sense. It's much broader than the IT sense. So in the IT sense, when you talk about processing data, you're talking about compute operations on data. But in the legal sense, when data protection laws talk about processing, it's not just operations on data, but it's also passively storing, holding data. It's transmitting, displaying data, et cetera. It's basically anything that you can do to or with digital data is going to be processing and caught by data protection laws. And data protection laws are supervised by data protection authorities such as the ICO in the UK. It is considered a human right. Data protection is considered a human right in the EU, and so non-EU citizens can also be protected under data protection laws. Now the concept of personal data is central to the application of data protection laws. It is what I call binary and application analog in determination. And what I mean by that is that if something is personal data, then data protection laws apply to it. If it's not personal data, if it's anonymous data or anonymized data, then you don't have to worry about data protection laws. You can ignore them. So that's the binary bit. The analog bit, the shades of gray, is that it's actually quite difficult to decide is this bit of information personal data or not. And you get this strange duality in many laws, not just data protection law. So personal data, what is personal data? It's about a living individual who can be identified from that data or from that data combined with other data. And these individuals are known as data subjects. With anonymous data, as I've said, it's actually not subject to data protection laws, but there is a strange illogicality about encrypted data. Regulators think, well, if you encrypt data, you're protecting it, but you're not anonymizing it. I would argue that encrypted data is anonymous data in the hands of somebody who doesn't have the decryption key, at least as long as it's properly encrypted. But they would say, no, it's still personal data, even though it's encrypted, and the person holding it is still subject to all data protection laws, which to me doesn't make any sense. It should be personal data if you've got the key, but if you don't, it should be treated as anonymous data in my view. And the UK has a fairly similar view, but in continental Europe, it's different. So the concept of personal data is very important, and it's very, very broad. Now, you might think, OK, a name is personal data. John Smith, because it's such a common name, you may not know exactly who that person is without other information. So actually, John Smith may not necessarily be personal data. On the other hand, if you delete names, addresses, et cetera, fields, that doesn't mean it's not personal data, because there might be other information that's left which could identify a person. And a lot of organizations, if they're not sure whether something's personal data or not, they will treat it as personal data, comply with laws in relation to that just in case. But the personal data concept is not the same as the US concept of personally identified information or PII. People tend to use PII in a generic sense, the US influence, but it's not the same. The US concept is different. Who's going to be responsible for complying with data protection laws? It's going to be the controller. The controller is the person who determines the purposes and means of processing personal data. And the controller could be under the hook for complying with data protection laws, even if they're not in the EEA, even if they're an individual, not a company, even if they're a charity. Lots of organizations and types of entities could be caught. And it's the controller who is obliged to comply with data protection laws. And this includes requirements when a controller wants to use a third party processor to help it process personal data, like a service provider, cloud provider in particular, and there's certain rules on security in a written contract that apply if a controller wants to use a processor. The requirements of data protection law basically relate to collecting data, disclosing or sharing data, and using data, personal data, I should say. It's all about personal data and only personal data. So there are a set of basic principles which govern all this. And for what's known as special category sensitive data, like health data, there are even more rules like explicit consent being needed for processing. And data subjects are given write-in remedies. They can go to the controller and ask to access their data. If they need to, they can go to the courts. They can complain to their data protection authority. And these are the data protection principles, fair and lawful processing, purpose limitation. Data minimization is an important one in the technology context. For example, mobile apps over collecting data that they don't need, as Troy Hunt was talking about yesterday. Data accuracy, retention and deletion of data that's no longer needed for its purpose. There have been some companies that have been fined because they retain too much data and that they were hacked. Security is hugely important. There are rights for data subjects to object to direct marketing, rights to correct their data, et cetera, et cetera. There is a restriction which is very important in practice on the transfer, I put it in quotes, of personal data outside the European economic area except to countries with adequate protection. But a very important point to bear in mind, you need a legal basis to process personal data unless you have an exception like national security. And there are many legal basis that could apply, but only a few of them are used in practice, in particular consent and legitimate interests. And as I mentioned earlier, there's even more rules for sensitive personal data. So consent is not enough to process sensitive personal data. You need explicit consent. I just want to mention some myths or fallacies about data protection. Just because personal data is public does not mean that you can process it and not worry about data protection laws. It's like copyright data which is publicly available. So beware that just because personal data is published on a website or on Twitter or Facebook doesn't mean that you can do anything you like with it. Another point is this fixation on consent. Everybody goes on about noticing consent, how do you get consent, blah, blah. That is obviously important in the e-privacy directive, the cookie law. But for the data protection directive, personal data, it's actually not the only legal basis. I mentioned briefly earlier, there are several legal basis that could apply to allow processing in personal data. And in practice, most controllers do not rely on consent. They rely on what's known as legitimate interest. If it's in their legitimate interest to process the personal data, then they are allowed to do that. As long as it's not outweighed by the data subjects, fundamental rights and interests, there's a sort of proportionality test. So for example, if it's too privacy invasive, then the legitimate interest ground cannot apply. Another one is financial data. Some people think financial data is sensitive data. It's not. But interestingly, trade union membership is considered sensitive data. And there have been lots of high profile enforcement actions under EU data protection laws like Sony for the PlayStation hack, Google in relation to Street View Wi-Fi data collection. Privacy policies, interestingly, lots of data protection regulators across the EU actually coordinated their action on this front in discussions with Google. Facebook, lots of regulators, state regulators in Germany have taken action against Facebook. And I've mentioned the Belgian case. Now this is in the UK. The information commissioner has power to issue fines for data protection breaches since 2010. So this shows the fines that have been issued between 2010 and 2015 based on the type of breach, the type of principle. You can see that principle seven has got the most number of fines. Can you guess what principle seven is? Silence, security. You can see it's huge. I mean, security is the main reason. Security breaches are the main reason why companies get fined under data protection laws in the UK. So good security for personal data is good for privacy and compliance. The usual stuff, encryption, you know, app security, et cetera, including cloud security. And conversely, if you have bad security, you might get noncompliance and possibly fines. The ICO has published a document called Learning from the Mistakes of Others where it goes through some of the mistakes that have been made by companies which then got fined. It's a weird mixture of, you know, explaining some stuff that's really, really basic and then on the other hand, assuming quite a lot of knowledge. But you know, that is worth a read. And it includes fairly obvious things like, you know, not patching or updating, not implementing a suitable contract with a processor, not pen testing, et cetera. What does help is if you discover a breach and you reported yourself to the ICO rather than them hearing about it through the media and you take prompt remedial action, then that is going to help reduce your fine or should help reduce your fine. And I just wanted to show an example of some of the fines that the ICO has levied over the past few years. Sony, PlayStation hack, £250,000, Vulnerability not addressed. British Pregnancy Advisory Service, £200,000, Automated Tool to Identify Vulnerabilities, 10,000 users' data was kept for five years more than necessary. This is what I was talking about earlier, deleting unwanted obsolete data. Admin passwords not stored securely using HTTP instead of HTTPS. Think W3, £150,000, coding, again, some of the detail is no more than this, coding error in the login page authentication script. And a server only intended for internal use was actually open to the internet. It wasn't pen tested or scanned because it was intended for internal use. SQL injection, they kept the decryption key for encrypted credit card data on the same server they got broken into and where the data was. Worldview, 2014, it was originally going to be fined £75,000 but they reduced it to £7,500 due to financial hardship. But SQL injection, password, hash is extracted from a WordPress database, weak admin password, again keys for encrypted data kept on the same server, no testing, no security testing. Stature, £175,000, Unpatched JBus application server. So it is fairly standard security stuff but that can lead to quite big fines from the data protection front if they're not addressed. Just to show you, there was very, very little information about the Sony, all the ICO said was a vulnerability and action required to address the vulnerability even though appropriate updates were available. So something was unpatched, don't know what. So talking a bit about cloud now, if you're using layered cloud, SaaS on top of IaaS or Paz or Paz on IaaS, then I've mentioned before these mirror contracts that you need from your cloud provider and maybe even data center provider. This is actually going to be quite hard to get because, you know, imagine going to Amazon or Google or Microsoft and saying, right, I want you to sign these contracts where you're going to take on all these obligations to my customers. You know, it's going to be very hard to get them to do it. And so this is actually going to favor the large providers and large cloud customers rather than SMEs. And unfortunately, this requirement is going to be enshrined under the data protection regulation. International transfers restriction I've talked about before, you can't transfer personal data outside the EEA to countries without adequate protection unless you use a recognized mechanism or some derogation or exception applies. And unfortunately, regulators and courts approach this in a very location-centric way. They look at data location. They should be looking at who can access the data, including remotely, how secure is it, it has been encrypted so people in that country can't actually access it even though it's physically there. Which country has effective jurisdiction over those who have access to internal data? That's what they should be doing, but that's not what they're doing. They're looking purely at the location of data. I'm sure a lot of you will have heard about the Shremmers case in the Court of Justice of the European Union, where one of the mechanisms allowed to export personal data outside the EEA to the US was known as Safe Harbour. And the court said, Safe Harbour's dead. It's not valid. No time to talk about it now. I've got a link to a note there. And also for those in London at the British Computer Society, I'm talking in detail about what you do after Safe Harbour on the 9th of February. But this is a big issue. This is causing organizations to build data centers in Europe. And of course, that's going to raise costs, and the costs are going to be passed on to customers. So in summary for Cloud, it's location, location, location, contracts, contracts, contracts, encryption, encryption, encryption, and of course backup, backup, backup, but bearing in mind where you're back up to does impact on the location point. Cloud laws, unfortunately, are not technology neutral. They ought to be, but they're not. And for anybody interested, there's an article on the ways in which it's not technology neutral. Now of course, there are other areas. There's no time to go into, but for big data and profiling, anonymization is going to be a big issue. If you can anonymize data sufficiently, then you can process it using big data. You can do profiling, et cetera. But it is quite difficult. As I've mentioned, removing names and postcards, et cetera, may not be enough. With mobile apps, of course, you've got things like location data and biometrics. With IoT, you've got all of the above, including Cloud, because you might be using Cloud platforms for IoT. So they're relevant to lots and lots of areas. Now of course, there's a question of reality. Law may say one thing, but a different thing is, can a breach of that law be detected, and can it be enforced? Then it can be difficult to detect breaches, and that is why a lot of countries have introduced breach notification laws, to try and make sure that companies will notify breaches, although it's difficult to know whether there's evidence that breach notification laws have actually helped to improve security. Now in terms of enforcing breaches, individuals are not going to have the resources to sue large corporations, and large corporations are going to want to defend it because they don't want a precedent against them. Data protection authorities may not have resources to detect or enforce breaches. I mean, here in the UK, the ICO used to be under the Ministry of Justice, and it was recently moved to the Department of Culture, Media and Sport. The Cyber Security and Resilience team was moved to the Department of Business and Skills to the same Department of Culture, Media and Sport, which is all harking back to 1990s where data protection policy was the responsibility of the Home Office liquor gambling and data protection unit. Seriously, that is what it was. So that's going to be fragmentation of responsibility for data protection, which can't be a good thing in terms of joined up enforcement. So practical issues, consults, technology lawyers early, privacy by design, building in compliance with data protection principles into your systems and your software is going to be important, privacy engineering. And in particular, as I've mentioned, data minimization, not retaining data beyond what's necessary, good security like access controls and logging, data location. So there is a business opportunity for those involved in privacy enhancing technologies. And also, of course, for organizations, privacy impact assessments are going to be important, and what will be called data protection impact assessments in the future. Building a system or a service or a project in advance during the project as to its compliance rather than waiting to the end when it's already been built. Now I wanted to mention a bit about the GDPR, General Data Protection Regulation, which is going through at the moment. No time to cover it comprehensively, but there are some videos online on the previous version, which is still fairly, fairly relevant. This has gone through the EU legislative process since 2012, and political agreement was reached between the EU institutions last month. So actually, it might be adopted the first quarter, second quarter of this year. There will be a two-year lead time probably before it comes in, and they are going to be what's known as delegated or implementing acts, where the European Commission can produce further laws to sort of put flesh on the bones. Now the intention of the regulation was to strengthen rights for individuals, increase their control, and for organisations to make it easier for them to do business across the EU by having one set of rules that applies across the whole EU, and remove some administrative requirements on those organisations. However, as the ICO said, being more prescriptive doesn't mean you go to improve data protection, and I very much fear this is what's going to happen. It's going to be more prescriptive, but it's not necessarily going to actually help privacy. Now this, you've heard about the big fines that could be levied under the GDPR. These are the biggest fines that have been levied by the ICO in the last few years. 2012 is Sony, that's the biggest one. And you can see that potentially 4% of annual global turnover is the biggest fine under the regulation. You can see how much more that is. And actually, it's not just 4%, it's 4% or 20 million euros if higher. So it could be way more than that. For security breaches, it's going to be 2% and 10 million, so not so bad. But for breaches of fundamental principles, that's what it's going to be. So if you need to try and get upper management or the board to invest more in data protection and security, this might help. And just very rushing through the key changes, it is a regulation, not a directive, which means it takes effect directly in member states from the date it's supposed to become law. But there are two issues with that. It doesn't necessarily mean there's harmonisation because it can build in room for the manoeuvre. And the regulation can actually say member states can do this and that on this particular aspect. And they have done that here. Also a regulation could be ambiguous and therefore different member states can interpret it differently the way they like. And one of my favourite quotes from Newt Minow, a US lawyer, which illustrates cultural differences in the EU is this. He said to paraphrase a bit, in France, everything is permitted except that which is prohibited. In Germany, everything is prohibited except that which is permitted. In the Soviet Union, which dates somewhat, everything is prohibited including that which is permitted. But in Italy, everything is permitted especially that which is prohibited. So there are cultural differences in approaches to laws. I just want to pick out a few points there. Data portability and erasure, the right to be forgotten as you've heard about it. You may need to build systems that will allow, make it easier for data structures to get the data out, to move the data, to delete their data including with third parties. For controllers and processors, there's an article on SCL.org about processor liability. But if anybody here is working for a service provider like a cloud provider, you're going to be on the hook. You weren't under the directive but under the regulation, if somebody, if there's a breach and you were involved in the processing, your service was used in providing the overall service, then somebody who's been harmed by the breach could decide, okay, you have got the bigger pockets, I'm going to sue you. Even though it wasn't your fault, you could get done for it and then you'll have to claim back from, you know, the cloud customer, whoever, really was at fault. So this is a very important change for service providers. And for controllers and processors, you could have to look at your contract starting now in order to try and allocate liability in situations like that. Not in two years, you could start doing it now. Information of personal data will be important, including encryption. There's more emphasis on accountability like information to data subjects, recording and logging, you know, systems to allow data subjects to get information and to monitor the processing of their data. I mentioned earlier about the lack of harmonization. Somebody called Winford Veal did this diagram showing the areas where different member states can go their own way. So, so much for harmonization. You know, there can be so many national differences. And I've talked about consent, that it's not always the only legal basis, but if you rely on consent, then you need to record it properly. In fact, even now in the UK, under a case called Optical Express, you have to make sure you've got reliable records of where you got your data from and how you got your consent if you rely on consent. Personal consent, you know, where you, where free services are provided on the basis that the data subject consents to their data being used. It's difficult to know whether those models are going to survive or how difficult it will be for those models under the new regulation. I've mentioned security and the importance of that. And there will be new requirements for everybody, not just Helcos, to notify breaches to regulators and in some cases to individuals. Within 72 hours, we're feasible. So you're going to have to build in systems that will allow for breach notification. However, use of certified software or having systems that are under a particular seal or have got particular codes might actually help if there's a breach. You can say, well, I've got this certification. I did my best. It might help reduce fines. But these have to be approved by data protection authorities, not just any old certification. You can't say I've got ISO 27002, whatever. It has to be something that's approved by the regulators. So data protection by design and default, I've mentioned before, it's going to be compulsory. So not just something that's good, you know, a good idea to think about, but you'll have to do it. And that includes security by design and default. Data protection impact assessments will also be compulsory in some situations, going beyond security and consulting with data protection authorities. Some organizations are going to have to appoint data protection officers. International transfers, I've mentioned before, unfortunately, is going to be tightened up in many ways. They're not going to modernize the view of access, but they're going to focus still on physical location from the sounds of it. And there are going to be different rules on profiling and automated decision-taking which should affect things like use of AI and machine learning. So overall, I personally don't think that the GDPR is going to be better for data subjects because of the lack of harmonization. Member states can introduce exceptions through the back door. It is going to have a big impact on cloud computing, big data, et cetera. And there is a risk that protesters could refuse services to EEA customers, leave the EEA market, or alternatively, maybe the laws are going to be ignored. But certainly, the way that the laws are going, they're going to favor large incumbents over small startups. I'm not sure that's the intention, but that's going to be the result. However, for the public sector, they're going to have more flexibility in their processing of personal data, even though a lot of public sector authorities may have lost personal data, but they're going to have more flexibility in the processing. So one question is actually, could the GDPR enable government data protection backdoors, never mind encryption backdoors? So please do think about planning ahead. Two years actually isn't that long in the scheme of things if you need to change the systems. If you're a service provider, you're going to be directly liable for the first time, and so it's really important to think about your contract and similarly for controllers. There are some places where you can get free IT law advice. In London, there's Q Legal for startups. There's Boot Law, which has free meetups. Own it, mainly intellectual property, rather than IT. I should say Q Legal is associated with Queen Mary, Boot Law with Princeton Masons. And of course, with different jurisdictions, they're going to be different places where you can get free advice. For legal news, it's affecting technology outlaw. I've mentioned before, it's associated with Princeton Masons, but it's quite well known as a good source for non-lawyers about technology law news. SCL.org, I am on the media board, but it is a very good society for computers and law. And there are lots of blogs around like IPCAT for IP law, Inform for media law, Panopticon for information law. And obviously, standard resources on security are going to be very relevant. But also, the Article 29 Working Party has a whole raft of opinions. The Information Commissioner in England has got lots of guidance and a blog, et cetera. And I'm not going to list them or link to them because you can just go through them. There's guidance on mobile apps, there's guidance on big data, et cetera, facial recognition. I'm not going to talk about laws affecting hacking. I might in the future, if there's demand, but a lot of countries, including here in the US, have laws which are about accessing systems or data without authority. And I thought it was important to mention, it's not about whether you have got good intention to an ethical hacker, it's about whether it was authorized by the company or not. So for pentesters, it's very important that the written scope of your authorization that you get that right. And if there are other areas that you want to hear about on legal issues, then please let me know. So if there's time, then please come, I don't think there is, come and talk to me with questions, and please do fill in the evaluation or do the evaluation red, green, yellow thing at the end. Thank you very much. So here's my contact details if anybody wants to touch base afterwards.
 I'm Kwan Hon, and welcome to Legal Pitfalls for Developers.  This is me, four hats, four clouds, and two weasels.  I have several hats.  I am a lawyer, but I've also got a degree in Computing Science.  The other two hats are that I'm a practitioner.  I'm a consultant lawyer to a law firm, Pinsen-Masons, but also I'm an academic.  I'm a researcher at Queen Mary University of London.  I've worked on four cloud law projects, including the Microsoft Cloud Computing Research Centre,  which is a collaboration with computer scientists at the Cambridge Computer Lab.  I have been the primary author of eight out of the 14 chapters in this cloud computing law book by OUP.  The two weasels are that what I say represents my own opinion and not necessarily that of any organisation I'm associated with,  and the second weasel is that this is just general information, not legal advice.  So the purpose really is to raise awareness of some issues.  There's no time to go through everything in detail.  It's just so that you're aware of some of the issues you might be coming across.  So first, I'm going to talk about law in dealing with lawyers and then some key pitfalls with intellectual property.  My main focus is going to be data protection, legal issues, and if there's time for questions at the end,  we'll have that otherwise please catch me during a break.  Now, as developers with software, these are the main areas I'm going to cover.  There could be more, of course, but the main areas are you create software, you use your software,  you might allow other people to use your software on certain terms.  So in terms of laws and lawyers, I'm just going to go through the laws and what they are,  even though it might seem fairly obvious.  Laws are just rules that are enforced by the government and backed by the government.  So the rules could come from legislation or legal codes.  They could be created by judges in common, what's known as common law systems like England and North America,  rather than civil law systems which rely more on legal codes and less on the judges.  The enforcement systems can include courts, regulators with sanctions such as jails and fines,  damages, injunctions, stopping people from doing something or making them do something.  Now, the role of contract is very important in law and basically a contract is just an agreement between parties  who's going to do what, what happens if they do or if they don't, etc.  which the state is willing to enforce.  It's just a state backed agreement, but it's important.  It's really important to note that each country has laws on the validity of contracts.  So just because Alice and Bob agree something doesn't mean it's going to be contract.  They're criteria which have to be fulfilled before the law will recognize it as a valid contract that it will enforce.  And furthermore, even if the overall contract is valid, there might be some part of it that laws are going to say  are not valid, they won't enforce it, they're not legal.  For example, there are a lot of laws about protecting consumers against unfair contract terms.  So certain terms might be considered unenforceable as against consumers.  Even the contract overall is a valid contract.  In terms of what, well, I like illiteration, so I phrased it as dues, deals, disputes and decrees.  So dues, your rights, what's due to you?  IP rights, other rights, there's obviously lots of actors that can be involved, deals, your contracts.  Disputes, what happens if things go wrong and decrees or dictates, compliance requirements on you  where you have to comply with, for example, requirements on notifying breaches.  In terms of the what, there are multiple laws that can apply.  So in one situation, you can't just say, oh, well, one law applies to this situation.  There are many laws that could apply, including the laws of different states.  So different countries' laws could apply to the same situation at the same time.  And the way I think of it is for each law, you think about multiple boxes.  There's a box for the scope of the law in what circumstances it'll apply.  There's a box for exceptions to the law in what circumstances that it not apply.  What are the consequences if that law does apply, et cetera?  And then you have to look at each box and say, for this particular situation, is it going to fit in that box?  And bear in mind that in law, the boundaries for these boxes are fuzzy.  And they change.  They can get bigger.  They can get smaller, et cetera.  So that is what makes it difficult.  You can have multiple boxes and the boundaries are fuzzy.  And then you have to repeat this for every law that might be relevant.  It is also particularly difficult because laws are behind technology, for example, copyright law.  So basically, this is what lawyers have to deal with.  So multiple overlapping boxes where the boundaries are fuzzy and they can change.  They can get bigger or smaller.  New boxes might be added or taken away.  They can change around.  And that's why some lawyers get the big box because they have to deal with these sort of complexities.  Now, why do you care?  Obviously, it's your rights.  It's your remedies.  But it's also your risk management.  You have to manage your legal risk.  And the issues for you may be different compared with the issues for your employer or higher.  Sometimes you might have opposing interests.  So bear in mind they might be different.  I'm mostly going to be talking about the issues for your organizations.  So managing legal risk, I think of it as a risk pyramid because legal risk affects  reputational issues which can affect public trust.  And the reality, though, is that organizations don't necessarily comply for the sake of compliance  because legal risk is part of the overall business risk.  So there might be strategic issues or commercial issues, revenues.  Is it practical to comply with particular laws?  And organizations balance that against the risks of detection of a breach and forcing  the law, one of the sanctions, if it's enforced.  So I'm not advocating or advising that you do not comply with laws.  No lawyer can do that.  But basically, it is up to the organization to make its own decision.  And sometimes there are hard choices.  An example, not of hard choices but of noncompliance, might be media organizations who deliberately  invade the privacy of celebrities to try and get more traffic, sell more newspapers, whatever.  And they take the chance that they might get caught and get fined.  So another reason why it is important to talk to lawyers is that laws are not necessarily  logical.  Just because something is logical doesn't mean it's legal.  Just because something is illogical doesn't mean you don't have to do it.  Sometimes the law requires you to do things which are actually not very logical or not  very sensible.  And a very important issue, which I don't think many people realize, is that laws don't  necessarily mean what they say.  You could read a statute, you could read a case from a judge, and you think, oh, yes,  this is what it says.  But actually, words may have different meanings from what it says on the page because the  law says so.  The legislation actually defines something particularly.  Or a judge has interpreted certain words just to mean something other than what it actually  says.  So that's a very important point.  And also, laws are not always technology neutral.  It seems that actually, laws are enforced more harshly against things digital, like  with copyright law or website vandalism, than with things in the non-digital world.  So the point about using lawyers is that lawyers know about all these peculiarities and idiosyncrasies.  They can translate them into practical advice.  And of course, you could rely on the insurance policy, perhaps.  If they get it wrong, they advise you wrong, you might be able to sue them.  Because if you do it yourself and you get it wrong, you're kind of stuck with that.  In terms of how, obviously, it always helps to give lawyers lots of money.  But really, it's communication and information.  That's what's important.  And when you're communicating with lawyers, bear in mind that there are different mindsets  between technologists and lawyers.  So technologists tend to think in binary, in black and white.  But lawyers tend to think in analog, in shades of gray.  So it is quite, you have to bear this in mind when you're communicating with lawyers, the  different mindsets.  As far as lawyers are concerned, there isn't such a thing as certainty.  That is why lawyers always say it depends.  Because it does depend on interpretation, on context, the individual situation, and things  are much more a matter of probability than of certainty in law.  So in terms of information that you give to your lawyers, you've got to make sure, particularly  for deals and projects, you communicate what you're trying to achieve, exactly what you're  trying to do, exactly what sort of data you're trying to handle, and how you have to explain  the technical model and the business model properly.  And it has to be a proper two-way communication.  And an important factor, again, to bear in mind when you're communicating with lawyers,  is that there is an issue of jargon or terminology.  Often, lawyers and technologists can use the same words to mean different things or  different words to mean the same things.  And then you're going like that instead of like this.  And examples I like to use are, from the cloud context, SLAs.  Most people here would probably think SLAs means the contract.  But actually, to lawyers, SLAs is just one subset of the contract.  It's just the service levels bit, not the rest of it, like liability, choice of law,  et cetera.  And this is a consumer, I mean, NIST says a cloud consumer, whereas to lawyers, that  would be the cloud customer.  Consumer is the individual end user.  Now of course, it is quite difficult because with laws, every country has their own law.  The internet is global, but laws are local.  So this can cause a lot of problems in this century.  And the thing is, even with regional laws like EU directives, EU legislation, et cetera,  actually there are differences within individual countries.  And then we have things like federal systems, for example, in the US states, Germany with  its states, then that makes it even more complicated because they could be different.  So you have multiple different jurisdictions to consider, and you have to think about which  individual countries or states are relevant to your particular situation.  You might think, OK, well, let's put it in the contract to say the laws of England and  Wales are going to cover the situation.  I want the courts of England to deal with any disputes.  But actually, again, like I was saying before, there is an issue of validity.  Some contractual clauses may not be valid.  So you might say you want, the parties might say we want this law to apply, but the courts  will say no, it doesn't.  For example, in France, a man sued Facebook, Facebook said it's California law that applies,  and the court said no, that's not valid.  You can hear the case here in France.  So there are mandatory rules in lots of countries which apply here.  And there's also another important point, I think, in practice, which is the difference  between claimed jurisdiction and effective jurisdiction.  So a country might say there is a ban on wearing T-shirts at conferences.  But if it's a country on the other side of the world and you're not in there, then they  can claim that all they like, but they can't actually apply it to you.  And they don't have effective jurisdiction over you.  So in terms of countries that are relevant, the factors, I think if this is a target test,  it's not a particular rule, it's just the way I put it as a target test.  So what's your target market?  Which countries are you targeting?  That's where you have to be concerned about their laws.  Where are you a target?  Which countries could target you because they have effective jurisdiction over you because  you have physical assets there, people or operations, et cetera.  Take for example the EU internet gambling CEOs.  They were in transit in the US.  And then the moment they were in transit in London and US soil, they were arrested because  they had a physical presence there.  And the physical connection is very important in lots of laws.  Other connections are possible such as an organization being incorporated in a particular  country, for example.  So it is important to listen to your lawyer's advice, communicate with them properly about  where the relevant countries might be and see what they say about which are the most  important countries to consider.  There's also a question of impossibility, particularly with multinationals.  Sometimes if you try to comply with the law of country A, you're breaching the law of  country B, and then you have to decide which law to break.  So that's a really difficult situation.  You do need to talk to your lawyers as soon as possible.  It is the false economy to wait.  I've done research on cloud contracts and the negotiation of cloud contracts.  And I've had in-house lawyers saying to me, look, they are thrown a contract and told,  it's going live next week.  Just have a quick look and you'll see if there's any legal issues.  And that's too late for them to do anything about it if there are going to be legal problems  for your company from the contract.  So please do remember to involve your legal teams at an early stage.  Of course, you need to consult lawyers plus plus or lawyers sharp.  You need lawyers who have subject matter expertise, expertise in technology law.  You wouldn't want a GP or a bowel surgeon to operate on your brain.  And similarly, you wouldn't want a high street practitioner or a general commercial lawyer  to advise you on IT law.  You also need to consult lawyers who have expertise in the relevant countries because  all countries' laws are different.  And you want to make sure you get somebody who's going to give you solutions and ways  to do things rather than saying no, no, no to everything.  So that's just a canter through lawyers.  And now talking a bit about intellectual property.  Intellectual property rights are property rights of intangible property.  But again, they are just government backed rights to control or monopolize the use of  intellectual property.  And the main ones, I'm sure you've heard of are copyright, patents, database, right,  trademarks, et cetera.  And again, different countries have slightly different rules on intellectual property rights.  When does the right arise?  For example, with copyright, it arises automatically once the work is fixed, recorded, written  down.  Whereas with patents, you have to apply and get your application granted before you have  that right.  So the scope of the right may differ.  The duration, how long you have that right, how is that property right transferred or  licensed, et cetera.  What acts are restricted?  What's considered infringement of copyright?  What are the exceptions that are allowed?  What acts are allowed and not considered infringement?  So of course, you'll all have heard a lot about licensing, permissions to use certain  intellectual property.  And there's an overlap between licenses and contracts, but they're not technically exactly  the same.  So for software, let's look at the creation part.  Code, you're going to write code, you're going to be in some applications using other content  like graphics or music.  So who owns software?  Well, with code, the main intellectual property rights that are relevant will be copyright  and patent.  I'm mainly going to talk about copyright because it's the main one.  I mean, patents are less common.  It is possible to patent software where it's part of a larger thing.  You can't patent software as such.  And in some countries, it's easier to patent software than others.  But copyright is the main thing.  So is there a difference if you're an employee or you're a contractor?  If you are an employee of a company and you write code, who owns the code?  Generally it's going to be your company, not you.  If you're a contractor, you're hired to write code for another company.  Actually, you will own the code.  Even if they paid for it, they don't own the code.  You own the code.  So they've got to make sure that they do something, put something in the contract to ensure that  actually you will assign the ownership of the code to them.  So there is a big difference between employees and contractors.  And with side projects, if you're an employee and you're doing a side project at your own  time, who owns the code?  You might find that your employer tries to say it owns the code.  What about joint ownership when there's collaborations?  If you've got lots of people involved as is common, then actually they might all own  the code jointly.  And the ownership may not be in proportion to the extent of the contribution.  So really what you have to do is make sure that you've got a contract in place at the  outset that deals with the things.  For example, if you're going to be working for a company, but you know you're going to  be doing side projects and you want to make sure you own the code, make sure you put that  in the contract.  Or if you want some code that you do in your work to be yours and not the companies, make  sure that's in the contract at the start.  And similarly for companies which are hiring contractors, if they want to make sure they  own the code and not the contractor, they've got to make sure they put that in the contract  at the start.  So I put timing as a very important point.  You have to do that at the start.  It might be too late to do it afterwards.  And again, bear in mind different jurisdictions have slightly different rules.  So another aspect, if you are creating software, is could you be infringing other people's rights?  For example, if you're using other people's code in your code, and bear in mind that just  because code is publicly available doesn't mean that it's free from copyright.  Public does not mean free to use.  That's an important point under copyright law.  Of course, there are also issues if you're using open source code.  There could be lots and lots of talks on open source code alone.  A small example is if you're using open source code, and you modify it, you're supposed to  contribute your modifications back to the community.  And there's this question about, well, okay, you take open source code, you modify it,  and then you run it in the cloud, offer it as a service.  You're not distributing it, so therefore you're not obliged to contribute it back to the community.  And that's how the aphero license was born, to try and get around that.  It doesn't actually work, but it's trying to do.  And bear in mind that even APIs may be copyright.  So in the EU, interestingly, again, regional differences, in the EU, the Court of Justice  has said that you cannot copyright APIs.  However, in the US, the judge initially who actually does some programming said, no, you  can't copyright APIs, but then the appeals court said, yes, you can copyright APIs.  And the Supreme Court has refused to hear the appeal, so we're kind of stuck with that  in the US.  So that underlines the point I said where every country, every region may have differences.  And there are many ways in which you might risk infringing copyright, for example, not  just copying, but modifying, distributing, communicating to the public, et cetera.  And it's not just copyright that could be relevant.  There are other IP rights like trademark, and there might be other legal rights like  data protection.  And of course, bear in mind, it's not just your code you have to think about, but anything  else you incorporate in your app, like graphics, music, et cetera.  There might be intellectual property issues with those that you have to think about.  I wanted to say a bit about data ownership.  I think it's a fallacy.  People keep talking about who owns your data, it's your data, et cetera.  Number ownership is just a government-backed rule.  Ownership of intellectual property, even physical property, depends on laws.  In medieval times, lords owned land, but serfs didn't strictly own land in that same  sense.  They couldn't.  So it's all dependent on the laws as to ownership.  So really, with data, you don't own data, you can control the use and dissemination  of data through laws like intellectual property law, copyright, et cetera, and other laws  might be relevant like confidential information, misuse of private information, et cetera.  But practical control is also very important.  And as for personal data, I will come to that.  So really, with software, there are a number of issues.  The main one that I want to concentrate on next is exploiting the software.  If you want to make your software available for other people to use.  And you might be concerned about your rights and liabilities in this context, which might  depend on the channel of distribution.  So the model is relevant.  Are you licensing?  Is it a contract?  Are you going to...  The method is important.  Are you going to be using online terms and conditions?  To what extent is that actually enforceable?  And what about the channel?  Are you going to go through cloud, through app stores, where there might be developer  agreements that bind you, et cetera?  What's your liability for things like bugs and security holes?  What happens if people want to sell their software secondhand?  And there's a lot of laws, particularly on protection of consumers.  I just mentioned briefly one because it's quite new.  Consumers Rights Act came in in the UK a few months ago.  It's under a directive which is going to apply across the EU.  And it applies to digital content, which is sold to consumers, not just apps or games,  but even a website content.  If you're delivering a website design, that could be digital content, a supply of digital  content.  Interestingly, there are fewer rights for the consumers where the service or the sale  is for free or personal data rather than when it's paid for with money.  And of course, if you're trying to sell your software as a service or on media, there are  laws that you'll have to think about which are applying generally like on marketing,  advertising, et cetera, what information must you put on your website for consumers, what  do you have to put in your emails, et cetera?  So not going to go into that.  That's all general business stuff.  Coming to the use of software internally, where you might be creating software and then  using it internally to process personal data or other data and inputting, sorry, and getting  output.  Well, for developers, it's probably slightly less relevant when you're using software  internally because it's mainly the person using the software who will have the risk,  whether they're using software produced internally or software that they got from externally.  For example, if they use software to process copyright third party material, then they  will be at risk there.  Or to process personal data, they have to comply with data protection laws.  But there are issues like if software is used to process data, where did it come from?  Is it properly sourced?  Is it legally sourced?  And with personal data processing, what happens if the software wasn't properly secure?  So another point I want to mention is that the channel matters.  The legal issues can actually depend on whether you're using cloud or not.  If you've built a SaaS app on PaaS or IaaS, then actually the legal issues may be different  from when you're just building an application and deploying and hosting it in your own data  centers.  Just some examples.  For example, with copyright, which countries' laws apply may depend on where the work was  recorded or created.  So if you're using a server that's in a different country, then maybe the laws of that country  may apply rather than your laws.  With database rights, sorry, that should say database rather than data.  But I've told you briefly about the EU database right.  It's a special right created under EU law.  Well, it's only an EU right.  So again, if you're trying to create a database but you're using a server in the US, do you  get an EU database right?  So location does matter a lot with law, physical location of servers.  Or similarly, if you're running patented software, some countries recognize software  patents, some don't.  So you're running a software which is actually under a patent.  But if you run it in your own country, you might be okay.  But if the server you're using it on is in the US or some other country where that software  is patented, then maybe you'll be in trouble.  So actually the location of your servers again does matter.  And of course, with cloud, a lot of people are concerned that the cloud provider has  access to your data and there might have to be contractual restrictions.  So even if you're using internally the software or app you've created, but you're using a  third party provider, PAS or IS, you have to be concerned about the contract with the  provider.  Normally, the contract is going to be on the provider's own standard terms and you don't  have any choice about it.  The scope for negotiation is very limited.  But there are legal risks, especially with personal data.  And I did some research on the negotiation of cloud contracts a few years ago.  And the top three issues that came up were liability and disclaimers of the provider,  for example, for data integrity or disaster recovery, service level agreements, and security  and privacy.  So again, another important reason to involve external lawyers early to deal with these  issues.  And of course, it's not just legal issues that are relevant, practical issues may also  be important and they're related.  For example, as regards the risk of lock-in or exit.  OK, you might put in the contract that there has to be a minimum time period that you get  to retrieve your data after the termination of the contract.  But also, of course, it's important to test beforehand whether the data and how portable  the data is, how can you get it out, how portable is your code, et cetera, to a different platform  and to implement backups.  If you are using a third-party cloud provider, PAS or IAS, to offer your own SaaS service  to your own customers, then you've still got the same issues regarding your contract  with the IAS or PAS provider as before.  But you have even more issues because, of course, you have the risk of liability to  your own customers and you've got your contract, your own customers that you have to think about.  And there is a question mark about the viability of these back-to-back contracts with your  own cloud provider, maybe with third-party data-centred providers, et cetera.  Because if you have certain liability under your contract to your customers, but you can't  actually get the same liability sort of back-to-back from your provider, then you are kind of pigging  in the middle, you are exposed, but you can't actually claim back from your cloud provider.  So again, it is very important to talk to your lawyers about this sort of thing.  And now moving to the main area I want to focus on, which is data protection, there  are lots of laws on data protection and privacy.  Some of them may overlap, but basically there's a whole patchwork.  You've got the ePrivacy directive, which is the source of the infamous cookie law.  Same focus is the data protection directive, but things like the EU Charter of Fundamental  Rights, Convention of Human Rights, cases which have evolved laws on misuse of private  information, et cetera.  And again, different countries may have different applications.  This is an and, not all.  I can't emphasize enough.  It's not just one law that applies.  Many, many laws from many countries could apply to your situation, particularly if it involves  the internet.  But this overlapping application and liability is important, because if something goes wrong,  then whoever is trying to sue you may just pick all the laws they can and throw all of  them at you and say, I'm going to sue you under this, under this, under this, under  this.  So all of them could apply, and they may all need to be considered.  Now I want to talk a bit about the cookie law under the ePrivacy directive.  It's not just about cookies.  It's mainly this directive about communications privacy, such as breach notification requirements  for telcos, and again, with national differences.  This is, I don't know whether this is, you've seen this.  It's fairly well known because there has been a lot of criticism of the cookie law and an  organization called SightBeam put out some graphics.  This is one of them showing how it doesn't actually necessarily help privacy, but has  caused a lot of panic and a lot of money spent.  The origins of the law, well-meaning privacy advocates and octogenarian lawmakers who couldn't  use a mouse, probably something in that.  And to be fair, you could say this doesn't just apply to the cookie law.  It could apply to other laws as well.  And beyond the EU, for example, in the US, there's been talk about the judges who have  to rule in cases about mobile phones and about video games, but they don't even have mobile  phones and so on.  So there is an issue about lawmakers' understanding of technology, which is quite important because  it affects the laws that affect us all.  And of course, the fact that it might actually help very, very little people who benefit  from a law that tells them a website uses cookies.  And even Outlaw, which is a website associated with Princeton Masons, is a technology news  website called the Cookie Law, breathtakingly stupid, but it is the law.  And I just wanted to clear up some misconceptions about the cookie law because people call  it the cookie law, but actually it's not just about cookies or even tracking cookies.  It's broader than that.  And it's not just about organizations or businesses.  Individuals can be caught by the cookie law.  It's not just about computers or browsers or websites, but other devices as well.  And it's not just about personal data, unlike the Data Protection Directive.  It's not just about storing data.  It also includes access to data.  And it's not just about things happening over the internet.  A USB stick with software in it, which could read or access information, that could be  caught by the cookie law.  And the penalties, well, some people aren't worried about the penalties, but I think they're  increasing in Spain.  4,000 euros for a jewelry retail chain.  In the Netherlands, 25,000 euros.  It was a public service broadcaster.  EU regulators, generally, they did a cookie sweep in 2014.  So as a result of that, France have actually been in contact with, I think, 20 companies  saying you've got to comply with the cookie law.  In Belgium, the Belgian Data Protection Authority sued Facebook in court under the cookie law  and under data protection laws, and actually won.  And you've probably heard about the 250,000 euros a day fine that they were imposing on  Facebook before Facebook decided to change their systems.  And there are exceptions where the cookie laws do not apply, but they're very, very narrow,  like essential cookies, such as a shopping basket or a login cookie.  They're very narrow.  So really, the cookie law is about stopping storing information or accessing information  on the terminal equipment, not just computer, of a user subscriber unless the user subscriber  has been given information about what you're doing this for, why you're doing this, and  they've consented.  So it's not just about cookies and websites.  It actually affects mobile apps, IoT, et cetera, et cetera.  Maybe consent will be easy to get with an app, something with a signed up form, registration  only sites.  But there are lots of difficulties with this law, like who's responsible for complying?  If you have a website and you use third party analytics or you use a social plug-in, is  it you that's responsible for getting consent?  Is it the analytics or social plug-in provider who's responsible for getting consent?  Even Europa, this is the website of the European institutions, European Commission, Council,  et cetera.  They've got various pages talking about Google Analytics, but they're quite inconsistent  in the way they talk about that.  And it's quite interesting that Google, in the middle of last year, about AdSense, they  actually, I think some of you might have come across these changes, they actually said,  if you are a publisher using AdSense on your website, in your apps, it is your responsibility  not theirs to get consent.  Now whether that's right or not, difficult to say because if it's your responsibility,  then you might, in order to say what the data is being used for, you might have to go into  their code and figure out exactly what it's doing and what it's collecting, et cetera,  et cetera.  So this is quite difficult.  So it's a major issue as to how you can comply.  How do you get consent?  For example, at the strictest extreme, you could have a mobile light box on a website,  user can't do anything until they consent, but you pause the cookies so no cookies are  set until they consent.  Is implied consent sufficient?  Is that, in some countries, it might be in others, it won't be.  Now there's a lot of guidance that's been issued, including by the Article 29 Working  Party, which is EU regulators, data protection regulators collectively, in the UK, the Information  Commissioner.  They use a tool called Civic Cookie Control, but different countries, there might be different  issues.  The Interactive Advertising Bureau has produced guidance last year.  The Belgian Data Protection Authority, who I mentioned sued Facebook, they recommend  social share privacy as a tool for pausing cookies before making sure they're not set  until the user consents.  Canil, which is the French Data Protection Authority, they use Peewick for analytics  rather than Google Analytics because they think, again, that's better.  And Europa, the European institutions website, they even have a cookie consent kit on there.  So I've compiled some links to tools.  It's slightly updated.  I haven't a chance to update it properly, so you can have a look at Bitly Cookie Law  links if you want.  But a difficult and important point to note is actually you've got all these guidance  out there, but just because you comply with it doesn't mean you're guaranteed to comply  with the law because it may take a court to say exactly what the law means before you  know you're compliant.  A lot of people have been using banners, but in the Belgian Facebook case, the court said,  I don't like the way they've used the banners.  Not sure that's good enough.  So it is quite difficult.  You do need to take advice and you need to look at the practicalities as well.  I mean, some of the guidance on cloud, which I haven't put there, but the regulations guidance  on cloud is frankly, I think, impossible to comply with.  So the Data Protection Directive, this was, this took five years to come through.  It was proposed in 1990 and adopted in 1995.  It's a directive, not a regulation, which means that it only takes effect as law in  a particular country when that country passes national legislation to adopt it into law.  And there are differences.  For example, mainly what I like to say, with security.  In the UK, the Data Protection Law has four lines on security.  In Italy, it's about four pages, including stuff on access controls, et cetera, et cetera.  So it can be quite different.  And this law applies not just to the EU, but also the European Economic Area, EU plus Iceland,  Liechtenstein and Norway.  And currently there is a draft Data Protection Regulation, which is intended to modernize  the laws, but I'll talk about that later.  And for those who are interested in the difference between the EU and the EEA, I produce a Venn  diagram, EFTR, et cetera, et cetera, bit.ly slash EU hyphen Venn for anybody interested.  So this is not to scale, but this is just to show that data protection in the legal  sense is not the same as data protection in the IT sense.  In the IT sense, data protection might apply to data that's not personal data under the  Data Protection Directive.  Under the Data Protection Directive, data protection only applies to personal data,  but there are technical and organizational security measures that have to be taken in  relation to personal data.  So there is an overlap, but it's not necessarily the same as IT data protection.  And of course, the Data Protection Directive is relevant to lots of areas.  Remember this is in addition to the cookie law, not instead of websites, mobile apps,  cloud sharing data with third parties, et cetera.  So the basic principle is that the Data Protection Directive regulates the processing of personal  data with some exceptions such as household use.  So your personal address book with the contact details of your friends and family, that's  exempt because that's household personal use.  Big hole, national security, law enforcement.  So it's important to note that processing that's regulated under the Directive is not  the same under the legal and IT sense.  It's much broader than the IT sense.  So in the IT sense, when you talk about processing data, you're talking about compute operations  on data.  But in the legal sense, when data protection laws talk about processing, it's not just  operations on data, but it's also passively storing, holding data.  It's transmitting, displaying data, et cetera.  It's basically anything that you can do to or with digital data is going to be processing  and caught by data protection laws.  And data protection laws are supervised by data protection authorities such as the ICO  in the UK.  It is considered a human right.  Data protection is considered a human right in the EU, and so non-EU citizens can also  be protected under data protection laws.  Now the concept of personal data is central to the application of data protection laws.  It is what I call binary and application analog in determination.  And what I mean by that is that if something is personal data, then data protection laws  apply to it.  If it's not personal data, if it's anonymous data or anonymized data, then you don't have  to worry about data protection laws.  You can ignore them.  So that's the binary bit.  The analog bit, the shades of gray, is that it's actually quite difficult to decide is  this bit of information personal data or not.  And you get this strange duality in many laws, not just data protection law.  So personal data, what is personal data?  It's about a living individual who can be identified from that data or from that data  combined with other data.  And these individuals are known as data subjects.  With anonymous data, as I've said, it's actually not subject to data protection laws, but there  is a strange illogicality about encrypted data.  Regulators think, well, if you encrypt data, you're protecting it, but you're not anonymizing  it.  I would argue that encrypted data is anonymous data in the hands of somebody who doesn't  have the decryption key, at least as long as it's properly encrypted.  But they would say, no, it's still personal data, even though it's encrypted, and the  person holding it is still subject to all data protection laws, which to me doesn't  make any sense.  It should be personal data if you've got the key, but if you don't, it should be treated  as anonymous data in my view.  And the UK has a fairly similar view, but in continental Europe, it's different.  So the concept of personal data is very important, and it's very, very broad.  Now, you might think, OK, a name is personal data.  John Smith, because it's such a common name, you may not know exactly who that person is  without other information.  So actually, John Smith may not necessarily be personal data.  On the other hand, if you delete names, addresses, et cetera, fields, that doesn't mean it's  not personal data, because there might be other information that's left which could  identify a person.  And a lot of organizations, if they're not sure whether something's personal data or  not, they will treat it as personal data, comply with laws in relation to that just  in case.  But the personal data concept is not the same as the US concept of personally identified  information or PII.  People tend to use PII in a generic sense, the US influence, but it's not the same.  The US concept is different.  Who's going to be responsible for complying with data protection laws?  It's going to be the controller.  The controller is the person who determines the purposes and means of processing personal  data.  And the controller could be under the hook for complying with data protection laws,  even if they're not in the EEA, even if they're an individual, not a company, even if they're  a charity.  Lots of organizations and types of entities could be caught.  And it's the controller who is obliged to comply with data protection laws.  And this includes requirements when a controller wants to use a third party processor to help  it process personal data, like a service provider, cloud provider in particular, and there's  certain rules on security in a written contract that apply if a controller wants to use a  processor.  The requirements of data protection law basically relate to collecting data, disclosing or sharing  data, and using data, personal data, I should say.  It's all about personal data and only personal data.  So there are a set of basic principles which govern all this.  And for what's known as special category sensitive data, like health data, there are even more  rules like explicit consent being needed for processing.  And data subjects are given write-in remedies.  They can go to the controller and ask to access their data.  If they need to, they can go to the courts.  They can complain to their data protection authority.  And these are the data protection principles, fair and lawful processing, purpose limitation.  Data minimization is an important one in the technology context.  For example, mobile apps over collecting data that they don't need, as Troy Hunt was talking  about yesterday.  Data accuracy, retention and deletion of data that's no longer needed for its purpose.  There have been some companies that have been fined because they retain too much data and  that they were hacked.  Security is hugely important.  There are rights for data subjects to object to direct marketing, rights to correct their  data, et cetera, et cetera.  There is a restriction which is very important in practice on the transfer, I put it in quotes,  of personal data outside the European economic area except to countries with adequate protection.  But a very important point to bear in mind, you need a legal basis to process personal  data unless you have an exception like national security.  And there are many legal basis that could apply, but only a few of them are used in  practice, in particular consent and legitimate interests.  And as I mentioned earlier, there's even more rules for sensitive personal data.  So consent is not enough to process sensitive personal data.  You need explicit consent.  I just want to mention some myths or fallacies about data protection.  Just because personal data is public does not mean that you can process it and not worry  about data protection laws.  It's like copyright data which is publicly available.  So beware that just because personal data is published on a website or on Twitter or  Facebook doesn't mean that you can do anything you like with it.  Another point is this fixation on consent.  Everybody goes on about noticing consent, how do you get consent, blah, blah.  That is obviously important in the e-privacy directive, the cookie law.  But for the data protection directive, personal data, it's actually not the only legal basis.  I mentioned briefly earlier, there are several legal basis that could apply to allow processing  in personal data.  And in practice, most controllers do not rely on consent.  They rely on what's known as legitimate interest.  If it's in their legitimate interest to process the personal data, then they are allowed to  do that.  As long as it's not outweighed by the data subjects, fundamental rights and interests,  there's a sort of proportionality test.  So for example, if it's too privacy invasive, then the legitimate interest ground cannot  apply.  Another one is financial data.  Some people think financial data is sensitive data.  It's not.  But interestingly, trade union membership is considered sensitive data.  And there have been lots of high profile enforcement actions under EU data protection  laws like Sony for the PlayStation hack, Google in relation to Street View Wi-Fi data collection.  Privacy policies, interestingly, lots of data protection regulators across the EU actually  coordinated their action on this front in discussions with Google.  Facebook, lots of regulators, state regulators in Germany have taken action against Facebook.  And I've mentioned the Belgian case.  Now this is in the UK.  The information commissioner has power to issue fines for data protection breaches since  2010.  So this shows the fines that have been issued between 2010 and 2015 based on the type of  breach, the type of principle.  You can see that principle seven has got the most number of fines.  Can you guess what principle seven is?  Silence, security.  You can see it's huge.  I mean, security is the main reason.  Security breaches are the main reason why companies get fined under data protection  laws in the UK.  So good security for personal data is good for privacy and compliance.  The usual stuff, encryption, you know, app security, et cetera, including cloud security.  And conversely, if you have bad security, you might get noncompliance and possibly fines.  The ICO has published a document called Learning from the Mistakes of Others where it goes  through some of the mistakes that have been made by companies which then got fined.  It's a weird mixture of, you know, explaining some stuff that's really, really basic and  then on the other hand, assuming quite a lot of knowledge.  But you know, that is worth a read.  And it includes fairly obvious things like, you know, not patching or updating, not implementing  a suitable contract with a processor, not pen testing, et cetera.  What does help is if you discover a breach and you reported yourself to the ICO rather  than them hearing about it through the media and you take prompt remedial action, then  that is going to help reduce your fine or should help reduce your fine.  And I just wanted to show an example of some of the fines that the ICO has levied over the  past few years.  Sony, PlayStation hack, £250,000, Vulnerability not addressed.  British Pregnancy Advisory Service, £200,000, Automated Tool to Identify Vulnerabilities,  10,000 users' data was kept for five years more than necessary.  This is what I was talking about earlier, deleting unwanted obsolete data.  Admin passwords not stored securely using HTTP instead of HTTPS.  Think W3, £150,000, coding, again, some of the detail is no more than this, coding error  in the login page authentication script.  And a server only intended for internal use was actually open to the internet.  It wasn't pen tested or scanned because it was intended for internal use.  SQL injection, they kept the decryption key for encrypted credit card data on the same  server they got broken into and where the data was.  Worldview, 2014, it was originally going to be fined £75,000 but they reduced it to  £7,500 due to financial hardship.  But SQL injection, password, hash is extracted from a WordPress database, weak admin password,  again keys for encrypted data kept on the same server, no testing, no security testing.  Stature, £175,000, Unpatched JBus application server.  So it is fairly standard security stuff but that can lead to quite big fines from the data  protection front if they're not addressed.  Just to show you, there was very, very little information about the Sony, all the ICO said  was a vulnerability and action required to address the vulnerability even though appropriate  updates were available.  So something was unpatched, don't know what.  So talking a bit about cloud now, if you're using layered cloud, SaaS on top of IaaS or  Paz or Paz on IaaS, then I've mentioned before these mirror contracts that you need from your  cloud provider and maybe even data center provider.  This is actually going to be quite hard to get because, you know, imagine going to Amazon  or Google or Microsoft and saying, right, I want you to sign these contracts where you're  going to take on all these obligations to my customers.  You know, it's going to be very hard to get them to do it.  And so this is actually going to favor the large providers and large cloud customers  rather than SMEs.  And unfortunately, this requirement is going to be enshrined under the data protection  regulation.  International transfers restriction I've talked about before, you can't transfer personal  data outside the EEA to countries without adequate protection unless you use a recognized  mechanism or some derogation or exception applies.  And unfortunately, regulators and courts approach this in a very location-centric way.  They look at data location.  They should be looking at who can access the data, including remotely, how secure is it,  it has been encrypted so people in that country can't actually access it even though it's  physically there.  Which country has effective jurisdiction over those who have access to internal data?  That's what they should be doing, but that's not what they're doing.  They're looking purely at the location of data.  I'm sure a lot of you will have heard about the Shremmers case in the Court of Justice  of the European Union, where one of the mechanisms allowed to export personal data outside the  EEA to the US was known as Safe Harbour.  And the court said, Safe Harbour's dead.  It's not valid.  No time to talk about it now.  I've got a link to a note there.  And also for those in London at the British Computer Society, I'm talking in detail about  what you do after Safe Harbour on the 9th of February.  But this is a big issue.  This is causing organizations to build data centers in Europe.  And of course, that's going to raise costs, and the costs are going to be passed on to  customers.  So in summary for Cloud, it's location, location, location, contracts, contracts, contracts,  encryption, encryption, encryption, and of course backup, backup, backup, but bearing  in mind where you're back up to does impact on the location point.  Cloud laws, unfortunately, are not technology neutral.  They ought to be, but they're not.  And for anybody interested, there's an article on the ways in which it's not technology neutral.  Now of course, there are other areas.  There's no time to go into, but for big data and profiling, anonymization is going to be  a big issue.  If you can anonymize data sufficiently, then you can process it using big data.  You can do profiling, et cetera.  But it is quite difficult.  As I've mentioned, removing names and postcards, et cetera, may not be enough.  With mobile apps, of course, you've got things like location data and biometrics.  With IoT, you've got all of the above, including Cloud, because you might be using Cloud platforms  for IoT.  So they're relevant to lots and lots of areas.  Now of course, there's a question of reality.  Law may say one thing, but a different thing is, can a breach of that law be detected,  and can it be enforced?  Then it can be difficult to detect breaches, and that is why a lot of countries have introduced  breach notification laws, to try and make sure that companies will notify breaches,  although it's difficult to know whether there's evidence that breach notification laws have  actually helped to improve security.  Now in terms of enforcing breaches, individuals are not going to have the resources to sue  large corporations, and large corporations are going to want to defend it because they  don't want a precedent against them.  Data protection authorities may not have resources to detect or enforce breaches.  I mean, here in the UK, the ICO used to be under the Ministry of Justice, and it was  recently moved to the Department of Culture, Media and Sport.  The Cyber Security and Resilience team was moved to the Department of Business and Skills  to the same Department of Culture, Media and Sport, which is all harking back to 1990s  where data protection policy was the responsibility of the Home Office liquor gambling and data  protection unit.  Seriously, that is what it was.  So that's going to be fragmentation of responsibility for data protection, which can't be a good  thing in terms of joined up enforcement.  So practical issues, consults, technology lawyers early, privacy by design, building  in compliance with data protection principles into your systems and your software is going  to be important, privacy engineering.  And in particular, as I've mentioned, data minimization, not retaining data beyond what's  necessary, good security like access controls and logging, data location.  So there is a business opportunity for those involved in privacy enhancing technologies.  And also, of course, for organizations, privacy impact assessments are going to be important,  and what will be called data protection impact assessments in the future.  Building a system or a service or a project in advance during the project as to its compliance  rather than waiting to the end when it's already been built.  Now I wanted to mention a bit about the GDPR, General Data Protection Regulation, which  is going through at the moment.  No time to cover it comprehensively, but there are some videos online on the previous version,  which is still fairly, fairly relevant.  This has gone through the EU legislative process since 2012, and political agreement  was reached between the EU institutions last month.  So actually, it might be adopted the first quarter, second quarter of this year.  There will be a two-year lead time probably before it comes in, and they are going to  be what's known as delegated or implementing acts, where the European Commission can produce  further laws to sort of put flesh on the bones.  Now the intention of the regulation was to strengthen rights for individuals, increase  their control, and for organisations to make it easier for them to do business across the  EU by having one set of rules that applies across the whole EU, and remove some administrative  requirements on those organisations.  However, as the ICO said, being more prescriptive doesn't mean you go to improve data protection,  and I very much fear this is what's going to happen.  It's going to be more prescriptive, but it's not necessarily going to actually help privacy.  Now this, you've heard about the big fines that could be levied under the GDPR.  These are the biggest fines that have been levied by the ICO in the last few years.  2012 is Sony, that's the biggest one.  And you can see that potentially 4% of annual global turnover is the biggest fine under  the regulation.  You can see how much more that is.  And actually, it's not just 4%, it's 4% or 20 million euros if higher.  So it could be way more than that.  For security breaches, it's going to be 2% and 10 million, so not so bad.  But for breaches of fundamental principles, that's what it's going to be.  So if you need to try and get upper management or the board to invest more in data protection  and security, this might help.  And just very rushing through the key changes, it is a regulation, not a directive, which  means it takes effect directly in member states from the date it's supposed to become  law.  But there are two issues with that.  It doesn't necessarily mean there's harmonisation because it can build in room for the manoeuvre.  And the regulation can actually say member states can do this and that on this particular  aspect.  And they have done that here.  Also a regulation could be ambiguous and therefore different member states can interpret  it differently the way they like.  And one of my favourite quotes from Newt Minow, a US lawyer, which illustrates cultural differences  in the EU is this.  He said to paraphrase a bit, in France, everything is permitted except that which is prohibited.  In Germany, everything is prohibited except that which is permitted.  In the Soviet Union, which dates somewhat, everything is prohibited including that which  is permitted.  But in Italy, everything is permitted especially that which is prohibited.  So there are cultural differences in approaches to laws.  I just want to pick out a few points there.  Data portability and erasure, the right to be forgotten as you've heard about it.  You may need to build systems that will allow, make it easier for data structures to get  the data out, to move the data, to delete their data including with third parties.  For controllers and processors, there's an article on SCL.org about processor liability.  But if anybody here is working for a service provider like a cloud provider, you're going  to be on the hook.  You weren't under the directive but under the regulation, if somebody, if there's a  breach and you were involved in the processing, your service was used in providing the overall  service, then somebody who's been harmed by the breach could decide, okay, you have got  the bigger pockets, I'm going to sue you.  Even though it wasn't your fault, you could get done for it and then you'll have to claim  back from, you know, the cloud customer, whoever, really was at fault.  So this is a very important change for service providers.  And for controllers and processors, you could have to look at your contract starting now  in order to try and allocate liability in situations like that.  Not in two years, you could start doing it now.  Information of personal data will be important, including encryption.  There's more emphasis on accountability like information to data subjects, recording and  logging, you know, systems to allow data subjects to get information and to monitor  the processing of their data.  I mentioned earlier about the lack of harmonization.  Somebody called Winford Veal did this diagram showing the areas where different member states  can go their own way.  So, so much for harmonization.  You know, there can be so many national differences.  And I've talked about consent, that it's not always the only legal basis, but if you rely  on consent, then you need to record it properly.  In fact, even now in the UK, under a case called Optical Express, you have to make  sure you've got reliable records of where you got your data from and how you got your  consent if you rely on consent.  Personal consent, you know, where you, where free services are provided on the basis that  the data subject consents to their data being used.  It's difficult to know whether those models are going to survive or how difficult it will  be for those models under the new regulation.  I've mentioned security and the importance of that.  And there will be new requirements for everybody, not just Helcos, to notify breaches to regulators  and in some cases to individuals.  Within 72 hours, we're feasible.  So you're going to have to build in systems that will allow for breach notification.  However, use of certified software or having systems that are under a particular seal or  have got particular codes might actually help if there's a breach.  You can say, well, I've got this certification.  I did my best.  It might help reduce fines.  But these have to be approved by data protection authorities, not just any old certification.  You can't say I've got ISO 27002, whatever.  It has to be something that's approved by the regulators.  So data protection by design and default, I've mentioned before, it's going to be compulsory.  So not just something that's good, you know, a good idea to think about, but you'll have  to do it.  And that includes security by design and default.  Data protection impact assessments will also be compulsory in some situations, going beyond  security and consulting with data protection authorities.  Some organizations are going to have to appoint data protection officers.  International transfers, I've mentioned before, unfortunately, is going to be tightened up  in many ways.  They're not going to modernize the view of access, but they're going to focus still on  physical location from the sounds of it.  And there are going to be different rules on profiling and automated decision-taking which  should affect things like use of AI and machine learning.  So overall, I personally don't think that the GDPR is going to be better for data subjects  because of the lack of harmonization.  Member states can introduce exceptions through the back door.  It is going to have a big impact on cloud computing, big data, et cetera.  And there is a risk that protesters could refuse services to EEA customers, leave the  EEA market, or alternatively, maybe the laws are going to be ignored.  But certainly, the way that the laws are going, they're going to favor large incumbents over  small startups.  I'm not sure that's the intention, but that's going to be the result.  However, for the public sector, they're going to have more flexibility in their processing  of personal data, even though a lot of public sector authorities may have lost personal data,  but they're going to have more flexibility in the processing.  So one question is actually, could the GDPR enable government data protection backdoors,  never mind encryption backdoors?  So please do think about planning ahead.  Two years actually isn't that long in the scheme of things if you need to change the  systems.  If you're a service provider, you're going to be directly liable for the first time,  and so it's really important to think about your contract and similarly for controllers.  There are some places where you can get free IT law advice.  In London, there's Q Legal for startups.  There's Boot Law, which has free meetups.  Own it, mainly intellectual property, rather than IT.  I should say Q Legal is associated with Queen Mary, Boot Law with Princeton Masons.  And of course, with different jurisdictions, they're going to be different places where  you can get free advice.  For legal news, it's affecting technology outlaw.  I've mentioned before, it's associated with Princeton Masons, but it's quite well known  as a good source for non-lawyers about technology law news.  SCL.org, I am on the media board, but it is a very good society for computers and law.  And there are lots of blogs around like IPCAT for IP law, Inform for media law, Panopticon  for information law.  And obviously, standard resources on security are going to be very relevant.  But also, the Article 29 Working Party has a whole raft of opinions.  The Information Commissioner in England has got lots of guidance and a blog, et cetera.  And I'm not going to list them or link to them because you can just go through them.  There's guidance on mobile apps, there's guidance on big data, et cetera, facial recognition.  I'm not going to talk about laws affecting hacking.  I might in the future, if there's demand, but a lot of countries, including here in  the US, have laws which are about accessing systems or data without authority.  And I thought it was important to mention, it's not about whether you have got good  intention to an ethical hacker, it's about whether it was authorized by the company or  not.  So for pentesters, it's very important that the written scope of your authorization that  you get that right.  And if there are other areas that you want to hear about on legal issues, then please  let me know.  So if there's time, then please come, I don't think there is, come and talk to me with  questions, and please do fill in the evaluation or do the evaluation red, green, yellow thing  at the end.  Thank you very much.  So here's my contact details if anybody wants to touch base afterwards.
Legal_pitfalls_for_developers_-_Kuan_Hon_0_71.png Legal_pitfalls_for_developers_-_Kuan_Hon_72_131.png Legal_pitfalls_for_developers_-_Kuan_Hon_132_239.png Legal_pitfalls_for_developers_-_Kuan_Hon_240_1559.png Legal_pitfalls_for_developers_-_Kuan_Hon_1560_2255.png Legal_pitfalls_for_developers_-_Kuan_Hon_2256_2627.png Legal_pitfalls_for_developers_-_Kuan_Hon_2628_2723.png Legal_pitfalls_for_developers_-_Kuan_Hon_2724_5099.png Legal_pitfalls_for_developers_-_Kuan_Hon_5100_5855.png Legal_pitfalls_for_developers_-_Kuan_Hon_5856_7559.png Legal_pitfalls_for_developers_-_Kuan_Hon_7560_8027.png Legal_pitfalls_for_developers_-_Kuan_Hon_8028_8615.png Legal_pitfalls_for_developers_-_Kuan_Hon_8616_8855.png Legal_pitfalls_for_developers_-_Kuan_Hon_8856_10271.png Legal_pitfalls_for_developers_-_Kuan_Hon_10272_12515.png Legal_pitfalls_for_developers_-_Kuan_Hon_12516_12659.png Legal_pitfalls_for_developers_-_Kuan_Hon_12660_12947.png Legal_pitfalls_for_developers_-_Kuan_Hon_12948_13103.png Legal_pitfalls_for_developers_-_Kuan_Hon_13104_13271.png Legal_pitfalls_for_developers_-_Kuan_Hon_13272_13703.png Legal_pitfalls_for_developers_-_Kuan_Hon_13704_14183.png Legal_pitfalls_for_developers_-_Kuan_Hon_14184_15443.png Legal_pitfalls_for_developers_-_Kuan_Hon_15444_15803.png Legal_pitfalls_for_developers_-_Kuan_Hon_15804_18107.png Legal_pitfalls_for_developers_-_Kuan_Hon_18108_20147.png Legal_pitfalls_for_developers_-_Kuan_Hon_20148_20939.png Legal_pitfalls_for_developers_-_Kuan_Hon_20940_21827.png Legal_pitfalls_for_developers_-_Kuan_Hon_21828_22055.png Legal_pitfalls_for_developers_-_Kuan_Hon_22056_23843.png Legal_pitfalls_for_developers_-_Kuan_Hon_23844_24143.png Legal_pitfalls_for_developers_-_Kuan_Hon_24144_27467.png Legal_pitfalls_for_developers_-_Kuan_Hon_27468_30791.png Legal_pitfalls_for_developers_-_Kuan_Hon_30792_32099.png Legal_pitfalls_for_developers_-_Kuan_Hon_32100_32579.png Legal_pitfalls_for_developers_-_Kuan_Hon_32580_34799.png Legal_pitfalls_for_developers_-_Kuan_Hon_34800_35159.png Legal_pitfalls_for_developers_-_Kuan_Hon_35160_38651.png Legal_pitfalls_for_developers_-_Kuan_Hon_38652_40739.png Legal_pitfalls_for_developers_-_Kuan_Hon_40740_42167.png Legal_pitfalls_for_developers_-_Kuan_Hon_42168_42287.png Legal_pitfalls_for_developers_-_Kuan_Hon_42288_43811.png Legal_pitfalls_for_developers_-_Kuan_Hon_43812_44135.png Legal_pitfalls_for_developers_-_Kuan_Hon_44136_44627.png Legal_pitfalls_for_developers_-_Kuan_Hon_44628_45587.png Legal_pitfalls_for_developers_-_Kuan_Hon_45588_45791.png Legal_pitfalls_for_developers_-_Kuan_Hon_45792_46103.png Legal_pitfalls_for_developers_-_Kuan_Hon_46104_48731.png Legal_pitfalls_for_developers_-_Kuan_Hon_48732_49667.png Legal_pitfalls_for_developers_-_Kuan_Hon_49668_51983.png Legal_pitfalls_for_developers_-_Kuan_Hon_51984_54515.png Legal_pitfalls_for_developers_-_Kuan_Hon_54516_55943.png Legal_pitfalls_for_developers_-_Kuan_Hon_55944_56195.png Legal_pitfalls_for_developers_-_Kuan_Hon_56196_57131.png Legal_pitfalls_for_developers_-_Kuan_Hon_57132_57515.png Legal_pitfalls_for_developers_-_Kuan_Hon_57516_59603.png Legal_pitfalls_for_developers_-_Kuan_Hon_59604_63731.png Legal_pitfalls_for_developers_-_Kuan_Hon_63732_65027.png Legal_pitfalls_for_developers_-_Kuan_Hon_65028_65939.png Legal_pitfalls_for_developers_-_Kuan_Hon_65940_67883.png Legal_pitfalls_for_developers_-_Kuan_Hon_67884_69995.png Legal_pitfalls_for_developers_-_Kuan_Hon_69996_70799.png Legal_pitfalls_for_developers_-_Kuan_Hon_70800_71171.png Legal_pitfalls_for_developers_-_Kuan_Hon_71172_71507.png Legal_pitfalls_for_developers_-_Kuan_Hon_71508_71555.png Legal_pitfalls_for_developers_-_Kuan_Hon_71556_71735.png Legal_pitfalls_for_developers_-_Kuan_Hon_71736_73259.png Legal_pitfalls_for_developers_-_Kuan_Hon_73260_75839.png Legal_pitfalls_for_developers_-_Kuan_Hon_75840_76043.png Legal_pitfalls_for_developers_-_Kuan_Hon_76044_76259.png Legal_pitfalls_for_developers_-_Kuan_Hon_76260_79547.png Legal_pitfalls_for_developers_-_Kuan_Hon_79548_80135.png Legal_pitfalls_for_developers_-_Kuan_Hon_80136_80975.png Legal_pitfalls_for_developers_-_Kuan_Hon_80976_82115.png Legal_pitfalls_for_developers_-_Kuan_Hon_82116_83159.png Legal_pitfalls_for_developers_-_Kuan_Hon_83160_84347.png Legal_pitfalls_for_developers_-_Kuan_Hon_84348_84395.png Legal_pitfalls_for_developers_-_Kuan_Hon_84396_84683.png Legal_pitfalls_for_developers_-_Kuan_Hon_84684_85355.png Legal_pitfalls_for_developers_-_Kuan_Hon_85356_86219.png Legal_pitfalls_for_developers_-_Kuan_Hon_86220_87395.png Legal_pitfalls_for_developers_-_Kuan_Hon_87396_91379.png Legal_pitfalls_for_developers_-_Kuan_Hon_91380_91811.png Legal_pitfalls_for_developers_-_Kuan_Hon_91812_95051.png Legal_pitfalls_for_developers_-_Kuan_Hon_95052_96383.png Legal_pitfalls_for_developers_-_Kuan_Hon_96384_96755.png Legal_pitfalls_for_developers_-_Kuan_Hon_96756_97967.png Legal_pitfalls_for_developers_-_Kuan_Hon_97968_98579.png Legal_pitfalls_for_developers_-_Kuan_Hon_98580_99395.png Legal_pitfalls_for_developers_-_Kuan_Hon_99396_99527.png Legal_pitfalls_for_developers_-_Kuan_Hon_99528_99683.png Legal_pitfalls_for_developers_-_Kuan_Hon_99684_99842.png
I'm Kwan Hon, and welcome to Legal Pitfalls for Developers. This is me, four hats, four clouds, and two weasels. I have several hats. I am a lawyer, but I've also got a degree in Computing Science. The other two hats are that I'm a practitioner. I'm a consultant lawyer to a law firm, Pinsen-Masons, but also I'm an academic. I'm a researcher at Queen Mary University of London. I've worked on four cloud law projects, including the Microsoft Cloud Computing Research Centre, which is a collaboration with computer scientists at the Cambridge Computer Lab. I have been the primary author of eight out of the 14 chapters in this cloud computing law book by OUP. The two weasels are that what I say represents my own opinion and not necessarily that of any organisation I'm associated with, and the second weasel is that this is just general information, not legal advice. So the purpose really is to raise awareness of some issues. There's no time to go through everything in detail. It's just so that you're aware of some of the issues you might be coming across. So first, I'm going to talk about law in dealing with lawyers and then some key pitfalls with intellectual property. My main focus is going to be data protection, legal issues, and if there's time for questions at the end, we'll have that otherwise please catch me during a break. Now, as developers with software, these are the main areas I'm going to cover. There could be more, of course, but the main areas are you create software, you use your software, you might allow other people to use your software on certain terms. So in terms of laws and lawyers, I'm just going to go through the laws and what they are, even though it might seem fairly obvious. Laws are just rules that are enforced by the government and backed by the government. So the rules could come from legislation or legal codes. They could be created by judges in common, what's known as common law systems like England and North America, rather than civil law systems which rely more on legal codes and less on the judges. The enforcement systems can include courts, regulators with sanctions such as jails and fines, damages, injunctions, stopping people from doing something or making them do something. Now, the role of contract is very important in law and basically a contract is just an agreement between parties who's going to do what, what happens if they do or if they don't, etc. which the state is willing to enforce. It's just a state backed agreement, but it's important. It's really important to note that each country has laws on the validity of contracts. So just because Alice and Bob agree something doesn't mean it's going to be contract. They're criteria which have to be fulfilled before the law will recognize it as a valid contract that it will enforce. And furthermore, even if the overall contract is valid, there might be some part of it that laws are going to say are not valid, they won't enforce it, they're not legal. For example, there are a lot of laws about protecting consumers against unfair contract terms. So certain terms might be considered unenforceable as against consumers. Even the contract overall is a valid contract. In terms of what, well, I like illiteration, so I phrased it as dues, deals, disputes and decrees. So dues, your rights, what's due to you? IP rights, other rights, there's obviously lots of actors that can be involved, deals, your contracts. Disputes, what happens if things go wrong and decrees or dictates, compliance requirements on you where you have to comply with, for example, requirements on notifying breaches. In terms of the what, there are multiple laws that can apply. So in one situation, you can't just say, oh, well, one law applies to this situation. There are many laws that could apply, including the laws of different states. So different countries' laws could apply to the same situation at the same time. And the way I think of it is for each law, you think about multiple boxes. There's a box for the scope of the law in what circumstances it'll apply. There's a box for exceptions to the law in what circumstances that it not apply. What are the consequences if that law does apply, et cetera? And then you have to look at each box and say, for this particular situation, is it going to fit in that box? And bear in mind that in law, the boundaries for these boxes are fuzzy. And they change. They can get bigger. They can get smaller, et cetera. So that is what makes it difficult. You can have multiple boxes and the boundaries are fuzzy. And then you have to repeat this for every law that might be relevant. It is also particularly difficult because laws are behind technology, for example, copyright law. So basically, this is what lawyers have to deal with. So multiple overlapping boxes where the boundaries are fuzzy and they can change. They can get bigger or smaller. New boxes might be added or taken away. They can change around. And that's why some lawyers get the big box because they have to deal with these sort of complexities. Now, why do you care? Obviously, it's your rights. It's your remedies. But it's also your risk management. You have to manage your legal risk. And the issues for you may be different compared with the issues for your employer or higher. Sometimes you might have opposing interests. So bear in mind they might be different. I'm mostly going to be talking about the issues for your organizations. So managing legal risk, I think of it as a risk pyramid because legal risk affects reputational issues which can affect public trust. And the reality, though, is that organizations don't necessarily comply for the sake of compliance because legal risk is part of the overall business risk. So there might be strategic issues or commercial issues, revenues. Is it practical to comply with particular laws? And organizations balance that against the risks of detection of a breach and forcing the law, one of the sanctions, if it's enforced. So I'm not advocating or advising that you do not comply with laws. No lawyer can do that. But basically, it is up to the organization to make its own decision. And sometimes there are hard choices. An example, not of hard choices but of noncompliance, might be media organizations who deliberately invade the privacy of celebrities to try and get more traffic, sell more newspapers, whatever. And they take the chance that they might get caught and get fined. So another reason why it is important to talk to lawyers is that laws are not necessarily logical. Just because something is logical doesn't mean it's legal. Just because something is illogical doesn't mean you don't have to do it. Sometimes the law requires you to do things which are actually not very logical or not very sensible. And a very important issue, which I don't think many people realize, is that laws don't necessarily mean what they say. You could read a statute, you could read a case from a judge, and you think, oh, yes, this is what it says. But actually, words may have different meanings from what it says on the page because the law says so. The legislation actually defines something particularly. Or a judge has interpreted certain words just to mean something other than what it actually says. So that's a very important point. And also, laws are not always technology neutral. It seems that actually, laws are enforced more harshly against things digital, like with copyright law or website vandalism, than with things in the non-digital world. So the point about using lawyers is that lawyers know about all these peculiarities and idiosyncrasies. They can translate them into practical advice. And of course, you could rely on the insurance policy, perhaps. If they get it wrong, they advise you wrong, you might be able to sue them. Because if you do it yourself and you get it wrong, you're kind of stuck with that. In terms of how, obviously, it always helps to give lawyers lots of money. But really, it's communication and information. That's what's important. And when you're communicating with lawyers, bear in mind that there are different mindsets between technologists and lawyers. So technologists tend to think in binary, in black and white. But lawyers tend to think in analog, in shades of gray. So it is quite, you have to bear this in mind when you're communicating with lawyers, the different mindsets. As far as lawyers are concerned, there isn't such a thing as certainty. That is why lawyers always say it depends. Because it does depend on interpretation, on context, the individual situation, and things are much more a matter of probability than of certainty in law. So in terms of information that you give to your lawyers, you've got to make sure, particularly for deals and projects, you communicate what you're trying to achieve, exactly what you're trying to do, exactly what sort of data you're trying to handle, and how you have to explain the technical model and the business model properly. And it has to be a proper two-way communication. And an important factor, again, to bear in mind when you're communicating with lawyers, is that there is an issue of jargon or terminology. Often, lawyers and technologists can use the same words to mean different things or different words to mean the same things. And then you're going like that instead of like this. And examples I like to use are, from the cloud context, SLAs. Most people here would probably think SLAs means the contract. But actually, to lawyers, SLAs is just one subset of the contract. It's just the service levels bit, not the rest of it, like liability, choice of law, et cetera. And this is a consumer, I mean, NIST says a cloud consumer, whereas to lawyers, that would be the cloud customer. Consumer is the individual end user. Now of course, it is quite difficult because with laws, every country has their own law. The internet is global, but laws are local. So this can cause a lot of problems in this century. And the thing is, even with regional laws like EU directives, EU legislation, et cetera, actually there are differences within individual countries. And then we have things like federal systems, for example, in the US states, Germany with its states, then that makes it even more complicated because they could be different. So you have multiple different jurisdictions to consider, and you have to think about which individual countries or states are relevant to your particular situation. You might think, OK, well, let's put it in the contract to say the laws of England and Wales are going to cover the situation. I want the courts of England to deal with any disputes. But actually, again, like I was saying before, there is an issue of validity. Some contractual clauses may not be valid. So you might say you want, the parties might say we want this law to apply, but the courts will say no, it doesn't. For example, in France, a man sued Facebook, Facebook said it's California law that applies, and the court said no, that's not valid. You can hear the case here in France. So there are mandatory rules in lots of countries which apply here. And there's also another important point, I think, in practice, which is the difference between claimed jurisdiction and effective jurisdiction. So a country might say there is a ban on wearing T-shirts at conferences. But if it's a country on the other side of the world and you're not in there, then they can claim that all they like, but they can't actually apply it to you. And they don't have effective jurisdiction over you. So in terms of countries that are relevant, the factors, I think if this is a target test, it's not a particular rule, it's just the way I put it as a target test. So what's your target market? Which countries are you targeting? That's where you have to be concerned about their laws. Where are you a target? Which countries could target you because they have effective jurisdiction over you because you have physical assets there, people or operations, et cetera. Take for example the EU internet gambling CEOs. They were in transit in the US. And then the moment they were in transit in London and US soil, they were arrested because they had a physical presence there. And the physical connection is very important in lots of laws. Other connections are possible such as an organization being incorporated in a particular country, for example. So it is important to listen to your lawyer's advice, communicate with them properly about where the relevant countries might be and see what they say about which are the most important countries to consider. There's also a question of impossibility, particularly with multinationals. Sometimes if you try to comply with the law of country A, you're breaching the law of country B, and then you have to decide which law to break. So that's a really difficult situation. You do need to talk to your lawyers as soon as possible. It is the false economy to wait. I've done research on cloud contracts and the negotiation of cloud contracts. And I've had in-house lawyers saying to me, look, they are thrown a contract and told, it's going live next week. Just have a quick look and you'll see if there's any legal issues. And that's too late for them to do anything about it if there are going to be legal problems for your company from the contract. So please do remember to involve your legal teams at an early stage. Of course, you need to consult lawyers plus plus or lawyers sharp. You need lawyers who have subject matter expertise, expertise in technology law. You wouldn't want a GP or a bowel surgeon to operate on your brain. And similarly, you wouldn't want a high street practitioner or a general commercial lawyer to advise you on IT law. You also need to consult lawyers who have expertise in the relevant countries because all countries' laws are different. And you want to make sure you get somebody who's going to give you solutions and ways to do things rather than saying no, no, no to everything. So that's just a canter through lawyers. And now talking a bit about intellectual property. Intellectual property rights are property rights of intangible property. But again, they are just government backed rights to control or monopolize the use of intellectual property. And the main ones, I'm sure you've heard of are copyright, patents, database, right, trademarks, et cetera. And again, different countries have slightly different rules on intellectual property rights. When does the right arise? For example, with copyright, it arises automatically once the work is fixed, recorded, written down. Whereas with patents, you have to apply and get your application granted before you have that right. So the scope of the right may differ. The duration, how long you have that right, how is that property right transferred or licensed, et cetera. What acts are restricted? What's considered infringement of copyright? What are the exceptions that are allowed? What acts are allowed and not considered infringement? So of course, you'll all have heard a lot about licensing, permissions to use certain intellectual property. And there's an overlap between licenses and contracts, but they're not technically exactly the same. So for software, let's look at the creation part. Code, you're going to write code, you're going to be in some applications using other content like graphics or music. So who owns software? Well, with code, the main intellectual property rights that are relevant will be copyright and patent. I'm mainly going to talk about copyright because it's the main one. I mean, patents are less common. It is possible to patent software where it's part of a larger thing. You can't patent software as such. And in some countries, it's easier to patent software than others. But copyright is the main thing. So is there a difference if you're an employee or you're a contractor? If you are an employee of a company and you write code, who owns the code? Generally it's going to be your company, not you. If you're a contractor, you're hired to write code for another company. Actually, you will own the code. Even if they paid for it, they don't own the code. You own the code. So they've got to make sure that they do something, put something in the contract to ensure that actually you will assign the ownership of the code to them. So there is a big difference between employees and contractors. And with side projects, if you're an employee and you're doing a side project at your own time, who owns the code? You might find that your employer tries to say it owns the code. What about joint ownership when there's collaborations? If you've got lots of people involved as is common, then actually they might all own the code jointly. And the ownership may not be in proportion to the extent of the contribution. So really what you have to do is make sure that you've got a contract in place at the outset that deals with the things. For example, if you're going to be working for a company, but you know you're going to be doing side projects and you want to make sure you own the code, make sure you put that in the contract. Or if you want some code that you do in your work to be yours and not the companies, make sure that's in the contract at the start. And similarly for companies which are hiring contractors, if they want to make sure they own the code and not the contractor, they've got to make sure they put that in the contract at the start. So I put timing as a very important point. You have to do that at the start. It might be too late to do it afterwards. And again, bear in mind different jurisdictions have slightly different rules. So another aspect, if you are creating software, is could you be infringing other people's rights? For example, if you're using other people's code in your code, and bear in mind that just because code is publicly available doesn't mean that it's free from copyright. Public does not mean free to use. That's an important point under copyright law. Of course, there are also issues if you're using open source code. There could be lots and lots of talks on open source code alone. A small example is if you're using open source code, and you modify it, you're supposed to contribute your modifications back to the community. And there's this question about, well, okay, you take open source code, you modify it, and then you run it in the cloud, offer it as a service. You're not distributing it, so therefore you're not obliged to contribute it back to the community. And that's how the aphero license was born, to try and get around that. It doesn't actually work, but it's trying to do. And bear in mind that even APIs may be copyright. So in the EU, interestingly, again, regional differences, in the EU, the Court of Justice has said that you cannot copyright APIs. However, in the US, the judge initially who actually does some programming said, no, you can't copyright APIs, but then the appeals court said, yes, you can copyright APIs. And the Supreme Court has refused to hear the appeal, so we're kind of stuck with that in the US. So that underlines the point I said where every country, every region may have differences. And there are many ways in which you might risk infringing copyright, for example, not just copying, but modifying, distributing, communicating to the public, et cetera. And it's not just copyright that could be relevant. There are other IP rights like trademark, and there might be other legal rights like data protection. And of course, bear in mind, it's not just your code you have to think about, but anything else you incorporate in your app, like graphics, music, et cetera. There might be intellectual property issues with those that you have to think about. I wanted to say a bit about data ownership. I think it's a fallacy. People keep talking about who owns your data, it's your data, et cetera. Number ownership is just a government-backed rule. Ownership of intellectual property, even physical property, depends on laws. In medieval times, lords owned land, but serfs didn't strictly own land in that same sense. They couldn't. So it's all dependent on the laws as to ownership. So really, with data, you don't own data, you can control the use and dissemination of data through laws like intellectual property law, copyright, et cetera, and other laws might be relevant like confidential information, misuse of private information, et cetera. But practical control is also very important. And as for personal data, I will come to that. So really, with software, there are a number of issues. The main one that I want to concentrate on next is exploiting the software. If you want to make your software available for other people to use. And you might be concerned about your rights and liabilities in this context, which might depend on the channel of distribution. So the model is relevant. Are you licensing? Is it a contract? Are you going to... The method is important. Are you going to be using online terms and conditions? To what extent is that actually enforceable? And what about the channel? Are you going to go through cloud, through app stores, where there might be developer agreements that bind you, et cetera? What's your liability for things like bugs and security holes? What happens if people want to sell their software secondhand? And there's a lot of laws, particularly on protection of consumers. I just mentioned briefly one because it's quite new. Consumers Rights Act came in in the UK a few months ago. It's under a directive which is going to apply across the EU. And it applies to digital content, which is sold to consumers, not just apps or games, but even a website content. If you're delivering a website design, that could be digital content, a supply of digital content. Interestingly, there are fewer rights for the consumers where the service or the sale is for free or personal data rather than when it's paid for with money. And of course, if you're trying to sell your software as a service or on media, there are laws that you'll have to think about which are applying generally like on marketing, advertising, et cetera, what information must you put on your website for consumers, what do you have to put in your emails, et cetera? So not going to go into that. That's all general business stuff. Coming to the use of software internally, where you might be creating software and then using it internally to process personal data or other data and inputting, sorry, and getting output. Well, for developers, it's probably slightly less relevant when you're using software internally because it's mainly the person using the software who will have the risk, whether they're using software produced internally or software that they got from externally. For example, if they use software to process copyright third party material, then they will be at risk there. Or to process personal data, they have to comply with data protection laws. But there are issues like if software is used to process data, where did it come from? Is it properly sourced? Is it legally sourced? And with personal data processing, what happens if the software wasn't properly secure? So another point I want to mention is that the channel matters. The legal issues can actually depend on whether you're using cloud or not. If you've built a SaaS app on PaaS or IaaS, then actually the legal issues may be different from when you're just building an application and deploying and hosting it in your own data centers. Just some examples. For example, with copyright, which countries' laws apply may depend on where the work was recorded or created. So if you're using a server that's in a different country, then maybe the laws of that country may apply rather than your laws. With database rights, sorry, that should say database rather than data. But I've told you briefly about the EU database right. It's a special right created under EU law. Well, it's only an EU right. So again, if you're trying to create a database but you're using a server in the US, do you get an EU database right? So location does matter a lot with law, physical location of servers. Or similarly, if you're running patented software, some countries recognize software patents, some don't. So you're running a software which is actually under a patent. But if you run it in your own country, you might be okay. But if the server you're using it on is in the US or some other country where that software is patented, then maybe you'll be in trouble. So actually the location of your servers again does matter. And of course, with cloud, a lot of people are concerned that the cloud provider has access to your data and there might have to be contractual restrictions. So even if you're using internally the software or app you've created, but you're using a third party provider, PAS or IS, you have to be concerned about the contract with the provider. Normally, the contract is going to be on the provider's own standard terms and you don't have any choice about it. The scope for negotiation is very limited. But there are legal risks, especially with personal data. And I did some research on the negotiation of cloud contracts a few years ago. And the top three issues that came up were liability and disclaimers of the provider, for example, for data integrity or disaster recovery, service level agreements, and security and privacy. So again, another important reason to involve external lawyers early to deal with these issues. And of course, it's not just legal issues that are relevant, practical issues may also be important and they're related. For example, as regards the risk of lock-in or exit. OK, you might put in the contract that there has to be a minimum time period that you get to retrieve your data after the termination of the contract. But also, of course, it's important to test beforehand whether the data and how portable the data is, how can you get it out, how portable is your code, et cetera, to a different platform and to implement backups. If you are using a third-party cloud provider, PAS or IAS, to offer your own SaaS service to your own customers, then you've still got the same issues regarding your contract with the IAS or PAS provider as before. But you have even more issues because, of course, you have the risk of liability to your own customers and you've got your contract, your own customers that you have to think about. And there is a question mark about the viability of these back-to-back contracts with your own cloud provider, maybe with third-party data-centred providers, et cetera. Because if you have certain liability under your contract to your customers, but you can't actually get the same liability sort of back-to-back from your provider, then you are kind of pigging in the middle, you are exposed, but you can't actually claim back from your cloud provider. So again, it is very important to talk to your lawyers about this sort of thing. And now moving to the main area I want to focus on, which is data protection, there are lots of laws on data protection and privacy. Some of them may overlap, but basically there's a whole patchwork. You've got the ePrivacy directive, which is the source of the infamous cookie law. Same focus is the data protection directive, but things like the EU Charter of Fundamental Rights, Convention of Human Rights, cases which have evolved laws on misuse of private information, et cetera. And again, different countries may have different applications. This is an and, not all. I can't emphasize enough. It's not just one law that applies. Many, many laws from many countries could apply to your situation, particularly if it involves the internet. But this overlapping application and liability is important, because if something goes wrong, then whoever is trying to sue you may just pick all the laws they can and throw all of them at you and say, I'm going to sue you under this, under this, under this, under this. So all of them could apply, and they may all need to be considered. Now I want to talk a bit about the cookie law under the ePrivacy directive. It's not just about cookies. It's mainly this directive about communications privacy, such as breach notification requirements for telcos, and again, with national differences. This is, I don't know whether this is, you've seen this. It's fairly well known because there has been a lot of criticism of the cookie law and an organization called SightBeam put out some graphics. This is one of them showing how it doesn't actually necessarily help privacy, but has caused a lot of panic and a lot of money spent. The origins of the law, well-meaning privacy advocates and octogenarian lawmakers who couldn't use a mouse, probably something in that. And to be fair, you could say this doesn't just apply to the cookie law. It could apply to other laws as well. And beyond the EU, for example, in the US, there's been talk about the judges who have to rule in cases about mobile phones and about video games, but they don't even have mobile phones and so on. So there is an issue about lawmakers' understanding of technology, which is quite important because it affects the laws that affect us all. And of course, the fact that it might actually help very, very little people who benefit from a law that tells them a website uses cookies. And even Outlaw, which is a website associated with Princeton Masons, is a technology news website called the Cookie Law, breathtakingly stupid, but it is the law. And I just wanted to clear up some misconceptions about the cookie law because people call it the cookie law, but actually it's not just about cookies or even tracking cookies. It's broader than that. And it's not just about organizations or businesses. Individuals can be caught by the cookie law. It's not just about computers or browsers or websites, but other devices as well. And it's not just about personal data, unlike the Data Protection Directive. It's not just about storing data. It also includes access to data. And it's not just about things happening over the internet. A USB stick with software in it, which could read or access information, that could be caught by the cookie law. And the penalties, well, some people aren't worried about the penalties, but I think they're increasing in Spain. 4,000 euros for a jewelry retail chain. In the Netherlands, 25,000 euros. It was a public service broadcaster. EU regulators, generally, they did a cookie sweep in 2014. So as a result of that, France have actually been in contact with, I think, 20 companies saying you've got to comply with the cookie law. In Belgium, the Belgian Data Protection Authority sued Facebook in court under the cookie law and under data protection laws, and actually won. And you've probably heard about the 250,000 euros a day fine that they were imposing on Facebook before Facebook decided to change their systems. And there are exceptions where the cookie laws do not apply, but they're very, very narrow, like essential cookies, such as a shopping basket or a login cookie. They're very narrow. So really, the cookie law is about stopping storing information or accessing information on the terminal equipment, not just computer, of a user subscriber unless the user subscriber has been given information about what you're doing this for, why you're doing this, and they've consented. So it's not just about cookies and websites. It actually affects mobile apps, IoT, et cetera, et cetera. Maybe consent will be easy to get with an app, something with a signed up form, registration only sites. But there are lots of difficulties with this law, like who's responsible for complying? If you have a website and you use third party analytics or you use a social plug-in, is it you that's responsible for getting consent? Is it the analytics or social plug-in provider who's responsible for getting consent? Even Europa, this is the website of the European institutions, European Commission, Council, et cetera. They've got various pages talking about Google Analytics, but they're quite inconsistent in the way they talk about that. And it's quite interesting that Google, in the middle of last year, about AdSense, they actually, I think some of you might have come across these changes, they actually said, if you are a publisher using AdSense on your website, in your apps, it is your responsibility not theirs to get consent. Now whether that's right or not, difficult to say because if it's your responsibility, then you might, in order to say what the data is being used for, you might have to go into their code and figure out exactly what it's doing and what it's collecting, et cetera, et cetera. So this is quite difficult. So it's a major issue as to how you can comply. How do you get consent? For example, at the strictest extreme, you could have a mobile light box on a website, user can't do anything until they consent, but you pause the cookies so no cookies are set until they consent. Is implied consent sufficient? Is that, in some countries, it might be in others, it won't be. Now there's a lot of guidance that's been issued, including by the Article 29 Working Party, which is EU regulators, data protection regulators collectively, in the UK, the Information Commissioner. They use a tool called Civic Cookie Control, but different countries, there might be different issues. The Interactive Advertising Bureau has produced guidance last year. The Belgian Data Protection Authority, who I mentioned sued Facebook, they recommend social share privacy as a tool for pausing cookies before making sure they're not set until the user consents. Canil, which is the French Data Protection Authority, they use Peewick for analytics rather than Google Analytics because they think, again, that's better. And Europa, the European institutions website, they even have a cookie consent kit on there. So I've compiled some links to tools. It's slightly updated. I haven't a chance to update it properly, so you can have a look at Bitly Cookie Law links if you want. But a difficult and important point to note is actually you've got all these guidance out there, but just because you comply with it doesn't mean you're guaranteed to comply with the law because it may take a court to say exactly what the law means before you know you're compliant. A lot of people have been using banners, but in the Belgian Facebook case, the court said, I don't like the way they've used the banners. Not sure that's good enough. So it is quite difficult. You do need to take advice and you need to look at the practicalities as well. I mean, some of the guidance on cloud, which I haven't put there, but the regulations guidance on cloud is frankly, I think, impossible to comply with. So the Data Protection Directive, this was, this took five years to come through. It was proposed in 1990 and adopted in 1995. It's a directive, not a regulation, which means that it only takes effect as law in a particular country when that country passes national legislation to adopt it into law. And there are differences. For example, mainly what I like to say, with security. In the UK, the Data Protection Law has four lines on security. In Italy, it's about four pages, including stuff on access controls, et cetera, et cetera. So it can be quite different. And this law applies not just to the EU, but also the European Economic Area, EU plus Iceland, Liechtenstein and Norway. And currently there is a draft Data Protection Regulation, which is intended to modernize the laws, but I'll talk about that later. And for those who are interested in the difference between the EU and the EEA, I produce a Venn diagram, EFTR, et cetera, et cetera, bit.ly slash EU hyphen Venn for anybody interested. So this is not to scale, but this is just to show that data protection in the legal sense is not the same as data protection in the IT sense. In the IT sense, data protection might apply to data that's not personal data under the Data Protection Directive. Under the Data Protection Directive, data protection only applies to personal data, but there are technical and organizational security measures that have to be taken in relation to personal data. So there is an overlap, but it's not necessarily the same as IT data protection. And of course, the Data Protection Directive is relevant to lots of areas. Remember this is in addition to the cookie law, not instead of websites, mobile apps, cloud sharing data with third parties, et cetera. So the basic principle is that the Data Protection Directive regulates the processing of personal data with some exceptions such as household use. So your personal address book with the contact details of your friends and family, that's exempt because that's household personal use. Big hole, national security, law enforcement. So it's important to note that processing that's regulated under the Directive is not the same under the legal and IT sense. It's much broader than the IT sense. So in the IT sense, when you talk about processing data, you're talking about compute operations on data. But in the legal sense, when data protection laws talk about processing, it's not just operations on data, but it's also passively storing, holding data. It's transmitting, displaying data, et cetera. It's basically anything that you can do to or with digital data is going to be processing and caught by data protection laws. And data protection laws are supervised by data protection authorities such as the ICO in the UK. It is considered a human right. Data protection is considered a human right in the EU, and so non-EU citizens can also be protected under data protection laws. Now the concept of personal data is central to the application of data protection laws. It is what I call binary and application analog in determination. And what I mean by that is that if something is personal data, then data protection laws apply to it. If it's not personal data, if it's anonymous data or anonymized data, then you don't have to worry about data protection laws. You can ignore them. So that's the binary bit. The analog bit, the shades of gray, is that it's actually quite difficult to decide is this bit of information personal data or not. And you get this strange duality in many laws, not just data protection law. So personal data, what is personal data? It's about a living individual who can be identified from that data or from that data combined with other data. And these individuals are known as data subjects. With anonymous data, as I've said, it's actually not subject to data protection laws, but there is a strange illogicality about encrypted data. Regulators think, well, if you encrypt data, you're protecting it, but you're not anonymizing it. I would argue that encrypted data is anonymous data in the hands of somebody who doesn't have the decryption key, at least as long as it's properly encrypted. But they would say, no, it's still personal data, even though it's encrypted, and the person holding it is still subject to all data protection laws, which to me doesn't make any sense. It should be personal data if you've got the key, but if you don't, it should be treated as anonymous data in my view. And the UK has a fairly similar view, but in continental Europe, it's different. So the concept of personal data is very important, and it's very, very broad. Now, you might think, OK, a name is personal data. John Smith, because it's such a common name, you may not know exactly who that person is without other information. So actually, John Smith may not necessarily be personal data. On the other hand, if you delete names, addresses, et cetera, fields, that doesn't mean it's not personal data, because there might be other information that's left which could identify a person. And a lot of organizations, if they're not sure whether something's personal data or not, they will treat it as personal data, comply with laws in relation to that just in case. But the personal data concept is not the same as the US concept of personally identified information or PII. People tend to use PII in a generic sense, the US influence, but it's not the same. The US concept is different. Who's going to be responsible for complying with data protection laws? It's going to be the controller. The controller is the person who determines the purposes and means of processing personal data. And the controller could be under the hook for complying with data protection laws, even if they're not in the EEA, even if they're an individual, not a company, even if they're a charity. Lots of organizations and types of entities could be caught. And it's the controller who is obliged to comply with data protection laws. And this includes requirements when a controller wants to use a third party processor to help it process personal data, like a service provider, cloud provider in particular, and there's certain rules on security in a written contract that apply if a controller wants to use a processor. The requirements of data protection law basically relate to collecting data, disclosing or sharing data, and using data, personal data, I should say. It's all about personal data and only personal data. So there are a set of basic principles which govern all this. And for what's known as special category sensitive data, like health data, there are even more rules like explicit consent being needed for processing. And data subjects are given write-in remedies. They can go to the controller and ask to access their data. If they need to, they can go to the courts. They can complain to their data protection authority. And these are the data protection principles, fair and lawful processing, purpose limitation. Data minimization is an important one in the technology context. For example, mobile apps over collecting data that they don't need, as Troy Hunt was talking about yesterday. Data accuracy, retention and deletion of data that's no longer needed for its purpose. There have been some companies that have been fined because they retain too much data and that they were hacked. Security is hugely important. There are rights for data subjects to object to direct marketing, rights to correct their data, et cetera, et cetera. There is a restriction which is very important in practice on the transfer, I put it in quotes, of personal data outside the European economic area except to countries with adequate protection. But a very important point to bear in mind, you need a legal basis to process personal data unless you have an exception like national security. And there are many legal basis that could apply, but only a few of them are used in practice, in particular consent and legitimate interests. And as I mentioned earlier, there's even more rules for sensitive personal data. So consent is not enough to process sensitive personal data. You need explicit consent. I just want to mention some myths or fallacies about data protection. Just because personal data is public does not mean that you can process it and not worry about data protection laws. It's like copyright data which is publicly available. So beware that just because personal data is published on a website or on Twitter or Facebook doesn't mean that you can do anything you like with it. Another point is this fixation on consent. Everybody goes on about noticing consent, how do you get consent, blah, blah. That is obviously important in the e-privacy directive, the cookie law. But for the data protection directive, personal data, it's actually not the only legal basis. I mentioned briefly earlier, there are several legal basis that could apply to allow processing in personal data. And in practice, most controllers do not rely on consent. They rely on what's known as legitimate interest. If it's in their legitimate interest to process the personal data, then they are allowed to do that. As long as it's not outweighed by the data subjects, fundamental rights and interests, there's a sort of proportionality test. So for example, if it's too privacy invasive, then the legitimate interest ground cannot apply. Another one is financial data. Some people think financial data is sensitive data. It's not. But interestingly, trade union membership is considered sensitive data. And there have been lots of high profile enforcement actions under EU data protection laws like Sony for the PlayStation hack, Google in relation to Street View Wi-Fi data collection. Privacy policies, interestingly, lots of data protection regulators across the EU actually coordinated their action on this front in discussions with Google. Facebook, lots of regulators, state regulators in Germany have taken action against Facebook. And I've mentioned the Belgian case. Now this is in the UK. The information commissioner has power to issue fines for data protection breaches since 2010. So this shows the fines that have been issued between 2010 and 2015 based on the type of breach, the type of principle. You can see that principle seven has got the most number of fines. Can you guess what principle seven is? Silence, security. You can see it's huge. I mean, security is the main reason. Security breaches are the main reason why companies get fined under data protection laws in the UK. So good security for personal data is good for privacy and compliance. The usual stuff, encryption, you know, app security, et cetera, including cloud security. And conversely, if you have bad security, you might get noncompliance and possibly fines. The ICO has published a document called Learning from the Mistakes of Others where it goes through some of the mistakes that have been made by companies which then got fined. It's a weird mixture of, you know, explaining some stuff that's really, really basic and then on the other hand, assuming quite a lot of knowledge. But you know, that is worth a read. And it includes fairly obvious things like, you know, not patching or updating, not implementing a suitable contract with a processor, not pen testing, et cetera. What does help is if you discover a breach and you reported yourself to the ICO rather than them hearing about it through the media and you take prompt remedial action, then that is going to help reduce your fine or should help reduce your fine. And I just wanted to show an example of some of the fines that the ICO has levied over the past few years. Sony, PlayStation hack, £250,000, Vulnerability not addressed. British Pregnancy Advisory Service, £200,000, Automated Tool to Identify Vulnerabilities, 10,000 users' data was kept for five years more than necessary. This is what I was talking about earlier, deleting unwanted obsolete data. Admin passwords not stored securely using HTTP instead of HTTPS. Think W3, £150,000, coding, again, some of the detail is no more than this, coding error in the login page authentication script. And a server only intended for internal use was actually open to the internet. It wasn't pen tested or scanned because it was intended for internal use. SQL injection, they kept the decryption key for encrypted credit card data on the same server they got broken into and where the data was. Worldview, 2014, it was originally going to be fined £75,000 but they reduced it to £7,500 due to financial hardship. But SQL injection, password, hash is extracted from a WordPress database, weak admin password, again keys for encrypted data kept on the same server, no testing, no security testing. Stature, £175,000, Unpatched JBus application server. So it is fairly standard security stuff but that can lead to quite big fines from the data protection front if they're not addressed. Just to show you, there was very, very little information about the Sony, all the ICO said was a vulnerability and action required to address the vulnerability even though appropriate updates were available. So something was unpatched, don't know what. So talking a bit about cloud now, if you're using layered cloud, SaaS on top of IaaS or Paz or Paz on IaaS, then I've mentioned before these mirror contracts that you need from your cloud provider and maybe even data center provider. This is actually going to be quite hard to get because, you know, imagine going to Amazon or Google or Microsoft and saying, right, I want you to sign these contracts where you're going to take on all these obligations to my customers. You know, it's going to be very hard to get them to do it. And so this is actually going to favor the large providers and large cloud customers rather than SMEs. And unfortunately, this requirement is going to be enshrined under the data protection regulation. International transfers restriction I've talked about before, you can't transfer personal data outside the EEA to countries without adequate protection unless you use a recognized mechanism or some derogation or exception applies. And unfortunately, regulators and courts approach this in a very location-centric way. They look at data location. They should be looking at who can access the data, including remotely, how secure is it, it has been encrypted so people in that country can't actually access it even though it's physically there. Which country has effective jurisdiction over those who have access to internal data? That's what they should be doing, but that's not what they're doing. They're looking purely at the location of data. I'm sure a lot of you will have heard about the Shremmers case in the Court of Justice of the European Union, where one of the mechanisms allowed to export personal data outside the EEA to the US was known as Safe Harbour. And the court said, Safe Harbour's dead. It's not valid. No time to talk about it now. I've got a link to a note there. And also for those in London at the British Computer Society, I'm talking in detail about what you do after Safe Harbour on the 9th of February. But this is a big issue. This is causing organizations to build data centers in Europe. And of course, that's going to raise costs, and the costs are going to be passed on to customers. So in summary for Cloud, it's location, location, location, contracts, contracts, contracts, encryption, encryption, encryption, and of course backup, backup, backup, but bearing in mind where you're back up to does impact on the location point. Cloud laws, unfortunately, are not technology neutral. They ought to be, but they're not. And for anybody interested, there's an article on the ways in which it's not technology neutral. Now of course, there are other areas. There's no time to go into, but for big data and profiling, anonymization is going to be a big issue. If you can anonymize data sufficiently, then you can process it using big data. You can do profiling, et cetera. But it is quite difficult. As I've mentioned, removing names and postcards, et cetera, may not be enough. With mobile apps, of course, you've got things like location data and biometrics. With IoT, you've got all of the above, including Cloud, because you might be using Cloud platforms for IoT. So they're relevant to lots and lots of areas. Now of course, there's a question of reality. Law may say one thing, but a different thing is, can a breach of that law be detected, and can it be enforced? Then it can be difficult to detect breaches, and that is why a lot of countries have introduced breach notification laws, to try and make sure that companies will notify breaches, although it's difficult to know whether there's evidence that breach notification laws have actually helped to improve security. Now in terms of enforcing breaches, individuals are not going to have the resources to sue large corporations, and large corporations are going to want to defend it because they don't want a precedent against them. Data protection authorities may not have resources to detect or enforce breaches. I mean, here in the UK, the ICO used to be under the Ministry of Justice, and it was recently moved to the Department of Culture, Media and Sport. The Cyber Security and Resilience team was moved to the Department of Business and Skills to the same Department of Culture, Media and Sport, which is all harking back to 1990s where data protection policy was the responsibility of the Home Office liquor gambling and data protection unit. Seriously, that is what it was. So that's going to be fragmentation of responsibility for data protection, which can't be a good thing in terms of joined up enforcement. So practical issues, consults, technology lawyers early, privacy by design, building in compliance with data protection principles into your systems and your software is going to be important, privacy engineering. And in particular, as I've mentioned, data minimization, not retaining data beyond what's necessary, good security like access controls and logging, data location. So there is a business opportunity for those involved in privacy enhancing technologies. And also, of course, for organizations, privacy impact assessments are going to be important, and what will be called data protection impact assessments in the future. Building a system or a service or a project in advance during the project as to its compliance rather than waiting to the end when it's already been built. Now I wanted to mention a bit about the GDPR, General Data Protection Regulation, which is going through at the moment. No time to cover it comprehensively, but there are some videos online on the previous version, which is still fairly, fairly relevant. This has gone through the EU legislative process since 2012, and political agreement was reached between the EU institutions last month. So actually, it might be adopted the first quarter, second quarter of this year. There will be a two-year lead time probably before it comes in, and they are going to be what's known as delegated or implementing acts, where the European Commission can produce further laws to sort of put flesh on the bones. Now the intention of the regulation was to strengthen rights for individuals, increase their control, and for organisations to make it easier for them to do business across the EU by having one set of rules that applies across the whole EU, and remove some administrative requirements on those organisations. However, as the ICO said, being more prescriptive doesn't mean you go to improve data protection, and I very much fear this is what's going to happen. It's going to be more prescriptive, but it's not necessarily going to actually help privacy. Now this, you've heard about the big fines that could be levied under the GDPR. These are the biggest fines that have been levied by the ICO in the last few years. 2012 is Sony, that's the biggest one. And you can see that potentially 4% of annual global turnover is the biggest fine under the regulation. You can see how much more that is. And actually, it's not just 4%, it's 4% or 20 million euros if higher. So it could be way more than that. For security breaches, it's going to be 2% and 10 million, so not so bad. But for breaches of fundamental principles, that's what it's going to be. So if you need to try and get upper management or the board to invest more in data protection and security, this might help. And just very rushing through the key changes, it is a regulation, not a directive, which means it takes effect directly in member states from the date it's supposed to become law. But there are two issues with that. It doesn't necessarily mean there's harmonisation because it can build in room for the manoeuvre. And the regulation can actually say member states can do this and that on this particular aspect. And they have done that here. Also a regulation could be ambiguous and therefore different member states can interpret it differently the way they like. And one of my favourite quotes from Newt Minow, a US lawyer, which illustrates cultural differences in the EU is this. He said to paraphrase a bit, in France, everything is permitted except that which is prohibited. In Germany, everything is prohibited except that which is permitted. In the Soviet Union, which dates somewhat, everything is prohibited including that which is permitted. But in Italy, everything is permitted especially that which is prohibited. So there are cultural differences in approaches to laws. I just want to pick out a few points there. Data portability and erasure, the right to be forgotten as you've heard about it. You may need to build systems that will allow, make it easier for data structures to get the data out, to move the data, to delete their data including with third parties. For controllers and processors, there's an article on SCL.org about processor liability. But if anybody here is working for a service provider like a cloud provider, you're going to be on the hook. You weren't under the directive but under the regulation, if somebody, if there's a breach and you were involved in the processing, your service was used in providing the overall service, then somebody who's been harmed by the breach could decide, okay, you have got the bigger pockets, I'm going to sue you. Even though it wasn't your fault, you could get done for it and then you'll have to claim back from, you know, the cloud customer, whoever, really was at fault. So this is a very important change for service providers. And for controllers and processors, you could have to look at your contract starting now in order to try and allocate liability in situations like that. Not in two years, you could start doing it now. Information of personal data will be important, including encryption. There's more emphasis on accountability like information to data subjects, recording and logging, you know, systems to allow data subjects to get information and to monitor the processing of their data. I mentioned earlier about the lack of harmonization. Somebody called Winford Veal did this diagram showing the areas where different member states can go their own way. So, so much for harmonization. You know, there can be so many national differences. And I've talked about consent, that it's not always the only legal basis, but if you rely on consent, then you need to record it properly. In fact, even now in the UK, under a case called Optical Express, you have to make sure you've got reliable records of where you got your data from and how you got your consent if you rely on consent. Personal consent, you know, where you, where free services are provided on the basis that the data subject consents to their data being used. It's difficult to know whether those models are going to survive or how difficult it will be for those models under the new regulation. I've mentioned security and the importance of that. And there will be new requirements for everybody, not just Helcos, to notify breaches to regulators and in some cases to individuals. Within 72 hours, we're feasible. So you're going to have to build in systems that will allow for breach notification. However, use of certified software or having systems that are under a particular seal or have got particular codes might actually help if there's a breach. You can say, well, I've got this certification. I did my best. It might help reduce fines. But these have to be approved by data protection authorities, not just any old certification. You can't say I've got ISO 27002, whatever. It has to be something that's approved by the regulators. So data protection by design and default, I've mentioned before, it's going to be compulsory. So not just something that's good, you know, a good idea to think about, but you'll have to do it. And that includes security by design and default. Data protection impact assessments will also be compulsory in some situations, going beyond security and consulting with data protection authorities. Some organizations are going to have to appoint data protection officers. International transfers, I've mentioned before, unfortunately, is going to be tightened up in many ways. They're not going to modernize the view of access, but they're going to focus still on physical location from the sounds of it. And there are going to be different rules on profiling and automated decision-taking which should affect things like use of AI and machine learning. So overall, I personally don't think that the GDPR is going to be better for data subjects because of the lack of harmonization. Member states can introduce exceptions through the back door. It is going to have a big impact on cloud computing, big data, et cetera. And there is a risk that protesters could refuse services to EEA customers, leave the EEA market, or alternatively, maybe the laws are going to be ignored. But certainly, the way that the laws are going, they're going to favor large incumbents over small startups. I'm not sure that's the intention, but that's going to be the result. However, for the public sector, they're going to have more flexibility in their processing of personal data, even though a lot of public sector authorities may have lost personal data, but they're going to have more flexibility in the processing. So one question is actually, could the GDPR enable government data protection backdoors, never mind encryption backdoors? So please do think about planning ahead. Two years actually isn't that long in the scheme of things if you need to change the systems. If you're a service provider, you're going to be directly liable for the first time, and so it's really important to think about your contract and similarly for controllers. There are some places where you can get free IT law advice. In London, there's Q Legal for startups. There's Boot Law, which has free meetups. Own it, mainly intellectual property, rather than IT. I should say Q Legal is associated with Queen Mary, Boot Law with Princeton Masons. And of course, with different jurisdictions, they're going to be different places where you can get free advice. For legal news, it's affecting technology outlaw. I've mentioned before, it's associated with Princeton Masons, but it's quite well known as a good source for non-lawyers about technology law news. SCL.org, I am on the media board, but it is a very good society for computers and law. And there are lots of blogs around like IPCAT for IP law, Inform for media law, Panopticon for information law. And obviously, standard resources on security are going to be very relevant. But also, the Article 29 Working Party has a whole raft of opinions. The Information Commissioner in England has got lots of guidance and a blog, et cetera. And I'm not going to list them or link to them because you can just go through them. There's guidance on mobile apps, there's guidance on big data, et cetera, facial recognition. I'm not going to talk about laws affecting hacking. I might in the future, if there's demand, but a lot of countries, including here in the US, have laws which are about accessing systems or data without authority. And I thought it was important to mention, it's not about whether you have got good intention to an ethical hacker, it's about whether it was authorized by the company or not. So for pentesters, it's very important that the written scope of your authorization that you get that right. And if there are other areas that you want to hear about on legal issues, then please let me know. So if there's time, then please come, I don't think there is, come and talk to me with questions, and please do fill in the evaluation or do the evaluation red, green, yellow thing at the end. Thank you very much. So here's my contact details if anybody wants to touch base afterwards.
key pitfalls with intellectual property. My main focus is going to be data protection, legal or making them do something. Now, the role of contract terms. So certain terms might be expertise, expertise in technology law. You main intellectual property rights that are getting output. Well, for developers, it's matters. The legal issues can actually depend on some examples. For example, with copyright, which law, not instead of websites, mobile apps, cloud the concept of personal data is central to the comply with laws in relation to that just in personal data is good for privacy and compliance. costs, and the costs are going to be passed on to enforced? Then it can be difficult to detect Data Protection Regulation, which is going differences in the EU is this. He said to requirements for everybody, not just Helcos, to So data protection by design and default, I've Data protection impact assessments will also be resources on security are going to be very