[Workshop Homepage] [Position Papers] [Agenda]
General Note:
These minutes only take account of discussions after the presentations. For the presentations see the submitted position-papers and the program. As most of the minute-takers didn't take verbatim minutes, the rapporteur decided to give an aggregate view of the discussions.
The main discussions circuled around the compact format and the preference language. The intense discussions where preceeded by explanations on P3P to those less familiar with the work accomplished until now.
Jeremy Epling was reporting that Microsoft had still a lot of issues with the preferences as the usability questions remain unsolved. They finally decided to provide an APPEL-import function, but were generally unhappy about APPEL. There are too many options, not enough behaviours and generally at least three ways to express the same thing. Günter Karjoth remarked, that APPEL allows only for negative rules which makes things even more complicated as everything is described by negations. Giles Hogben made clear that data protection authorities and other trusted parties will need some way to serve preferences for the P3P enabled browser. The discussion turned into the question, whether XPath would be a convenient way. XPath would at least improve the search facilities of the preference language. Rigo Wenning injected the hypthesis about XQuery, which was directly dissmissed as the complexity of XQuery is not needed in the context of a preference language. Matthias Schunter had doubts. He asked what would be purpose of APPEL. A UI around XPath would be even more complicated and there would be even more ways to express the same thing. It could get arbitrarily complicated like in skin-development. Giles replied that it is all about being to import stuff. There was further discussion on this issue. Matthias noted that in Xpath one could not even compare if two expression are semanticly the same. Giles wanted that some kind of API would be provided.
The further discussion revealed several issues with APPEL:
Jeremy evoked the general complexity of forms and policies and conceeded that it might be useful to announce what data is collected and what is required by a field.
There was a lively discussion about compact policies. Giles suggested in his presentation to remove the compact format from P3P 2.0 because of the many issues it created. Jeremy opened by stating that it was mainly used for performance issues. The significant improvements came from the fact that the compact format would need less round-trips. The following discussion touched all the issues. Giles asked whether IE has an XML-Parser natively included. Jeremy replied that this will be the case and that they will engage in new performance tests. Jeremy promised to report about those performance tests to the existing P3P 1.1 Group. Giles and others around the table said, that it would be impossible to fulfill EU-requirements with the compact format. The lack of granularity persists despite the envisioned 1.1 grouping mechanism. There was also discussion about the fact that people started to serve tokens just to satisfy IE. Those tokens, as they are abstract, generate some incentive to cheat about the real practices just to make the site work. The hidden semantics of the tokens seem to be less visible and touchable for the community than the full XML format. Further debate was delayed until new performance results are available.
Giles presented the trouble with the european understanding of opt-in and that this is done with a checkbox today. It could be semanticly expressed, if we could add some privacy metadata to the Form itself. Rigo noted that part of it is already done in P3P 1.1 and the consent-block clustering.
This opening was followed by a discussion on what consent is. Giles wanted a formal ascent of data being collected, expressed in P3P and signed. Art.29 Working Party needs an objection interface. Matthias reminded that this would need a second data flow of the agreed consent back into the backend. But Giles only thought about using the policy and a some kind of popup to record consent. He centers the ontology around a person and her relation to the environment. Caspar injected further food for thought as the DPA's know also unambiguous consent and explicit consent. The big question is whether this way an agreement for a transfer outside the EU could be reached. Thomas Petri explained the different requirements for the different levels of consent. Marit Hansen added that german law always requires explicit consent, but that the EU-Directive has also different models. Petri added that the difference between those levels is mainly the amount of detail one has to show to the user. Giles concluded that P3P is the place where the system talks about those things and that it has to be implemented here instead of doing browser-popups. The discussion turned shortly to the feasability of negociations. Tomas Sander asked about issues around matching and what feedback is provided, about what is implementable and feasable. Giles explained the past issues with PETs and regulators. Sometimes the practical consequences are not sufficiently taken into account. Steven Adler concluded that this also happens for enterprises. There is a stiff regulation and people don't implement it for liablility reasons Also the technical implications are such that techniciens don't implement something for a whole variety of reasons. The technology should be simple enough to be implemented. Giles reported also that he semantics of such consent could be established in an ontology. The JRC is already working on PRONTO.
Slides in [PPT]
Web site provider has to implement privacy standards reflected in P3P policy. On the other hand the user knows something about his rights - he knows some actions are not allowed. So the user can use P3P to control this. Actually there is a difference between the minimum privacy standard by implementing (basic) P3P and laws. How legally binding are these privacy standards? When the web-site provider applies P3P he promises to apply a minimum legal standard.
Caspar: what minimum privacy standard is actually in P3P.
Thomas Petri: what you say has to be correct.
Jan - there are ncessities like the entity field that fulfill a requirement from the law to disclose the identity of the data controller.
Steven Adler: Is there any law that says the P3P policy has to be aligned to the real practice?
Rigo - P3P doesn't express legal things - only tell you what you do not the legal implications. If P3P was up to the task of being able to articulate a complex legal policy, would regulators be willing to say that a company must be articulated in a machine readable form.
Giles: you can still be consistent.
Steve: where there is an ambiguity, enterprises will always use the most ambiguous policy.
Rigo: P3P doesn't state on every detail. W3C is not a legislator. The legal fact depends on the context. We deliberatly reduced the complexity applied in the current legalese in the human readable policies
Günter: Who would be the authority to say whether this policy would allow access to data or not?
Rigo: Disputes and Access.
Günter (IBM): IF someone violates the policy then who will decide.
Rigo: In an EU-context the semantics of the specification will be interpreted in the court. No challenges have arisen wrt p3p policies yet. There is an official response from w3c to BITs. We have clearly defined semantics for the tokens.
Jan Möller: In countries where a certain privacy protection is required by law, we have to localise P3P policies. For internet surfer. They are used to some basic level of legal standards. If p3p preferences are localised to this legal standard, he can rely on these Localise preference standards. For example - retention - indefinite - this is not possible within Europe or Germany. You have to have a good answer for why you are keeping something. Which options you can and can't use often the datenschutz centrum gets calls from companies. Policy generators should be able to help with these. Restricting certain things depending on the locality.
Steve Adler: The synchronization with enforcement policy and human language policy. So that there is a consistency across how we are articulating the policy. From a linguistic perspective - matching the human launguage with markup language and the actual practice.
Caspar - you shouldnt be able to waive your right to access data. Even in the US. Idea of importing legally compliant preferences should work. You'll know if someone is not compliant with local privacy laws.
Jeremy: IE 6 does support an import of preferences.
Jan Moller: An incentive for companies - this localisation principle gives privacy as a competitive edge - complying with localisation of preferences can act as a type of seal.
Steve. Some american companies might for example decide in that case not to service Swiss clients.
Rigo. There is not feedback loop.
There was consensus that localisation to the European level would be the best idea and that it would cover probably 95%. of the issues.
Jeremy: The crucial issue is what is the return of investment for complanies.
Steve: If the client can give feedback to server what the preferences are - insight about how the company wants us to treat them. Levers are regulation and image. There is no voting machine on the privacy policy. ONly the little red dot at the bottom of the screen. Privacy skin for the day - this is a voting lever.
There was further consensus that this would be nothing achievable in a short time frame as there is no feedback channel. One alternative already mentioned beforehand by Lorrie Cranor are multiple policies on the same resource. There was the remark that also feedback can be privacy invasive which led to the idea of a binary feedback. Jeremy was opposed as it would create just another popup. If such a thing could be integrated, it would have to be integrated in an opt-in opt-out or consent mechanism
There was again consensus that a feedback loop on would be on a very simple level and would require strong requirements on the safe-zone.
Jeremy Epling:: You don't know what the voting with the wallet is based on but is offering specific privacy feedback going to really make purchase choice differences. Sometimes because you only find out too late when you get the form. When you go to Amazon for the first time, you don't want to start with what will happen at the form level, having a general statement about them is a better way.
Steve Adler: individuals have their own mental for users. We can only provide the choices for people to fulfil their own model. The feedback power, is philosophically important.
Caspar: 2 possible uses. Collect statistics for cost benefit calculation. Or offer alternate business processes depending on what people choose. P3P - structural disincentive against them because all the legal incentives are for them to be as vague as possible. In the EU model, the primary driver is to obey the law. Mechanisms for reputation are different in US and EU. In EU there is more likely to be a loss of reputation as a result of a legal breach and EU people are more concerned about the law. Feedback mechanisms thus far have not been used. If they are implemented in a natural way.... Privacy should come out of the box.
Jeremy 100s of hours of user testing - functionality always win over privacy or security. Good deal etc... People block all the cookies and then call Microsoft for support.
Tomas Sander: But there are a minority of users who will make those choices.
Jeremy: process has to be of gradual learning. There are small very defined problems that users deal with. This is a highly vocal market segment.
Steve Adler: The top 25% of privacy aware people are the best customers.
Martijn Zuidweg was invited to have a look at the current draft of the beyond-http-taskforce. There was mainly discussion about the extension of the base-data-schema to not only include a category for location-data but a definition of such data. As there are so many location-data schemes around, this would be a difficult task. Currently there are no suggestions in this directions and nobody in the current P3P 1.1 Specification Working Group is particularly interested in it. This might change with public feedback. Martijn Zuidweg described the privacy challenges in ambient computing environments. The user has to use something else than his mobile because data comes also from elsewhere. Has to be in the platform as one doesn't control all the things around, might be the GSM antenna that holds data.
At the end of the session, it was clear that the main issues are already covered. But it would be worthwhile exploring to extend the data-schema to include more details about location. Especially the exactness of the location determination is of great concern. It might be no issue to know that user A is in country B. But it is nearly always of concern, if the user can be tracked by a few meters. The mapping from the different location-data-schemes to such semantics would be the task of those who implement P3P in location-aware services. The issue is that there are no agreed semantics about privacy and location data. Some data types in P3P would help a lot. It was asked to bring this issue to the P3P 1.1 Specification Working Group. There was also some discussion about using mulitple identies management to solve the issues around ubiquitous computing.
A second issue raised by Martijn Zuidweg was that they need some kind of dynamic preferences. In the context-aware scenario, new data requests arrive and new data from the sensors is generated. The system has to adapt to those requests. That means that preferences have to be context-aware too. There has to be a rule to trigger a dialog or a behaviour if new data is spotted. Jeremy asked if there is a P2P scenario in GSM-like networks. Steven explained that even SMS needs a hub and that this hub can be used to control things. Caspar reported about the perhaps upcoming requirement to mandatory data retention for traffic data. How would the preferences react, location data would be part of it. Thomas Petri confirms that this will generate conflicting requirements. The discussion then turned into the conflict between privacy requirements and mandatory data retention. It was stopped by lunch.
First there was a short presentation by Steve Adler on Tivoli privacy manager to introduce how and why IBM came to create EPAL. There were questions whether this was already implemented in larger organizations, which was confirmed by Steve Adler.
Slides in [PPT]
Slides in [PDF]
Karjoth outlined the choices for enforcing the privacy notice done externally towards the inside:
Change to a new policy takes too long. As a consequence, there is a need for a centralized enforcement infrastructure.
This leads to the desire for a centralized consent and policy management. But what happens if things go wrong? Centralized auditing and reporting do not only help the data commissioner.
In the discussions it came out, that the market driving the adoption of privacy enabled services in the backend will come mainly from e-government trying to share data, from healthcare trying to adopt new technology. Another aspect will be that privacy metadata in the backend will make subject-access a lot more efficient and cheaper. Audit trails could help to resolve employee disputes.
There is a short discussion about how many of the attendants' organizations have P3P policies (only a few) and who really remembers their policy (two). The main point is that only presenting a P3P policy on the border of an organization to its customers is not enough, and there should be some privacy policy enforcement within the organization.
Karjoth started with a citation of Lorrie Cranor: "whatever the website collects can be representedusing broad categories". P3P uses that approach and it is not finegrained enough to be able to steer the backend this way. Karjoth reported that the practical experiences with P3P as an authorization language showed the following issues:
*P3P extension
*Or per-enterprise codification of purposes
*"enterprises want to define their own types"
*Business sector specific categories
A backend system has to welcome the whole picture: Notice, collection of consent, enforcement and audit trails. P3P handles only the notices to the outside world, while it is insufficient for the inside control.
P3P is not considered fine-grained enough for this. This leads to a discussion about P3P predefined purposes.
Steve Adler: Don't define purposes; just define a container which can hold any kind of purpose.
Günther Karjoth added that companies want their sector-specific purposes encoded into the language. They want to define their own types.
Others do want predefined purposes. It is also mentioned that a container
is already present in P3P as other-purpose
. It could also be done
using the P3P extension mechanism, but people thought it would be more
problematic thus creating interoperability issues.
Matthias Schunter: P3P purposes are not about the primary use of the
described data, but only about secondary use, i.e. what are we going to do
with your data besides providing the service you asked for
.
Steve Adler: Big companies do not have just one primary purpose, and they also want to be able to distinguish these primary purposes. This is not possible with the predefined P3P purposes.
Example problem: If we only use current
for describing the primary
purpose, and the data is forwarded to another company for providing the
service, this second company may have quite a different interpretation of
current
.
Jeremy Epling: What about B2B exchange of data, there may be problems with regard to ambiguity in terminology between different business sectors.
Günter Karjoth: We may need sector-specific configurations of the language.
Caspar Bowden: Law or fair information practices will require us to expose the purposes anyway.
Most people agree that clearly defined purposes are necessary. P3P is not fine-grained enough for this. Someone injected the idea that a set of possible purposes could be derived from a reasonably complete ontology.
Thomas Petri and Marit Hansen added, that data protection authorities insist, that the purpose is often a function of the data involved and that it has to be connected to the data.
Jeroen de Rooij from LawIDs, a Dutch company that advises companies on how to implement law on the IT level. He said that every system addressing privacy today has to address the full lifecycle of data: from collection to storage to processing and sharing to deletion.
His main point was that P3P allows for the automated expression of policies, however that there were no technical tools available that help companies privacy protection internally. This may hurt the adoption of P3P. He welcomed EPAL (and the IBM privacy manager) as a step in the right direction. In the follow up discussion there was also a demand articulated for a universal language that allows to model and analyze internal business processes from a privacy point of view.
It was pointed out by the IBM people that EPAL provides rules between two parties how to interact. The question was raised whether centralized management of policies could lead to scalability issues. Several participants made the point that it would be important to enforce privacy policies in a distributed way. Rigo pointed out that it might be beneficial to use RDF as a format inside the EPAL framework as it would ease mixing of different enterprise dialects thus easing also transfer and exchange of data while maintaining the privacy metadata intact.
Slides in [PPT]
Siani Pearson from HP Labs gave a talk on the importance of audit and enforceability of enterprise privacy languages. Audit and enforceability was generally seen as an important aspect of technical solutions to implement good privacy practices. However there was some concerns raised about the particular approach presented, namely the fact that in some of this approach a company could have someone's private information, but were not be able to do with it what it liked; there was a strong parallel to DRM. It was argued that this type of remote control of how data are used might be unfair on companies and could result in legal chaos. On the other it was pointed out that although there was a parallel between DRM and the presented privacy enforcement techniques in the sense that both are concerned with applying rules and policies on how data are used. However there was also a huge number of differences as well, e.g. the completely different threat models in protecting rich media files on end-user machines vs protecting typically smaller sensitive data records within (closed) corporate networks, the completely different ways in which the data are used. Fair use questions, which are some of the major controversial and technically challenging issues in consumer DRM, are also most likely to be completely different enterprise scenarios. In general there was no consensus on the exact way how DRM techniques and privacy policy enforcement techniques in an enterprise should or could relate and this seems to be an interesting open question.
Another issue was whether you could have an analogy of fair use for enterprises, which indeed you could ("fair" uses might also comprise like law enforcement access etc.) This tied into an argument that there might be a lack of flexibility in this approach, and that it's like a switch either being on or off. The counterargument was raised that there is a choice of options both for the user and for the receiver, and it is possible both to update policies and machines, software, etc. As a follow-up to this it was argued that the technology provides a method of tunnelling into another person's machine and stopping them using you data that they have as they want. Siani responded that this was only the case in extreme situations - you could negotiate (aka P3P!) to allow use in different circumstances, or resend the information with a new policy, update the TTP to allow usage in the new circumstances, etc. There was also a question about how data tagging works wrt OIDs; tagging is carried out at the machine level, with the operating system kernel manipulating machine code and making sure that tags (or empty tags) in the form of extendible arrays are associated with data.
After all the discussion introduced by the presentations, the group discussed about possible next steps in the area of privacy. This discussion happened mainly on 20 June.
First the group agreed, that APPEL was not suited for the current needs and challenges that privacy technology faces today. APPEL was seen as too complex on the one hand and lacking certain characteristics on the other hand. Representatives from IBM, JRC, HP and Microsoft agreed that new work on a preferences-language is needed. There was no immediate committment, so the group decided to report back and gather for available resources. The group agreed to continue communication via the P3P mailing-lists and/or the Workshop's mailing-list. Future work on a preferences-language might also start with a requirements document. As a lot of implementations already use APPEL as their import - format for preferences, those APPEL preferences should be transformable to the potential new language.
Secondly, a lot of interest in a privacy and authorization language for the backend was expressed. Concrete requests and hopes about starting work generated reluctant feedback from IBM. Steve Adler wanted to have still more input. The legal clearing inside IBM is still under way and it is open, whether it can be resolved in a timely way. IBM committed to help organizing a Workshop on P3P and Privacy in the backend as a co-located event to the International Conference of the Data Commissioners in Sidney in September 2003. It was agreed that discussions on an initiative about privacy in the backend will continue.
Rigo Wenning (Privacy Activity Lead) 11 July 2003
Last update: $Date: 2003/11/24 10:52:43 $ by $Author: rigo $