Measuring Privacy

Finally got to publish some results...more coming:

The Measurement of Privacy from Ian Oliver

Seminar: Software as a Medical Device

Seminar: Software as a Medical Device:

Safety and security. 

January 5, 9-11 am 

Teaduspargi 6/1, Tallinm, Estonia

Seminar room: Merkuur 

Connected Health cluster presents a practical seminar to help health IT developers and startups plan and manage smoothly their products to comply with needed standards and rules.

9:00 What is a software as a medical device and what is required to get regulatory compliant products on the market - overview of medical device software safety, regulations in EU and US, standards and FDA guidance - Dr. Marion Lepmets, Co-Founder & CEO of SoftComply – 30 min presentation + 15 min Q&A

9:45 Privacy Engineering and Health Data: IT and IoT - Dr. Ian Oliver, Security Specialist at Bell Labs – 30 min presentation + 15 min Q&A

10:30 Discussion and 1-2-1 Q&A

Please register by January 3 the latest: services@tehnopol.ee 

Free for Science Park Tehnopol network and service clients and Connected Health cluster members. 30€ + vat for others.

Privacy Engineering for Today - DIMECC Presentation

Here is my presentation from the DIMECC 9th Annual Seminary on Business innovation in Finland.

Privacy Engineering for Today from Ian Oliver

CrIM'16 Keynote on Safety Critical Ideas in Privacy

Here are the slides and a longer presentation as a paper will be available soon:

Using Safety-Critical Concepts in Privacy Engineering from Ian Oliver

Requirements Engineering and Privacy

A lot of travelling this month to conferences and speaking about privacy engineering (as usual). I just spent a week in Beijing at RE'16 (Requirements Engineering 2016) where I both presented a paper on privacy requirements and participated in a panel session on digitalisation and telecommunications - more on that later.

Anyway, here are the slides from the privacy paper:

Experiences in the Development and Usage of a Privacy Requirements Framework from Ian Oliver

And here is the abstract:

"Any reasonable implementation of privacy requirements can not be made through legal compliance alone. The belief that a software system can be developed without privacy being an integral concept, or that a privacy policy is sufficient as requirements or compliance check is at best dangerous for the users, customers and business involved. While requirements frameworks exist, the specialisation of these into the privacy domain have not been made in such a manner that they unify both the legal and engineering domains. In order to achieve this one must develop ontological structures to aid communication between these domains, provide a commonly acceptable semantics and a framework by which requirements expressed at different levels of abstractness can be linked together and support refinement. An effect of this is to almost completely remove the terms ‘personal data’ and ‘PII’ from common usage and force a deeper understanding of the data and information being processed. Once such a structure is in place - even if just partially or sparsely populated - provides a formal framework by which not only requirements can be obtained, their application (or not) be justified and a proper risk analysis made. This has further advantages in that privacy requirements and their potential implementations can be explored through the software development process and support ideas such as agile methods and ‘DevOps’ rather than being an ‘add-on’ exercise - a privacy impact assessment - poorly executed at inappropriate times."

Ian Oliver (2016) Experiences in the Development and Usage of a Privacy Requirements Framework. Requirements Engineering 2016 (RE'16), Beijing, China, September 12-17, 2016

Privacy Engineering Procedures and Ebola

A seemingly unlikely combination: privacy engineering and ebola, though I guess there are similarities by which viruses spread with how personal data spreads around a company - another time and another study I think.

OK, so what the zark do these things have in common - the answer is via a convoluted path and actually is more related to how we react to an incident: privacy or medical (and we're back to safety-critical systems again).

Bit of background first: I've been reading about Marburg and Ebola recently - both are fascinating (and frightening) themselves, but what is more interesting from a procedural point of view is how they were discovered, researched and ultimately how we as a species react to them.

Ebola (via Wikipedia and CDC)

Now the procedural stuff, the CDC have a response plan for Ebola entitled: Identify, Isolate and Inform: Emergency Department Evaluation and Management for Patients Under Investigation for Ebola Virus Disease.

Worth reading just to understand how the CDC explain how to plan your due diligence - something we're exceptionally bad at in privacy ... we just scream PIA and COMPLIANCE !

The point here is that if privacy engineering is to emerge as a discipline we need to address our culture in how we react to incidents and even react in general. Learning from a discipline that already has to face critical incidents is a good start.

S-Group and Customer Data Collection

Have't written here for a while, but as luck would have it here's a privacy story from Finland.

The supermarket chain S-Group are updating their customer loyalty scheme to make it more relevant for their customers, ie: direct advertising. The basic idea is that they'll make fine grained data collection from the various shops and services in the S-Group. Such data include the specific purchases as well as, of course, time stamps, locations, identity etc.

While various consumer organisations are incensed by this obvious infringement of people's privacy, the danger is really elsewhere.

For a start we have the classic massive data collection from which we can make all kinds of inferences - ostensibly the what, where, when and intriguingly why of consumer purchases. Down this road we see the also classic direct advertising mistakes - you bought milk last week so you'll buy milk this week ... seriously if a supermarket can't work this out without "BigData" then they have problems.

There's also the issue that inferences can have other unforseen effects:

How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did
Kashmir Hill, Forbes
Feb 16, 2012

"Every time you go shopping, you share intimate details about your consumption patterns with retailers. And many of those retailers are studying those details to figure out what you like, what you need, and which coupons are most likely to make you happy. Target, for example, has figured out how to data-mine its way into your womb, to figure out whether you have a baby on the way long before you need to start buying diapers."

That's really going to go down well with the Finnish regulators...

The part that really worry me is where S-Market states that it will keep the data for future usages. As I wrote in Privacy Engineering, any time you see a future use of data this should start alarm bells ringing. It means that you have no clear use case, no clear set of users of that data and are in effect over-collecting data on a whim. Collecting and keeping data for future use is a very high risk activity.

Nothing is mentioned in their literature about security, location of data etc - though I guess the standard "industry standard" answer (Tesco anyone?) will be used. Hint: I worked on those industry standards...they set out some of the base, good practices only.

I constructed a data flow model of as much as I understand about the system at the moment. It isn't much but over each of those flows is going your personal data. The dashed lines represent return data flows, the dashed circles represent "unknown" participants. Question: does this data get sold to 3rd parties?

Inferred DFD

In defence of S-Group they have announced this to all customers of their bonus scheme - though the language is a little flowery in places (did you know that their bonus scheme has won a prize?!).
Details can be found here and here, and you can obtain your data that is held in their customer registry, though I assume not the inferences made from that data. You can see this data from your S-Kanava account; also in writing though only once per year without charge.  You can opt-out whenever you want (though the opt-out is not retroactive as far as I can see) by calling +358 (0)10 76 5858 (calls cost 0.088eur/min - why not free if you were serious about privacy?)

As this scheme is not in operation yet obviously I can't comment on what data I will be able to see and control. I might for myself let it run for a month and then see what data I can get out of the system. I assume I will get the time, location and itemised list of products from every transaction I make; hopefully also the mechanism how I paid the particular cashier (at least till number) and so on.

Another final point is that all bonus money collected by customers is paid to an account in S-Pankki, but that's another story about compliance and interpreting the law.

2nd IW5GS - Programme

The 2nd International Workshop on 5G Security

IW5GS2016

Xi'an, China

June 19, 2016

http://www.mobimedia.org/2016/show/program-final

IW5GS-01: (June 19, 2016, Sunday, 10: 30 – 12:30, Room B)

Session Chair: Valtteri Niemi (Email: valtteri.niemi@helsinki.fi)

Keynote 1: 5G Security for IoT

Speaker: Dr. Zhiyuan Hu, Nokia Shanghai Bell  (zhiyuan.hu@alcatel-sbell.com.cn)

Keynote 2: 5G Security: Forward Thinking

Speaker: Bo Zhang, Huawei (liufei19@huawei.com)

IW5GS-02: (June 19, 2016, Sunday, 14: 00 – 16:30, Room B)

Session Chair: Siddharth Prakash Rao (Siddharth.rao@aalto.fi); Ian Oliver (ian.oliver@nokia.com)

Paper 1: Protecting IMSI and User Privacy in 5G Networks

Karl Norrman, Elena Dubrova, Mats Näslund

Paper 2: Privacy of the Long-Term Identities in Cellular Networks

Philip Ginzboorg, Valtteri Niemi

Paper 3: Error-Correcting Message Authentication for 5G

Elena Dubrova, Mats Näslund, Göran Selander, Karl Norrman

Paper 4: Privacy in LTE networks

Siddharth Prakash Rao, Bhanu Teja Kotte, Silke Holtmanns

Paper 5: A Survey on Software-Defined Networking Security

Shanshan Bian, Peng Zhang, Zheng Yan

Paper 6: Designing Hybrid Cloud Computing Framework using OpenStack for Supporting Multimedia with Security and Privacy

Isaac Cushman, Lei Chen, Danda B. Rawat, and Nhien-An Le-Khac

Agile is dead

This is an excellent post, though some might consider it a rant, about how Agile wasn't really nor became what Agile should it should have...

Agile is Dead

"Are you an IT consultant or contractor? Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money. Soon recruiters will be putting your resume in the circular storage container. I have been warning you for some time, and the day is here. Hah, you should have listened. Move along."

But here's the best quote:

The moral of this part of the story is that if you produce some compact politicised ideology (manifesto) consisting of principles and rules there will be unintended consequences.  Success creates a religion or cult, and defeat is being ignored.  No such doctrine is perfect.  Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.

To me, given the problems that Privacy by Design has caused with privacy officers believing in some mythical "compliance" without any consideration of the software engineering or cultural aspects of developing information systems, this sums it up quite nicely!

Privacy Lectures @ University of Iowa

I'm giving two lectures at the University of Iowa on the 21st and 22nd of April as part of the Iowa Informatics Showcase Symposium.

The two lectures are:

• The Fundamentals of Privacy Engineering ( April 21 )
• From Where Comes Privacy ( April 22 )

The Iowa Informatics Showcase Symposium will focus on new directions in informatics research and involve talks from external and internal scholars. It will also include an informatics fair with a poster session, and booths highlighting research centers, core facilities, centers and institutes. Saturday Workshops will be conducted as part of the symposium with topics including software basics, GIS, mapping and visualization, statistical packages, and others.

Short abstract on privacy processes

Any reasonable implementation of privacy requirements can not be made through legal compliance alone. The belief that a software system can be developed without privacy being an integral engineering  concept and that a privacy policy is sufficient as requirements or compliance check is at best dangerous for the users, customers and business involved.

While requirements frameworks exist, the specialisation of these into the privacy domain have not been made in such a manner that they unify both the legal and engineering domains. In order to achieve this one must develop terminological or ontological structures to aid communication between these domains, provide a commonly acceptable semantics and a framework by which requirements expressed at different levels of abstractness can be linked together to provide refinement of these in some form. One interesting effect of this is to almost completely remove the terms ‘personal data’ and ‘PII’ from common usage and to force a deeper understanding of the data and information being processed.

Once such a structure is in place and even just partially or sparsely populated this provides a formal framework by which not only requirements can be obtained, their application (or not) be justified and a proper risk analysis made. This has further advantages in that privacy requirements and their potential implementations can be explored through the software development process supporting ideas such as agile methods and ‘DevOps’ rather than being an ‘add-on’ exercise - a privacy impact assessment - inappropriately executed at inappropriate times.

Thinking about Grothendieck

On n-Category Cafe is a post by John Baez linking to a short article on the late, great mathematician (and human being by all accounts) Alexander Grothendieck written by Barry Mazur.

I want to quote from that paper because I think the statement here is fundamental to everything we do, particularly in engineering and mathematics, be it category theory, trying to model the information flows in a system to better understand privacy or even linking privacy engineering with the legal aspects (emphasis mine):

The mathematical talks I had with him—as I remember them now—were largely, perhaps only, about viewpoint, never about specifics (with the exception of a conversation about differential structures on conjugate complexifications of an algebraic variety over a number field). Grothendieck’s message was clear throughout: that everything important will follow easily, will flow, from the right vantage. It was principally ‘the right vantage,’ a way of seeing mathematics, that he sought, and perhaps only on a lesser level, its by-products. 

DSummit, Stockholm, May 2016

One for the CEOs, CIOs and CxOs of the world. This year DSummit is in Stockholm on 26th-27th May and has an impressive array of speakers and a strong focus on #privacy engineering!

"Disruptology is the art and science behind disruption. We study disruption and its impact on business and society. With a network of change makers, technology moguls and innovation evangelists we assist companies of all sizes with guidance, advisory and resources to become true disruptors. As an non profit academic institution and research foundation, Disruptology is a pioneer of new and disruptive business models, such as the F2W free-to-win model. With a vast network of industry professionals on call, we are able to inject new ways of thinking, working and playing into the DNA of companies throughout the world."

Tickets can be bought here: https://www.tickettailor.com/checkout/view-event/id/38963/chk/1862/ref/ian-oliver

And further details of the event here: http://www.dsummit.net/

Engineers for Privacy Professionals

As many discussions on this blog have pointed out, there is a mismatch between engineering and legal when it comes to privacy; one can even argue there's a mismatch between these two groups and privacy advocates too, but that's another story...

It is critical for anyone involved in privacy to understand that without the complete trust and involvement of the engineers who build the systems that are supposed to be compliant with whatever privacy policy exists, that compliance will be at best, fragile.

At the IAPP's DPIntensive meeting earlier this year I gave a presentation on the subject, here's the link to the slides.

Engineering Privacy Engineering from Ian Oliver

The main learning is that unless engineering is an equal part in your privacy discussions then you're really just playing at compliance.

Privacy isn't just about privacy policies or long winded legal documents but about education, learning and understanding that everyone depends upon everyone else in order for your business to successfully (and legally!) function.

I wrote about how privacy should be taught earlier with the quote:

It often surprises me that many of the people advocating privacy don't actually understand the things that they're trying to keep private, specifically information. Indeed the terms data and information are used interchangeably and there is often little understanding of the actual nature and semantics of said, data and information.

This is also seen in how we train our staff in privacy aspects - with the dreaded "privacy awareness training":

One thing that came up was the need for training and that privacy awareness training hasn't had the effect hoped for. Given that awareness training is exactly that, is it no surprise that once the, usually, one hour presentation on how we should all care about privacy is made nothing happens?

 
Actually, everyone is acutely aware of privacy in the first place and privacy awareness training rapidly becomes an exercise in CYA - as security expert Bruce Schneier might have put it - and have no effect whatsoever on the overall quality of development, customer privacy and company culture.

I guess we're still pretty naive about privacy and unless we have a cultural change this naivety will come back to haunt us for a very, very long time with some awful business repercussions.

Twitter Discussion on Privacy and Engineering

Related with the upcoming DSummit conference in Malmö in May I've been involved in a fascinating discussion on Twitter with some of the big privacy people there.

The main point being raised is the need for a proper dialog between engineers and lawyers. I think we've seen this before, but still it is not being properly addressed and until it is privacy will remain a compliance activity rooted in a tick-box mentality with dreadful repercussions.

One only needs to take a look at the potential penalties in the EU's GDPR ... a potential fine of 4% of global turnover for a privacy violation!

The crux of this is that if you want to construct systems with privacy as an aspect, it has to be a first class aspect of that system's design. That means privacy is under the collective responsibility of lawyers, engineers and management and not the sole preserve of any of these groups.

Belief in high-level privacy impact assessments and "compliance", and placing trust in a legalese privacy policy is woefully insufficient, not to mention from a business perspective one step short of insanity.

Unfortunately going beyond this is considered by some - and I've seen too many examples of this - to be difficult and unnecessary and that legal compliance - whatever that means - is enough...

As we move to a "BigData" future, the knowledge of basic data handling, quality and governance at both engineering and legal levels is critical - not just for privacy but for basic business reasons, including consumer trust and quality of product.

How to do this is not difficult, but it does require thinking and small, but extremely beneficial cultural change...

Agreed. Need to translate high level privacy principles & PbD, into specific engineering reqs @mdennedy @i_j_oliver https://t.co/a4hgcUhGnJ

— Privacy Matters (@PrivacyMatters) December 20, 2015

and here's a recommendation to get those principles into use:

@daraghobrien I found @i_j_oliver's and @mdennedy's books on privacy engineering of enormous value @ll1t

— Privacy Matters (@PrivacyMatters) December 21, 2015

You can start here:Privacy Engineering and A Privacy Engineer's Manifesto

More Data Breach Excuses

This particular case reported on the BBC has a nice excuse...

Adele tickets: Fans claim personal data has been breachedBy Mark SavageMusic reporterFans buying tickets for Adele's tour have told the BBC they were shown the address and credit card details of customers other than themselves.
But several fans said they saw other people's shopping baskets, including payment details, upon check out.
Ticketing company Songkick said due to the "extreme load" on the site some customers could see others' account details. It apologised for any "alarm".
"At no time was anyone able to access another person's password, nor their payment or credit card details (which are not retained by Songkick)," it said.

So let's go through this and start with the last paragraph which states that no-one was able to access another person's password nor their payment or credit card details, yet, in the first paragraph it states that people were able to see payment details. 

I assume it means that the full credit card number, expiry date and CVC number were not available, however whoever makes these statements really needs to check with the engineers and really understand what they are being told.

The one I particularly like is that these errors happened due to "extreme load". Which suggests that the underlying system - UI, middleware, database etc were not implemented with concurrency in mind. 

I could imaging that the system probably wasn't load tested and/or that probably someone didn't use BASIC TRANSACTIONS which are present in, well, all databases - it has been part of the SQL standard for years and years. 

Worse is that someone probably tried to reinvent transactions or semaphores in an inherently distributed system and failed. Probably the system only worked up until now because various race conditions had never materialised - not even in testing - assuming that the tests had been properly created.

I can also imagine that the developers were rushed and probably forced to use some new technology that they didn't understand and that some manager somewhere had probably read an article about NoSQL and demanded that everything become a bizarre mix of Java, Clojure, Python, Ruby, XML, JSON, MongoDB and whatever web framework is currently in vogue.

Of course, at the end of the day it will be the engineers' fault ... which fails to address the issue of how such a system got signed off in the first place, let along from where came the requirements.

Furthermore I can imagine that testing was skipped or done badly because of a manager's false idea of what agile is...

So what we have here is a simple system that fails because of a misunderstanding of technology, non-functional requirements and most likely mis-management. I'd be willing to wager on that if we as engineers actually performed proper post-mortems or accident analyses on system failures instead of being forced to patch them up.

Ironically if they'd written in it COBOL it would all have worked fine... :-)

ABCDE....DevOps and Privacy, pt 2

Earlier I introduced the idea that DevOps, particularly in the area of privacy could take lessons from trauma medicine, particularly in taking on board ideas from ATLS.

This led to some further ideas about the relationships or analogies between disciplines - something we've already discussed before in the context of surgery, aviation and checklists.

As software engineering is being brought closer and closer to the metaphorical coal-face - we've moved away from requirements up-front to agile and now to "DevOps" where engineering and operations become the same thing we are starting to see the need to move to much more structured and disciplined teams of engineers. If this isn't happening then there are some serious cultural and management problems.

As this shift happens we have to develop techniques to deal with this - as already mentioned checklists and ATLS provide the necessary kind of structures.

By why ATLS in particular? Well, we can draw an analogy between DevOps and trauma medicine in that DevOps operates with extremely short time-scales and in an environment where fixes and patches need to be very quick and leave the system in a stable state where a longer-term patch can be made later.

DevOps is the ER of the software engineering world.

DevOps and the ABC(DE[FG]) of Privacy

Or maybe this should be called the ATLS of privacy perhaps?  ATLS, or Advanced Trauma Life Support is a training programme for dealing with medical trauma incidents and is typically used by first responders such as paramedics to an incident.

Now as we move to a DevOps oriented model - think of a highly integrated Agile with a "right now" delivery timescale - then the way we will have to react to compliance, privacy impact assessments, privacy engineering etc is going to be on the same kind of time-scale. Certainly if we are late or delayed with the PIA then the product is going to be shipped - with some interesting security and privacy consequences certainly!

So, I conjecture it makes sense that we bring our PIA/compliance activities not just to the engineering level but also to the speed of development and operations.

This means that the PIA is going to have to be extremely focused and very strictly run. Effectively we need the DevOps privacy version of the medical ABC.

The question then becomes what is the equivalent to the medical ABC?

As I've stated before, privacy can [must] learn a lot of things from medicine (and aviation) - such as checklists - in that they both work in very agile, unstructured and reactive environments. Privacy in a DevOps situation can not rely upon traditional compliance or work at the usual, relative glacial speed associated with such work.

References

Ian Oliver (2015). Privacy as a Safety Critical Concept. 1st International Workshop on Privacy Engineering. California. (Keynote Talk)

Ian Oliver (2014). Privacy Engineering: A Data Flow and Ontological Approach. CreateSpace. 978-1497569713 (see: http://www.amazon.co.uk/dp/1497569710  )

Second International Workshop on Privacy Engineering (IWPE'16)

Second International Workshop on Privacy Engineering (IWPE'16)
Co-located with 37th IEEE Symposium on Security and Privacy

26 May 2016 - The Fairmont, San Jose, CA

************************************************************

IMPORTANT DATES

Deadline for abstract submission: 18 January 2016
Deadline for paper submission: 8 February 2016
Notification of acceptance: 22 February 2016
Accepted paper camera-ready: 3 March 2016 

************************************************************
 
We are pleased to invite you to participate in the Second International Workshop on Privacy Engineering (IWPE'16).

Privacy engineering research has never been a more timely endeavor. Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide are seeking to strengthen individuals’ privacy by introducing legal and organizational frameworks that personal data collectors and processors must follow. As a result, engineers are increasingly expected to build and maintain systems that preserve privacy and comply with data protection standards in different ICT domains (such as health, energy, transportation, social computing, law enforcement, and public services) and on different infrastructures and architectures (such as cloud, grid, or mobile computing).

Although there is a consensus on the benefits of an engineering approach to privacy, few concrete proposals exist for models, methodologies, techniques and tools to support engineers and organizations in this endeavor. Work that focuses on helping organizations and software developers to identify and adopt appropriate privacy engineering methods, techniques and tools in their daily practices is also missing. Furthermore, it is difficult to systematically evaluate whether the systems developed using privacy engineering methodologies comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements.

Clearly, more research is needed in developing methods that can help translate legal and normative concepts, as well as user expectations, into systems requirements. There is also a growing need for techniques and tools to support organizations and engineers in developing and maintaining (socio-)technical systems that meet these requirements. In an effort to close the gaps in research, the topics of IWPE'16 include all aspects of privacy engineering, ranging from its theoretical foundations, engineering approaches and support infrastructures to its practical application in projects of different scales.

Specifically, we are seeking the following kinds of papers:

1.  technical solution papers that illustrate a novel formalism, method or other research finding with preliminary evaluation;
2.  experience and practice papers that describe a case study, challenge or lessons learned in a specific domain;
3.  early evaluations of tools and techniques that support engineering tasks in privacy requirements, design, implementation, testing, etc.;
4.  interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods and frameworks; 
5.  vision papers that take a clear position informed by evidence based on a thorough literature review.

IWPE’16 welcomes papers that focus on novel solutions based on recent developments in privacy engineering. Topics of interest include, but are not limited to:

• Integrating law and policy compliance into the development process
• Privacy impact assessment during software development
• Privacy risk management models
• Privacy breach recovery methods
• Technical standards, heuristics and best practices for privacy engineering
• Privacy engineering in technical standards
• Privacy requirements elicitation and analysis methods
• User privacy and data protection requirements
• Management of privacy requirements with other system requirements
• Privacy requirements implementation
• Privacy engineering strategies and design patterns
• Privacy-preserving architectures
• Privacy engineering and databases
• Privacy engineering in the context of interaction design and usability
• Privacy testing and evaluation methods
• Validation and verification of privacy requirements
• Engineering of Privacy Enhancing Technologies (PETs)
• Integration of PETs into systems
• Models and approaches for the verification of privacy properties
• Tools and formal languages supporting privacy engineering
• Teaching and training privacy engineering
• Adaptations of privacy engineering into specific software development processes
• Pilots and real-world applications
• Evaluation of privacy engineering methods, technologies and tools
• Privacy engineering and accountability
• Organizational, legal, political and economic aspects of privacy engineering

This topic list is not meant to be exhaustive, as IWPE'16 is interested in all aspects of privacy engineering. However, to screen out off-topic papers early in the review process, we request authors to submit an abstract prior to their paper submission. Abstracts of papers without a clear application to privacy engineering will be considered outside the scope of this workshop and may be rejected.

************************************************************

PAPER FORMAT & SUBMISSION GUIDELINES

We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper.

Abstracts and papers must be submitted via EasyChair

All IWPE'16 Papers will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus, etc.

Privacy Engineering Tutorial Slides (TrustCom)

Here are the publicly released slides from my privacy engineering tutorial given at TrustCom 2015 in Helsinki earlier this year.

 

Privacy Engineering Tutorial (TrustCom2015) from Ian Oliver

The slides should be used in conjunction with the book - Privacy Engineering: a Data Flow and Ontological Approach - supporting this.

NB: I notice there are some formatting errors in the slides - this seems to come from SlideShare's conversion algorithm as the original PDF appears to be fine. 

The full session also included talks by Jonathan Fox (Intel/MacAfee) and Antti Vähä-Sipiliä (F-Secure)

 

Privacy Engineering Tutorial (TrustCom2015) - Opening Slides from Ian Oliver