We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Legal pitfalls for developers

00:00

Formal Metadata

Title
Legal pitfalls for developers
Title of Series
Number of Parts
133
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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.
Software developerSoftware developerInformation technology consultingResultantDegree (graph theory)CAN busPhysical lawPoint cloudSelf-organizationInformationComputer scienceCollaborationismAuthorizationProjective planeCloud computingUniverse (mathematics)Context awarenessNeuroinformatikJSONXMLUMLComputer animation
Software developerPhysical lawFocus (optics)HypermediaCodeContent (media)SoftwareFunction (mathematics)Rule of inferenceDesign by contractPhysical systemDigital rights managementValidity (statistics)Civil engineeringRegulator geneTerm (mathematics)Term (mathematics)Physical lawKey (cryptography)Software developerMultiplication signControl flowAreaSoftwareFocus (optics)Information privacyRule of inferenceDesign by contractCivil engineeringPhysical systemInclusion mapState of matterArithmetic meanRegulator geneValidity (statistics)MereologyCodeDifferent (Kate Ryan album)Electronic mailing listInjektivitätRight angleForcing (mathematics)Convex hullOpen sourceQuicksortCodeComputer animation
Software developerPhysical lawInclusion mapException handlingBoundary value problemFuzzy logicPhysical lawCuboidState of matterBoundary value problemException handlingDifferent (Kate Ryan album)Multiplication signQuicksortComplex (psychology)Computer animation
Software developerQuicksortCuboidComplex (psychology)Boundary value problemSelf-organizationRight angleDigital rights managementComputer animation
Software developerDecision theoryNP-hardAxiom of choiceLogicPersonal digital assistantStatuteDigital signalWebsitePhysical lawPoint (geometry)HypermediaStatuteArithmetic meanInformation privacyResultantSelf-organizationDigitizingTerm (mathematics)Decision theoryWebsiteChemical equationWordCASE <Informatik>Web pageMereologyAxiom of choiceComputer animation
Software developerInformationContext awarenessInclusion mapData modelType theoryTelecommunicationDifferent (Kate Ryan album)Noise (electronics)InformationInterpreter (computing)Business modelProjective planeTerm (mathematics)Context awarenessQuicksortPhysical lawEndliche ModelltheorieProper mapComputer animation
Software developerTelecommunicationArithmetic meanLevel (video gaming)Service (economics)WordPoint cloudSubsetTelecommunicationDifferent (Kate Ryan album)National Institute of Standards and TechnologyAxiom of choiceDesign by contractPhysical lawComputer clusterContext awareness
Software developerFaktorenanalyseLocal ringPhysical lawInternetworkingAxiom of choiceSystem programmingState of matterValidity (statistics)Rule of inferenceComputer hardwareOffice suiteOperations researchPoint cloudInternetworkingCASE <Informatik>Forcing (mathematics)Information technology consultingTerm (mathematics)Self-organizationPoint cloudPhysical lawMetropolitan area networkRule of inferenceDesign by contractState of matterPhysical systemConnected spaceDifferent (Kate Ryan album)ArmMoment (mathematics)Software testingFacebookGroup actionLevel (video gaming)Sound effectDirection (geometry)Operator (mathematics)Point (geometry)CAN busControl flowDialectValidity (statistics)Computer animation
Software developerControl flowDesign by contractDatabaseCodeDigital rights managementSoftwareImage registrationCopyright infringementHeat transferException handlingContent (media)Function (mathematics)HypermediaExploit (computer security)Point cloudSource codeDistribution (mathematics)InformationPhysical lawLevel (video gaming)Information technology consultingBitCodeDifferent (Kate Ryan album)Mobile appPoint (geometry)Musical ensembleRule of inferenceMultiplication signPoint cloudNumberRoundness (object)Projective planeArithmetic meanSurfaceOpen sourceRight angleComputer programmingService (economics)Pattern languageSource code1 (number)InformationSoftwareGame controllerCartesian coordinate systemDatabaseMereologyCopyright infringementDesign by contractException handlingContext awarenessExtension (kinesiology)CollaborationismContent (media)DialectComputer animationJSONXML
Software developerHypermediaCodeContent (media)SoftwareFunction (mathematics)WebsiteGame theoryMobile appDigital signalInformation securityPhysical lawData modelDesign by contractCondition numberTerm (mathematics)Point cloudInformationEmailRight angleNumberDistribution (mathematics)SoftwareDesign by contractCondition numberData storage devicePoint cloudExtension (kinesiology)Endliche ModelltheorieTerm (mathematics)Keyboard shortcutPhysical lawService (economics)Content (media)Mobile appWebsite2 (number)InformationDigitizingDirection (geometry)Information securitySoftware bugWebdesignVulnerability (computing)HypermediaComputer animationSource code
CodeContent (media)Function (mathematics)HypermediaExploit (computer security)Software developerSoftwarePoint cloudProcess (computing)Internet service providerStandard deviationTerm (mathematics)Design by contractCloud computingData integrityFrequencyBackupInformation securityInformation privacyData recoverySoftware developerProcess (computing)SoftwareFunction (mathematics)ArmServer (computing)Uniform resource locatorQuicksortDesign by contractTerm (mathematics)Information privacyPoint (geometry)Ferry CorstenMaxima and minimaMobile appMultiplication signStandard deviationSoftware as a servicePoint cloudPhysical lawRadical (chemistry)Information securityInternet service providerCartesian coordinate systemDatabaseComputing platformRight angleCloud computingFrequencyService (economics)PhysicalismTheory of relativityLevel (video gaming)Data integrityData centerOpen sourceComputer clusterAxiom of choiceData recoveryCodeSoftware testingDeterminantGraphics tabletPlastikkarteNoise (electronics)SpacetimeComputer animation
Software developerFocus (optics)Information privacyPhysical lawHTTP cookieOpen sourceFundamental theorem of algebraInformationInformation privacyAreaCartesian coordinate systemCASE <Informatik>Physical lawOpen sourceHTTP cookieFocus (optics)InternetworkingNumberBitDirection (geometry)InformationRight angleProcedural programmingFundamental theorem of algebraJSONComputer animation
Software developerPhysical lawInformation privacyHTTP cookieSound effectElectronic program guideDirection (geometry)TelecommunicationHTTP cookieDifferent (Kate Ryan album)Physical lawBitWebsiteSelf-organizationInformation privacyVideoconferencingCASE <Informatik>ArmVideo gameRule of inferenceComputer animationDiagram
Software developerPhysical lawInternetworkingInformation privacyWebsiteHTTP cookieRule of inferenceException handlingComputerWeb browserData storage deviceSweep line algorithmInformationMobile appImage registrationConsistencyGoogolModal logicControl flowRegulator geneDiagramVenn diagramInformation securityPhysical lawHTTP cookieWebsiteSelf-organizationPersonal identification numberDirection (geometry)Goodness of fitPoint (geometry)Information privacyInformationRadical (chemistry)Order (biology)Plug-in (computing)Web pageDifferent (Kate Ryan album)Sound effectInternet service providerSoftwareImage registrationPoint cloudChainFigurate numberCodeResultantLine (geometry)Regulator geneWeb browserFacebookNeuroinformatikInformation securitySweep line algorithmService (economics)Software development kitBroadcasting (networking)Analytic setPhysical systemException handlingLink (knot theory)Dependent and independent variablesAuthorizationShared memoryVenn diagramArithmetic meanCASE <Informatik>MereologyMultiplication signInternetworkingAreaScaling (geometry)Mobile appGame controllerSign (mathematics)GoogolMathematicsExtreme programmingCuboidAsynchronous Transfer ModeTerminal equipmentComputer animation
Software developerInformation securityWebsitePoint cloudException handlingData transmissionData storage deviceElectronic visual displayDigital filterCoefficient of determinationAnalogyBinary fileLogicPhysical lawGame controllerInclusion mapCoprocessorDesign by contractRule of inferenceVenn diagramInformation privacyMeasurementTheory of relativityInformation securityDirection (geometry)InformationDigital signalCASE <Informatik>HTTP cookieGame controllerCloud computingBitPhysical lawType theoryAddress spaceProcess (computing)Operator (mathematics)CoprocessorView (database)Rule of inferenceService (economics)HookingAnalogyAreaArithmetic meanDeterminantRegulator geneLogicRight angleSimilarity (geometry)Category of beingNeuroinformatikSet (mathematics)Self-organizationAdditionEncryptionMobile WebAuthorizationExistential quantificationCartesian coordinate systemSensitivity analysisFamilyMobile appDescriptive statisticsDuality (mathematics)System callDifferent (Kate Ryan album)WebsiteField (computer science)Exception handlingRadical (chemistry)Binary codeQuicksortKey (cryptography)State of matterInternet service providerDiagramProgram flowchartComputer animation
Information securityBasis <Mathematik>Rule of inferenceProcess (computing)Mobile WebGotcha <Informatik>Software developerGame theoryGame controllerElement (mathematics)Fundamental theorem of algebraGroup actionGoogolFacebookComputer networkGoogle Street ViewInformation privacyRegulator geneHacker (term)Right angleLimit (category theory)Group actionMobile appInformation privacyState of matterPoint (geometry)Direction (geometry)FacebookQuicksortContext awarenessInformation securityMaxima and minimaRule of inferenceProfil (magazine)Basis <Mathematik>CASE <Informatik>WebsitePhysical lawAreaSensitivity analysisSoftware testingTwitterFundamental theorem of algebraGame controllerProcess (computing)Exception handlingElement (mathematics)Theory of relativityPlanningInformationWorkstation <Musikinstrument>Military baseHeat transferGoogle Street ViewGoogolPower (physics)Computer animation
Software developerType theoryGroup actionInformation securityInformation privacyCoding theoryEncryptionBackupPoint cloudPatch (Unix)Design by contractSoftware testingInformationType theoryNumberPower (physics)Information securityInformation privacyGoodness of fitPhysical lawEncryptionDesign by contractMixture modelMobile appPoint cloudOnline helpGroup actionHypermediaReading (process)Software testingProcess (computing)Computer animation
Software developerHash functionError messageLoginWeb pageWebsitePasswordWordDatabaseServer (computing)Sanitary sewerPlastikkarteEncryptionSoftware testingInformation securityPort scannerComputer configurationInformationVulnerability (computing)CryptographyInjektivitätGUI widgetAuthenticationServer (computing)Group actionInformation securityDatabaseAuthenticationVulnerability (computing)WordInternetworkingSequelInjektivitätKey (cryptography)Scripting languageService (economics)PasswordInformationPlastikkarteWorkstation <Musikinstrument>Software testingEncryptionPort scannerCartesian coordinate systemCodeStandard deviationWeb pageRWE DeaAddress spaceSystem administratorInformation privacyLoginError messageSource code
Software developerAdditionComputing platformComputer networkPlastikkarteAuthorizationVulnerability (computing)Game controllerGroup actionAddress spaceInformation securityPasswordSoftwareCloud computingHeat transferTerm (mathematics)Eccentricity (mathematics)Mechanism designInternet service providerProbability density functionPoint cloudEncryptionBackupPhysical lawMobile WebBiostatisticsInclusion mapVulnerability (computing)InformationGroup actionPoint cloudException handlingMechanism designInternet service providerUniform resource locatorDesign by contractPhysical lawBackupRegulator genePoint (geometry)Internet der DingeAreaBiostatisticsHeat transferMultiplication signCASE <Informatik>Cloud computingData centerInformation privacyInformation securityAuthorizationMobile appTerm (mathematics)Software as a serviceBuildingSelf-organizationBitLink (knot theory)Forcing (mathematics)Open sourceDepictionTwitterComputing platformContrast (vision)40 (number)NeuroinformatikWechselseitige InformationBridging (networking)Metric systemCountingPlastikkarteGoogolComputer animation
Statement (computer science)Software developerOffice suiteExecution unitInformationInformation privacyBlogInformation securityEncryptionGoodness of fitTerm (mathematics)Information privacyDependent and independent variablesExecution unitOffice suiteVideoconferencingGame controllerRegulator geneUniform resource locatorRevision controlService (economics)Moment (mathematics)Physical systemSelf-organizationMaxima and minimaProjective planeInformation securityBitBuildingMultiplication signInformation technology consultingSoftwareSource codeXMLComputer animation
Event horizonVideoconferencingSoftware developerControl flowOperations researchState of matterRule of inferenceRight angleRegulator geneMoment (mathematics)BitRule of inferenceMultiplication signProcess (computing)Game controllerRevision controlQuicksortSet (mathematics)Information privacyPhysical lawVideoconferencing2 (number)Self-organizationPressureInsertion lossView (database)Computer animation
Software developerInformationCoprocessorGame controllerEncryptionComputer fileFundamental theorem of algebraWhiteboardInformation securityRegulator geneDigital rights managementInformation privacyMathematicsPortable communications deviceOrder (biology)Service (economics)Process (computing)Right angleDirection (geometry)Different (Kate Ryan album)Internet service providerPhysical lawState of matterDesign by contractPhysical systemBookmark (World Wide Web)Computer clusterHookingPoint (geometry)InformationGame controllerResource allocationRow (database)Point cloudSound effectCoprocessorHarmonic analysisPseudonymizationEncryptionComputer animation
Software developerExpressionConditional probabilityInformation securityRegulator geneSystem programmingCodierung <Programmierung>Default (computer science)Heat transferDecision theoryOpticsInclusion mapPoint cloudProcess (computing)Service (economics)BefehlsprozessorState of matterException handlingPhysical lawGame controllerFreewareBootingHypermediaBlogInformationDifferent (Kate Ryan album)Harmonic analysisAreaState of matterDiagramEncryptionNumbering schemePhysical systemPublic key certificateInformation securityAuthorizationProcess (computing)Basis <Mathematik>Physical lawInformation privacySoftwareInformation technology consultingCASE <Informatik>Regulator geneService (economics)Game controllerPersonal identification numberBootingOpen sourceCodeHypermediaDefault (computer science)NeuroinformatikSelf-organizationGoodness of fitOffice suiteRule of inferenceView (database)Point cloudDesign by contractBlogDecision theoryInformationUniform resource locatorRow (database)Profil (magazine)Machine learningEndliche ModelltheorieAssociative propertyCloud computingUltraviolet photoelectron spectroscopyCondition numberInsertion lossAgreeablenessBackdoor (computing)Virtual machineMusical ensembleInternet service providerFreewareResultantFocus (optics)Heat transfer40 (number)Multiplication signException handlingWhiteboardNoise (electronics)Computer animation
Information securityPhysical lawNewsletterMobile WebMobile appSoftware developerSystem programmingAuthorizationPhysical systemPhysical lawBlogPerformance appraisalPattern recognitionSoftware testingHacker (term)Multiplication signElectronic mailing listAuthorizationInformation securityInformationStandard deviationLink (knot theory)Mobile WebAreaComputer animation
Software developerPublic domainEmailComputer animation
Transcript: English(auto-generated)
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, Pins and 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 Center 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 organization 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 want to talk about law and 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 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 is going to do what, what happens if they do or 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 a contract, there are criteria which have to be fulfilled before the law will recognise 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 alliteration 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 could be involved. Deals, your contracts. Disputes, what happens if things go wrong? And
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 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
does it apply. There's a box for exceptions to the law, in what circumstances does it not apply. What are the consequences if that law does apply etc. 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, etc. 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. There are 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 bucks 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 hirer. 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, commercial issues, revenues, you know, is it practical to comply with particular laws and organizations balance that against the risks of detection of a breach, enforcing the law, what are 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 non-compliance 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. Whereas if you do it yourself and you get it wrong, you know 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. Similarly, 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 with US states, Germany with its state, 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, okay, 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 know, 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, you know, 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. They don't have effective jurisdiction over you. So in terms of countries that are relevant, the fact is, I think 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
the moment they were in transit and landed on 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 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. And 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 counter through laws and lawyers, and now talking a bit about
intellectual property. Intellectual property rights are property rights over 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,
etc. 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 will 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, etc. 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, 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 in 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 company's, 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, you know, 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 deferral license was born, to try and get around that. It doesn't actually work, but it's what I was 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, who, et cetera. Remember, 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. You know, 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? You know, what's your liability for things like bugs and security holes? What happens if people want to sell their software second hand? 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 you know, 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 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'll be at risk there. Or to process personal data, they have to comply with data protection laws. But no, 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 country's 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, PaaS or IaaS, you have to be concerned about the contract with the provider.
Normally, the contract is gonna 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. Okay, 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, PaaS or IaaS, to offer your own SaaS service to your own customers, then you've still got the same issues
regarding your contract with the IaaS or PaaS 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 to 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 center 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 piggy 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 e-privacy directive,
which is the source of the infamous cookie law. Main 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. And this overlapping application and liability is important because if something goes wrong,
then whoever's trying to sue you may just pick all the laws they can and throw all of them at you and say, this, I'm gonna 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 e-privacy 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 fair, 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 Sitebeam put out some graphics. This is one of them showing, you know, 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, you know, there's been talk about the judges who don't, 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 affects us all. And of course, the fact that it might actually help very, very little people, you know, who benefit from a law that tells them a website uses cookies. And even Outlaw, which is a website associated with Pins and Masons, it's 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 you know, 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 it was 20 companies, saying you've got to comply with the cookie law. And 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 or subscriber, unless the user or 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 plugin, is it you that's responsible for getting consent?
Is it the analytics or social plugin provider who's responsible for getting consent? Even Europa, this is the website of the European institutions, European Commission Council, et cetera, and 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's been 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 modal lightbox on a website, user can't do anything until they consent, but you pause the cookies, so no cookies are sent 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 shared privacy as a tool for pausing cookies before making sure they're not sent until the user consents. CNIL, which is the French Data Protection Authority, they use PEWIC for analytics
rather than Google Analytics, because they think, again, that's better. And Europa, the European institution's website, they even have a cookie consent kit on there. So I've compiled some links to tools. It's slightly outdated. I haven't had a chance to update it properly, so you can have a look at bit.ly cookie law links if you want.
But a difficult and important point to note is actually you've got all this 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, hmm, 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 regulators guidance on cloud is frankly I think impossible to comply with.
So the Data Protection Directive, 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,
producer Venn diagram, EFTA, 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 and 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. Also, 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 gonna 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 in 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, okay, 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 on 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 control,
sorry, 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 rights and 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, right 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. And 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 wanted 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 interests 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 legitimate interests 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 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, app security, et cetera,
including cloud security. And conversely, if you have bad security, you might get non-compliance 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 explaining some stuff that's really, really basic,
and then on the other hand, assuming quite a lot of knowledge, but that is worth a read. And it includes fairly obvious things like 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 report it yourself to the ICO
rather than them hearing about it through the media, and you take prompt remedial action, then that is gonna 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 levered over the past few years. Sony, PlayStation hacked £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 W350,000 pounds. Coding, again, some of the detail is no more than this. Coding error in the login page authentication script and 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. World view, 2014. It was originally gonna be fined £75,000 but they reduced it to £7,500
due to financial hardship. But SQL injection, password hashes extracted from a WordPress database, weak admin password. Again, keys for encrypted data kept on the same server. No testing, no security testing. Stasia, £175,000, unpatched JBoss 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 ICOs 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 PaaS or PaaS 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 gonna be quite hard to get because imagine going to Amazon or Google or Microsoft and saying, I want you to sign these contracts where you're gonna take on all these obligations to my customers. It's gonna be very hard to get them to do it.
And so this is actually gonna favor the large providers and large cloud customers rather than SMEs. And unfortunately, this requirement is gonna 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 intelligible 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 Schrems case in the Court of Justice European Union where one of the mechanisms allowed to export personal data outside the EEA to the US was known as Safe Harbor. And the court said, Safe Harbor is 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 Harbor 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 gonna raise costs and the costs are gonna 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 your backup 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 gonna 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 postcodes 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? And 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 that'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 gonna have the resources to sue large corporations. And large corporations are gonna 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 Cybersecurity 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 there's gonna be fragmentation
of responsibility for data protection which can't be a good thing in terms of joined up enforcement. So practical issues, consult technology lawyers early, privacy by design, building in compliance with data protection principles into your systems and your software is gonna 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. Evaluating 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'll be a two year lead time probably before it comes in and they're 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 organizations 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 organizations. However, as the ICO said, being more prescriptive doesn't mean you're going to improve data protection
and I very much fear this is what's gonna happen. It's gonna be more prescriptive but it's not necessarily gonna 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 gonna 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 harmonization because it can build in room for the maneuver. 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 favorite 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 it 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 subjects to get their data out,
to move their data, to delete their data, including the 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 gonna be on the hook. You weren't under the directive, but under the.
The regulation, 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 the cloud customer, whoever, really was at fault.
So this is a very important change for service providers. And for controllers and processors, you're going to have to look at your contract starting now in order to try and allocate liability in situations like that. Not in two years, you're going to start doing it now.
Pseudonymization of personal data will be important, including encryption. There's more emphasis on accountability like information to data subjects, recording and logging 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 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're relying on consent. Conditional consent, you know, 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 telcos, to notify breaches to regulators, and in some cases to individuals within 72 hours where 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 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 they're going to be different rules on profiling and automated decision taking, which could 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 back doors, never mind encryption back doors? So please do think about planning ahead. Two years actually isn't that long in the scheme of things if you need to change your 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 certainly 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 Pins and Masons. And of course, with different jurisdictions, there are going to be different places where you can get free advice. For legal news affecting technology, Outlaw, I've mentioned before, it's associated with Pins and 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, the 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, if you're 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's 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 pen testers, 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 and here's my contact details if anybody wants to touch base afterwards.