The article "A Roadmap for Comprehensive Online Privacy Policy Management" by Annie I. Antón et al. (July 2007) provided a nice framework, but its discussion of the Platform for Privacy Preferences (P3P) needs clarification. For one thing, it said "The P3P language does not have a clear semantics and can therefore be interpreted and presented differently by different user agents." Though true that the P3P specification does not include a formal semantics, it does include natural language definitions for all P3P tokens; moreover, these definitions are intended for use by the people who set policy, not by end users. Therefore, user-agent developers must translate the definitions into statements that are meaningful to users.
While the P3P 1.1 specification includes suggested English phrases that can be presented to end users, the original P3P 1.0 specification included minimal guidance on the user interface. As a result, considerable differences exist among the approaches taken in each user agent. One popular agent is known to contain a bug that causes it to omit information in the way it presents P3P policies to users. A formal semantics (such as one proposed by the authors in a cited technical report) is valuable but does not address the problem of how to present policies in a user-friendly way or prevent buggy user agents.
They cited a CitiGroup position paper as evidence of the need for a formal semantics (see www.w3.org/2002/p3p-ws/pp/citigroup.html) but quoted from two different parts of the paper and used it somewhat out of context. The paper argued that natural language policies, not P3P policies, should be considered legally binding, that P3P policies should allow for the inclusion of more caveats like those in natural language policies, and that the World Wide Web Consortium should find a way to ensure that P3P user agents comply with the specification.
Antón et al. claimed that "a policy specified in P3P may be internally inconsistent," citing a related tech report. Most of the example inconsistencies in the report were actually plausible policy statements. For example, they said that data retention values must be mutually exclusive; that is, a particular data element cannot be retained for both a fixed amount of time and indefinitely. However, P3P allows organizations to discuss multiple databases in a single policy. Thus, a data element might be collected by one department in an organization and discarded immediately after its use, while another department in the same organization independently collects the same data element and retains it indefinitely.
Antón et al. said "the expressive power of P3P is limited," listing natural language privacy policy statements they claimed could not be expressed in P3P. With the exception of security mechanisms, all the examples they gave can be expressed in P3P.
They also said that "natural language privacy policies cover a much broader scope of an enterprise’s privacy practices than P3P policies." P3P provides considerable flexibility as to the scope of the practices an enterprise might wish to cover. Many enterprises create P3P policies covering most or all of the practices included in their natural language policies.
Finally, they said "Currently, only textual policies are legally binding for an enterprise." Based on discussions with regulators from around the world (I chaired the P3P Specification Working Group), it is likely that courts in most jurisdictions would find statements made in a P3P policy to be as legally binding as the corresponding textual policies.
Lorrie Cranor
Pittsburgh, PA
Authors’ Response:
In our article, we proposed a comprehensive architectural framework supporting the entire privacy policy life cycle; it was not specific to P3P, even though P3P lacks a formal semantics to enable one to verify the correctness of an agent. The objective should be to make it possible to automatically verify that P3P user agents comply with the specification. As for the counterexample we cited, an inconsistency still exists that could lead to a violation.
Annie I. Antón
Ting Yu
Raleigh, NC
Elisa Bertino
Ninghui Li
West Lafayette, IN
To Map a Process, First Find Its Swimlane
The analysis of software development methodologies in "An Empirical Investigation of the Effectiveness of Systems Modeling and Verification Tools" by Anand Jeyaraj and Vicki L. Sauter (June 2007) demonstrated that methodologies based on data-flow diagrams are superior in certain ways to those based on use-case diagrams. However, knowing this is of little help in the real world due to deficiencies in both types of methodologies.
As a former strategy and planning leader for integrated process management at IBM Global Services, I am familiar with numerous methodologies, some far superior to both data-flow-diagram- and user-centered-design-based systems. Several IBM divisions have had great success with a swimlane-based (SLB) methodology called DesignFlow that provides far superior results for analysts, stakeholders, architects, and developers by combining actors, data flows, processes, and the passage of time in ways that are highly understandable. Each process is graphically mapped in a way that each actor—human, virtual, or external process—is represented, along with its activities and information, in its own swimlane. Process flows, responsibilities, and decision points are highlighted.
The current process is typically mapped as a starting point, while a second map is made of the "proposed solution," or the improved process. These diagrams are referred to as the "as is" and the "to be" states, respectively, and when compared, their functional requirements essentially "fall out" of the differences.
Some might argue that many projects are so groundbreaking that no "as is" process can be mapped, though being without such a process is rarely the case.
Every new process replaces existing ones, just as the telephone, fax, and Internet replaced the telegraph. What actually happens is that manual processes are replaced by or integrated into technologically more sophisticated process structures, even as the overall objective remains the same.
In practice over many years, SLB diagrams and their accompanying functional requirements and specifications have proved far more effective than either data-flow-diagram or user-centered-design artifacts in terms of comprehension and analysis by ordinary managers and systems workers, as well as by trained practitioners. The SLB methodology allows for simulations and play-acting in all mapped processes by stakeholders and developers alike, ferreting out omissions and uncovering valuable process improvements.
I cannot stress enough the importance of enlisting the assistance of the people who must work with and depend on the system to be developed. Too many projects fail because users have little input into systems under development until the user-acceptance or implementation phase, which is far too late to effect anything but superficial changes without incurring enormous costs.
Jeyaraj and Sauter provided a valuable service toward establishing a useful basis for comparing methodologies, but until they expand their research to include SLB methodologies, that service will offer little help to those seeking maximum effectiveness, efficiency, and user satisfaction for their own development projects.
Sidney L. Bursten
Laguna Woods, CA
Join the Discussion (0)
Become a Member or Sign In to Post a Comment