DRAFT Minutes from WAP-W3C workshop on mobile privacy
Day 1: Thursday, 7 December, 2000

 

Note: These minutes represent the best understanding of the minute-taker at the time of the discussions and may contain errors or omissions.  Please contact me if you have any suggestions or corrections.

 

Morning:

• Introductory remarks
• Location drafting committee overview: Cameron
• P3P overview: Langheinrich, Weitzner

Afternoon:

• CC/PP and UAProf background: Nilsson
• General requirements panel I: Le Maitre, Mulligan, Seliger
• General requirements panel II: Tapia, Meiseki, Weber, Phillips
• Day 1 wrap-up

 

Introductory remarks from workshop co-chairs,
Danny Weitzner (W3C) and Stefan Viewig (Mannesmann)

 

Danny welcomed everyone and gave a brief overview of the workshop and went over the draft agenda.  Stefan added his welcome and said that, in terms of workshop deliverables, he hoped that in addition to the minutes and summary report, we would also be able to identify some concrete steps forward.  What are some future milestones to aim for?  What future steps should WAP and W3C take to promote further interaction between the two organizations?

 

Technology Background I: Location Drafting Committee,
Ewan Cameron (Signalsoft)

 

Ewan presented an overview of the WAP Location Drafting Committee’s (Loc-DC) work [see slides].  Note: because of intellectual property issues, many aspects of the Loc-DC’s work could not be discussed in great detail.

 

Main points of presentation:

• Goals: to define overall architectural framework for the location that includes the access to position information available in the client and/or network (and other entities).
• Issues: user/subscriber privacy; network operator privacy; legality -- ways for legal entities to access location information.
• Out of scope: Position technology -- the underlying position determination of procedures are not defined within this committee; Legal issues -- awareness of issues, but Loc-DC is not going to solve these.
• Requirements:
  • User and subscriber privacy
  • Possessor control access
  • Re-use of WAP security
  • Prevent leakage of strategic information
  • Disclosure of client identity
  • Adaptable to different legislative environments

 

Questions/discussion:

General:

• Eric Brunner (Engage): In your previous slide, you mentioned leakages of strategic information.  Can you give examples of where carrier would not want information leaked?
  • Ewan: if a service is being offered where there are zones, then location information might be strategic.  For example, if Pizza Hut had [segmented market into] pizza zones, would not want competitor to get this.
• Eric: does your group have a document where this is discussed?
  • Ewan: within the Loc-DC, we have talked about cell IDs, etc.
• Danny: are these requirements publicly available?
  • Ewan: to WAP members only.
• Eric: how [does WAP access?]
  • Mario Tapia (XYPoint): The architecture allows ; we allow a socket for you to plug into.  There were too many carriers, regions, and laws to undertake.  So we’re here to try to figure out how to attack problem -- it’s essentially a proxy: anyone who makes a WAP gateway -- interface requirements being defined right now

Models/perspectives:

• Dave Bevis (IBM): you’ve described from user and network perspective, but not end-to-end perspective
  • Ewan: question of how end-to-end works will come down to individual implementations
• Dave: my question was more to try to understand where model is coming from -- what is the framework?  (e.g., is network operator always involved?)
  • Mike Mulligan (Nokia): there are scenarios where network operator may be involved, and those are in the framework as well.  For example, with GPS, you (as mobile user) may not want corporate office to know where you are.
  • Danny: and you want to remain in control of that transaction?
    • Yes
  • Danny: is the network responsible?
    • Mike: no, that’s a common misperception.  In fact, WAP elements don’t have an “owner.”
• Bryan Sullivan (AT&T Wireless): so, for privacy requirements in general, are they under WAP security group?
  • Mark: we’ve never talked about them.
  • Alan Zausner (American Express): the e-commerce WG  is going to bring the question of where should privacy discussion reside to the WAP group, but question of where is not decided yet.
  • Eric: so location independent privacy has no institutional owner within WAP forum?
  • Ewan: Correct.

Owner of information?

• Bryan: I think a general issue of privacy is defining who the owner of the information is.  The server provider and/or business enterprise may want to override user’s preferences at some point.
  • Ewan: mechanisms for allowing this will be there.
  • Bryan: the point I’m making is that the end-user is not always in control
  • Sven Mörs (Berlin Data Protection office): This may be true, but do you need to address this at the technological level?  Why not rely on a contract?  I wouldn’t want to have a technological override over user’s preferences.
  • Bryan: the employer should always have power to override -- to block or allow access, for example.
• Mark Le Maitre (Nextel): we’re a wireless carrier, we do a lot of B2B.  The challenge for us is: we have maybe 12 million subscribers for 6 million phones -- that is, when people take their phones home after work, it is like a different phone. Would like to have situation where, during business hours, employer can say “you work for me, your location is important,” but after hours the employer should not be able to do this without user’s permission.
  • Sven: my problem is that I don’t want a technological override, happening behind the user’s back.
  • Mark Le M: define the user -- our users are businesses.
  • Sven: we might want to distinguish, then, between subscribers and users.
  • Mark Le M: yes, we need to take that into account.
• Alan: Danny, perhaps we should be agnostic about policy issues.
  • Danny: I think that’s right.  We have requirements, some of which are legal or policy requirements.  We’re not here to make judgments about whether such requirements are legally correct -- we’re here to explore what requirements exist.

High granularity of control:

• Mark Le M: we want a high granularity over subscriber state: e.g., are they at work?  It would be a shame to address location without state, because that’s a recipe for SPAM.  3 big things for us: location, state, and intent.  Need these for segmenting the market.

Participation/process:

• Fiona Walsh (Avenue A): have you got typical web-client providers who can represent that perspective?
  • Ewan: yes, there are such people in WAP, but you have to be a member to get requirements on to table for discussion
  • Danny: W3C could suggest requirements
  • Nicholas Wood (OpenWave): WAP is about 800 members
  • Mark Le M: I think the mechanism would be for W3C to send a liaison statement to WAP.
  • Danny: just to give a bit of background about process, there is a WAP-W3C coordination group.  This workshop came out discussions from that CG.  There’s a strong membership overlap between WAP and W3C, but communication is not as good as it could be.

Future requirements?

• Mark Le M: if we’re talking about the future, there’s another specter: Java clients and handsets.  How do we make sure that privacy requirements of this group are addressed in a way that takes into account Java?
  • Mike M: in WAP NG, gateway will be optional.
  • Mark: OK, but do you still have WML (etc.) requirements?  My assumption is that customer doesn’t care how information is routed, so long as privacy is protected.  W3C should solve the generic problem of privacy (not just privacy for WAP).
  • Frank Seliger (IBM): another example is the car -- a lot of cars already allow location tracking.  So we should have a broader focus than just for mobile phones.
• Mark Le M: there should be requirement that solution to mobile privacy is not dependent on WAP.
  • Nicholas: this is already the case.

Control in handset:

• Mario: need to put a privacy manager on the handset.  The mechanism to control privacy preferences has to go somewhere -- if not on network, then has to be on handset.
  • Mark V: FYI, privacy manager is a trademark by IBM.  <laughter>
• Sven: from privacy point of view, might not want to have everything on network.  I would be much happier with having it on handset, where user is in control.
  • Mark Le M: absolutely, but what I’m saying is you don’t have to put all the processing power on the handset
  • Mike M: I agree -- the 3G is not going to be some kind of utopia, still have to share the load of processing.

Scope?

• Danny: a question about scope of Loc-DC work -- does the work of DC work at more abstract model: not just
  • Mark Le M: the question I would ask: OK, loc solved using WAP, but what about state using Java?  I start to get worried about other pieces -- let’s not just solve for WAP
  • Nicolas: every part of WAP [framework] is transport independent

Third party ads, misc:

• Eric: glad to hear power management brought up.  Fiona brought up a question about who’s involved.  I suspect that third-party ad and content people are not involved.  There is a possibility that the third-party ad and content are at risk by their non-involvement. 
  • Scott Alperin (DoubleClick): I should say we’ve been somewhat involved in WAP.
• Eric: Ewan, can you provide us at end of day with something for P3P and other working groups to take back, to study?
  • Ewan: no, unfortunately not, because of IPR issues.
• Eric: Java’s been mentioned already -- I can tell you this has brought new issues for the P3P working group.  As executable content becomes possible, there’s an extra dimension to privacy -- have you considered this?
  • Ewan: yes
• Mike M: there’s been a very big WAP NG effort over the last year.  This is not public yet -- can’t share with you.  But the new architecture is a big leap forward, takes into account many more scenarios.  In fact, the big complaint has been that it’s too expansive.
• Mario: on P3P -- P3P is also extensible.  I don’t see any problem with extending location to P3P.

 

P3P architectural overview,
Marc Langheinrich (ETH Zürich)

Marc gave an overview of the P3P specification.  See his excellent slides.

 

Main points:

• P3P 1.0 is a scaled down version of earlier work on P3P.  For example, there is no automated negotiation of preferences in 1.0.
• Focus is on ease of deployment -- want people to use P3P.
• Browsing with P3P 1.0 -- what’s added is extra line specifying location of policy reference file
• There is always the possibility to link back to human-readable privacy policies, if policy is too complex then website should do this.
• P3P 1.0 can be used with APPEL, a preferences language
• Some frequently asked questions:
  • Performance: how much extra time with P3P?  Answer: a bit longer, but we have numerous optimizations.  [More on this below]
  • Isn’t it too late to protect privacy once my browser sends a GET request?  Answer: no, because there is a “safe zone” concept
  • What’s missing in 1.0?  Answer: among other things:
    • P3P 1.0 does not offer a choice of policies
    • no negotiation
    • no non-repudiation
    • no automated data transfer
    • However, it could be argued that some of these “features” (e.g., automated data transfer) are really “bugs” in terms of data protection
• The take home message is: P3P is a user empowerment tool, but not a complete solution by itself

Questions/discussion:

Integration with digital signatures?

• Mark V: is there integration with XML DSig?
  • Danny: there has been some work on this (e.g., see the work by Joseph Reagle, co-chair of XML Signature group), but nothing formal in P3P 1.0.
• Mark V: if you don’t sign your policy, then there’s no guarantee that it’s really from you.
  • Eric: well, we offer no guarantees about hijacking of DNS
  • Patrick: or, put it this way -- how is this different from going to a human-readable policy on a web page?  People don’t sign their HTML pages.
  • Mark: no, but people will in the future -- we’re moving that way.
  • Patrick: So this is a possible future requirement?  [yes]

Performance impact?

• Mark Le M: performance: how much extra time with P3P?
  • Marc L: yes, takes longer, but we have speed-ups:
    • Caching -- don’t have to fetch every time
    • Providing policies for embedded content: allows you to make a forward reference (e.g., all ads from DoubleClick are covered by this policy), so that browser doesn’t have to fetch again.
    • Compact policies -- applies only to cookies -- minimally verbose representation of policies intended as a optimization
• Mark V: I know IBM produces many 40 page legal documents.  <laughter>  I’m a bit suspicious about ability of a compact policy to represent a privacy policy.
  • Eric: compact doesn’t mean that you lose a lot of semantics -- main thing is that it doesn’t require an XML parser (coded in plain ASCII).
  • Marc L: it’s an optimization -- and it’s optional.

Need for encryption?

• Mike: you said encryption is not required, but don’t we need to secure against eavesdropping?
  • Marc: what might be more interesting is whether APPEL is secure, since this is where user preferences are.
  • Eric: I see P3P as a vehicle for announcing policies.  Therefore, encryption is outside of scope.
• Mike: I would turn it around -- if it routes through Afghanistan, you can’t ensure privacy
  • Mark Le M: I think we need a true understanding of difference between security and privacy.  What I’m hearing here is concerns about security.
  • Mike: I understand the difference between security and privacy, but the end-user doesn’t.
  • Mark V: if there’s no security, then privacy policy can’t be guaranteed.
  • Mark Le M: I understand and agree, but I think we should distinguish between the two, here, for the sake of developing a privacy framework.
• Eric: there’s another reason for not doing encryption -- it’s redundant because we have the lock icon for SSL.
  • Mike: but IPv6 does not have a lock.
  • Danny: I think we [= P3P WG] didn’t want to redo things that already exist on the web, like the SSL lock icon.
  • Simone Fischer-Hübner: it would enhance assurance if there were things to show that policies are encrypted/assured.
    • Marc: yes, these may be important and even necessary in the future, but deployment became more important than we first thought.  So P3P 1.0 is a kind of test balloon.

Implementation in mobile environment?

• Alan: do you have any thoughts on possible simple scenario for how P3P implemented in mobile environment?
  • Mark Le M: OpenWave has an implementation: you might ask them.
  • Nicholas: there are basically 2 approaches: one is have everyone use @@Netscape browser@@; or else use a proxy, so that you can re-use policies.
  • Alan: but what happens if one size doesn’t fit all?  Do you have a prototype?  What would a typical negotiation look like?
  • Nicholas: there’s no simple two-sentence answer.  I can talk to you more about this offline.

Mobile UI?

• Alan: how does a user read a privacy policy on a mobile device?  P3P has possibilities, but it will be steep learning curve.
  • Danny: my own view is that designing good UI is hard.  This is the next big challenge for P3P.

Changes to policy in transport?

• Dave: is there any thought about interim paths for P3P, so that interim steps [e.g., through proxies] can add or subtract policy?
  • Marc: not so far.  We’ve assumed a direct connection between server and client.
  • Eric: the question you asked goes to our core architectural model.  The semantic we are trying to guarantee is end-to-end (but we realize this is weak).  What you’re asking for is a hop-to-hop incremental policy guarantee, but that’s out of scope for P3P 1.0.  It’s an interesting question, but in wireline world we don’t consider it.
• Mike: is it possible to store preferences on proxies?
  • Danny: there’s some work being done on this
  • Mark Le M: in support of Phone.com folks, their solution is a first good attempt.

Legal status of P3P policy:

• Danny: one quick point about signed policies and their legal status: one of the P3P WGs are in process of putting together a legal opinion for U.S. law on what the effect of having a P3P policy will be.  My own view is that (in U.S. law) are not contracts.  Privacy policies are not contracts.  They are commitments from companies that consumers can rely on if they feel they have been mistreated or misled.  [They provide a basis for recourse for consumer.]  But this is a question that we are hoping to get a more formal look at.
  • Alan: is analysis also looking at implications for third parties?
  • Danny: that’s a question we’ll have to address.  The kind of novelty of the privacy environment, is that the consumer is relying on these statements.  That’s an instance a larger problem on the web -- crypto people call this signing what you see -- how do you prove that you saw a version of such-and-such document?
  • Danny Delov (Hebrew University): I can sign this policy and say I saw it, but I cannot prove this to a third party.

What binds policy to owner?

• Mike: From a legal standpoint, what is it that binds policy to owner?
  • Danny: well, legal requirements are usually fuzzier than technical requirements.  I think Patrick had the key point: human-readable policies are rendered in HTML; these are not “bound” in any strict sense to an owner [at least not by a digital signature].
  • Where your question is germane is when a consumer says “I read this” and website denies it.  I think this is not a first-order problem -- you don’t really see such cases.  Even in the Amazon case [where Amazon.com made known that they were selling personal data], the question is one of interpretation, not whether there was a policy at all.

 

P3P public policy overview,
Danny Weitzner, W3C

Danny gave an overview of how he sees metadata as being a public policy tool [see @@slides@@].  He noted his presentation comes from a U.S. perspective, with “privacy” being grounded in values of freedom and liberty.

 

Main points:

• Privacy in the U.S. is grounded in 2 rights.  The first is freedom of association:
  • political and intellectual liberty, grounded in U.S. 1st amendment
    • E.g., Alabama v. NACCP: state wanted civil rights’ membership list, NACCP refused, said they had an obligation to protect their members’ privacy
    • hence, our concern here: we want new (web) environments to afford the same sense of safety about what you say/do
  • EU human rights view -- data self-determination
  • Emphasis on individual control over information
• The second: the right to be left alone (by government or private organizations)
  • Emphasis on collection limitation
• DoubleClick: the cost of getting it wrong
  • Drop in stock price after Abacus announcement and FTC inquiry
  • Created a new position within company: Chief Privacy Officer

 

Craig Brown (Baltimore Technologies) added that when he was working for Lotus, he witnessed the first public uprising over privacy.  When the Lotus Marketplace CD-ROM came out, there was uproar -- Lotus threatened by many big companies: we will drop all your software unless you cancel this project!

• Danny: and the interesting thing is that product was targeted at small businesses.  Idea was to level the playing field (big companies already had access to such information).  The cost of getting in wrong was not just for Lotus, but also for others who might have had legitimate uses for this data.

 

[@@Danny’s presentation continued@@]

• defining policy moment for the Web: pornography
  • governments were urged to censor Net; industry reacted
  • user empowerment recognized as vital tool -- rationale behind the creation of PICS
• defining policy moment for Mobile Web: privacy?

 

Danny went through some examples of P3P user agent implementations and then explained where P3P is in terms of W3C process:

• P3P is at Candidate Recommendation state.  That is, W3C considers spec ready to be implemented (something like draft standard stage for IETF) -- now waiting for implementation experience.
• we’re expecting P3P implementation in next version of MS IE
• Netscape has said it’s waiting on Mozilla module -- as soon as that’s ready, will fold into next version of Navigator.
• We’re seeing lots of tools coming up; really, what we’re waiting for is implementation in major browsers.

 

Danny: We don’t consider that P3P is a complete solution, or that we’re finished, but we’ve consciously taken step-by-step approach.  We’re going to look at how this goes as we go along.  But we’ve identified niche: websites need this -- human readable form are more and more complex -- users can’t handle this.

Questions/discussion

Communications and outreach?

• Karen Kremer (Ericsson): how do you communicate to user who doesn’t know what he’s doing?
  • Danny: That’s the user interface challenge.  I think the SSL model is what to look at -- lock icon provides comfort to user.
• Karen: Are you planning to do marketing of P3P?
  • No, marketing the spec won’t help, but what will help is that people will build tools on top of P3P.  User doesn’t know -- and shouldn’t have to know -- details of how P3P or SSL works.  Just needs to understand what the SSL lock icon represents.
  • I believe the main communication about P3P will come from developers of applications -- those who see commercial benefit to P3P.

Need for secure systems?

• Mike(?): Are we setting up false expectations [by not having stronger security measures]?  If we want people to feel confident, then we have to build secure systems.
  • Danny: I don’t think so.
  • Mark V: but it’s easy to compromise sites’ privacy policies, with Java script for instance
  • Danny: there are situations where the perfect can be the enemy of the good.  You’re wanting to extend the reach of SSL.  I don’t believe you’re ever going to have a technical mechanism that will completely address needs of security.  You can develop useful tools even if not perfect -- for example, I think that despite its flaws, SSL has managed to increased trust.

 

(Lunch)

 

Technology Background III: CC/PP and UAProf
Mikael Nilsson (Ericsson)

Mikael gave an overview of the CC/PP and UAProf specifications [see @@slides@@].

 

[Editor’s note: points marked with @@ still to be filled in, waiting on slides]

 

Main points:

• @@status of CC/PP and UAProf@@
• @@architectural overview@@
  • Marc: where is the GET request?
    • Mikael: profile is obtained once per session; then gateway passes on profile each time afterwards
  • Danny: could you explain relationship between device profile and proxy profile?
    • Mikael: proxy profile in UAProf sense is the 02-Profile-diff: <xml> in the slide.  The device profile is the one stored on profile repository.
• UAProf is an instance of CC/PP (i.e., CC/PP is a more generic specification)
  • @@see slides on UAProf architecture@@
  • Danny: do you do binary encoding twice, at RDF and XML levels?
    • Mikael: we do it once, but it’s up to the implementation
• @@current status and looking ahead@@
  • Profile encryption?
• @@CC/PP WG on trust@@
• Requirements:
  • User should have control to take away part or all of profile
  • The goal of CC/PP is not to introduce any additional weaknesses in network security

 

Questions:

In phones now?

• Marc L: is UAProf already built into [mobile] phones?
  • Mikael: just starting to be deployed now

How to handle data prior to knowing privacy policy?

• Mark Le M, Nextel: how do you handle the problem of profile information given out prior to knowing [site’s] privacy policy?
  • Mikael: we’ve started climbing this mountain, not solved yet.

Minimizing data flow?

• Danny: to what extent could you design the spec to minimize the amount of information getting to origin server about the profile (e.g., by pointing to only a few lines instead of the whole profile)?
  • Mikael: No, there’s no way to send out selected information with current spec.  You would have to have another URI with minimized profile data.
  • Hidetaka Ohto (Panasonic): right now, XPointer/XLink are not supported, and I think RDF will not work smoothly with XPointer.
• Garland: wouldn’t it be easier just to reference a subset of the profile?
  • Mikael: not the way we have it set up now.

 

[Editor’s note: This might be future requirement -- privacy is enhanced when less profile information is given out.  Also, think of the problems faced when profile becomes large, because more and more information being dumped into one profile.]

Customizing content:

• Eric: a comment on the “blind man” problem [mentioned in your slides]: at the last W3C AC meeting, it was clear that WAI would like to know if user is blind -- that’s how they can give better content.  HTTP 1.1 on the other hand, turns us all into English speakers.  When you pose blind man problem and suggest it’s a privacy concern, did you think through all the possible uses of this information?
  • Mikael: our goal is not to think for others, just to give mechanism for handling profiles.
  • Sven: if I’m blind, why don’t I have an option just to turn on/off audio on my cell phone.  It’s not a privacy problem.
  • [at this point Hidetaka gave a review of CC/PP history, and noted that the CC/PP exchange protocol has led to a proposal in the IETF for a draft standard]
• Sven: if you want to give data, note that there are at least 2 kinds of profile data to give out.  One would describe the particular mobile device (my Ericsson 520), and another would describe my personalized settings.  With this information, can profile be traced to a specific handset (and therefore the person)?
  • Mikael: could be.
  • Marc L: but usually diff would not be “my password” -- diff is at device level.  I can imagine some unique diffs (e.g., 72KB extra memory) that might be traceable to a person, but would be rare.
  • Hidetaka: right now, there’s not much privacy-sensitive information in device profile.  Originally CC/PP did not have so much concern about privacy, but now awareness of privacy concerns increasing.  Location guys stated their concerns about privacy issues.
• Brian: one of the role’s of the gateway is to secure subscriber identity.  And ties to origin server.  So it’s important to note that, as a carrier, we take position that the subscriber ID will not be passed out under any circumstances, unless it’s at the application layer (from user to program).
• Simone: I just want to note that it’s difficult to say what’s sensitive information -- depends on context of use.
  • Mikael: yes, especially with user profiles
• Danny: think back to Mark Le M’s point that people have, in practice, 2 phones -- could provide for interesting profiles.
• Mike: step 3 or step 4 of hacker’s attack is what application user uses, and UAProf hands this on a plate.
• Sven: does the end-user have a choice -- can I choose not to send a profile?
  • Mikael: that’s implementation specific
• Sven: seems like a similar problem to browser chatter?
  • Mikael: yes
• Danny: I’m surprised at how deeply this cuts: CC/PP deals with seemingly technical details (e.g., device name), and yet might tie this to sensitive information (location, user name, etc.).  I’m wondering if this is intentional -- is the goal to have a very general specification, or is this feature creep?
• Marc L: This reminds me of P3P, and the problem of browser chatter.  The only thing the WG could think of is to have a “safe zone” [where minimal data is passed], and then when you know what you’re getting into, you pass out more information.
  • Danny: right, and in perfect web world you shouldn’t rely on chatter, but the reality is some people do
  • Sven: why not turn it the other way around -- why not have the server contact the handheld and say, “I’m going to send you a jpeg, can you handle?”  It’s a traffic problem.
    • Marc: I’m not sure that’s a better way, sites will just keep asking if you can handle content.
  • Scott: I think as there are more and more browsers, it will be important for the user experience that sites know user-agent’s capabilities.

 

(Coffee Break)

 

Panel: General requirements I

Marc Le Maitre, Nextel

Marc gave a presentation from the wireless carrier point of view, focusing on user experience [see slides]:

• what I hope to contribute to this group is the user experience: what are requirements from users point-of-view
• mCommerce [mobile commerce]: defined as real-time and context-sensitive, relies on personalized information such as location, state, and intent
  • state defined as the customer’s availability
  • note huge potential for profiling/surveillance/privacy invasion
• Assertion: privacy challenge is not primarily technology issue, or governance issue, but a business issue
  • Need to start building a privacy framework now -- you can’t get much more personal than “where are you and what are you doing?”
• What’s missing from P3P?
  • Negotiation, etc.
  • Not balanced: client has an agent, but service provider doesn’t -- so balance the equation.
• Location and state are possibly the most lucrative for wireless carrier -- allows us to stay in business stream -- but also the most problematic from point of view of privacy
• Among the solutions we are investigating: eXtensible Naming Service  [Editor’s note: there was a demonstration of XNS on Friday, at the end of the workshop.]
• This presentation represents about 12 months of work, we’re past analysis stage, moving towards implementation stage.
• If you’re a wireless carrier, you’ve got to go out and be a consumer advocate, give them control, and then have a contract that specifies the terms under which wireless carrier can access and use that information

 

Mike Mulligan, Nokia

[no slides]

 

Mike presented Nokia’s viewpoint.  Main points:

• Starting next month, GPRS will roll out; then 3G in 2002.  What this means is mobile phones will be connected to the Internet.  So when we’re talking about mobile Internet, it’s really the problem of Internet as a whole.
• Nokia view on privacy: mobile phone is a trusted device
  • When we release a mobile phone, bugs are highly noticed.
  • Phones are trusted devices: credit card information, etc. on phones means phones will become the ultimate smart card
  • Mobile phone will become the primary point of contact for accessing web, making purchases
• From Nokia point of view, trust is the key issue.  Any data on that device must be used only in ways that user wants and authorizes
• Problem is that data can leak.
• Short-term view: we want consumers to have ways to pay us money.  But let’s take a longer term view (2-3 years): we need to create trust

Comment:

• Dave B. (IBM): there are some things unique to GPRS, etc.  When we talk IPv4, we’ll end up with identification of users being handled by network operators.  One of the new things about mobile is identification information exists where data would not normally be stored.  So, mobile has broader concerns.

Question:

• Eric: when you say Nokia sees Internet starting at handset, did you mean starts at WAP, or broader?
  • Mike: our view is WAP is important, but not the whole picture.

 

Frank Seliger, IBM

Frank presented IBM’s approach to the mobile web [see slides].

 

Main points:

• IBM taking privacy seriously, created a new position of “chief privacy officer”
• IBM envisions future of mobile web to be “pervasive computing”; IBM involved in every part of this environment (both wired and wireless, from server to client)
• New product: Privacy manager™ is for back-end -- meant to complement P3P by giving confidence to user that P3P claims are actually carried out by the business
• Four basic classes of device configuration: full, service platform, terminal platform, and thin terminal [see slides]
• A use-case scenario for mobile: my car’s computer detects it’s low on [x], automatically sends out query as to where is closest repair shop, and if that shop has the parts I need.  But, is user in control in this scenario?
• Proposed  requirements for user options:
  • Users should have separate choices for location information, caller identification
  • Should be different levels of granularity of choice:
    • On/off
    • If on, then choice of simple prompting vs. intelligent prompting (e.g., based on P3P user preferences)
• Java will create more luxury, and more privacy problems.  [But wireless folks demur -- don’t think Java will be that big an issue. -ed.]

 

Alan suggested that Bluetooth complexifies mobile scenarios.

 

Questions

Screenshots?

• Alan: I’m not seeing any screenshots, etc.  I’d like to see these.
  • Marc Le Maitre: I can show you more back in the U.S.
• Alan: I want to see if (e.g., “push”) technology is happening.
  • Marc Le M: Here’s how I see it: either you have location (“push merchants onto user”) or Bluetooth-like responses.  In some way, shape, or form, you trigger something by being in proximity to something.  There’s not enough power on handset, so processing being handled by agent somewhere else.  So, agent will then give out personal data (subject to terms of user preferences) and get the best deal.
• Marc Le M: you have to trust somebody; my assertion is that trusted agent is best of all

 

Negotiation and P3P

• Danny: we have some notion of flexibility: being able to flex your preferences depending on nature of transaction.  That was a whole set of features that P3P WG had thought about and stepped away from, because WG did not see many implementations, so standardizing seemed premature.  So, how much of priority is this for people here?
  • Le Maitre: I think it’s critical
  • Mike M: I think negotiation could be added today -- important but not the most.  More important is enforcement of policies.
  • Frank: I would want to leave out of mobile version, because we cannot spend too much luxury because of number of devices -- can’t do on the device itself (processing power; power management).  If it’s hard on desktop, then even harder for mobile.
  • Marc L: there was also the concern in P3P of malicious negotiation, where site sends false negotiation offers just to learn more about you and your profile.
    • Nicholas: that’s paranoid.  If you’re afraid of that, just don’t communicate.
    • Patrick: no, the problem is if you do things behind my back, then a lack of trust develops.
  • Bill: there’s a level of trust built up over time -- not negotiation at the first interaction.
  • Sven: I want to stress that privacy preferences information can be sensitive data.
• Danny: can you have an anonymous negotiation?
  • Marc Le M: it boils down to business at the end of the day, and an anonymous profile doesn’t have much value to business.
    • Danny: but can you have anonymous negotiation first, and then have as a second-order question whether to create a profile.
  • Marc Le M: we just want a query mechanism, so we can tell if someone wants (or can handle) a given ad.
• Alan: I was part of the P3P WG when we discussed negotiation, and we felt it was just too complicated.  And negotiation is far more complicated in mobile space.
  • Scott Alperin (DoubleClick): consumers should have a choice about being anonymous or not.
  • Marc Le M: on consumer choice -- businesses don’t want anonymous unique identifiers, they want to profile you.  That has value.
  • Scott: to make advertising effective, you don’t necessarily need to know person down to the level of the individual.
• Danny: is identification scheme for mobile coming up in WAP?
  • [someone]: yes.
• Brian: we should distinguish between how subscriber ID is used, and how an ID transferred over the network should be kept anonymous.
  • [agreement]

 

Panel: General Requirements II

Mario Tapia, XYPoint

Mario presented an overview of the E911 system in the U.S. [see slides].

 

Main points:

• E911 was mandated by FCC -- being set up for situations where emergency services would need to pinpoint location of person in distress.
• Privacy is the problem: no one wants to deploy commercial services for location because of privacy liability.  [In the case of E911, carriers are protected by law from liability -- see FCC rule.]
• Industry should provide Fair Location Information Practices [see, for instance, this paper].  Basically, what this means is have a philosophy of being an advocate for the consumer.
• Requirement: Location data should be secure, but also allow for “Push” services

 

Kentaro Meiseki, J-Phone East

Kentaro presented information about J-Phone [see slides]:

• J-Phone East develops non-voice services: email, World Wide Web, etc.
• J-Sky station is push technology:
  • Basically, information is provided to use “one-way,” so content provider cannot collect user’s profile
  • But in the future, privacy will become more important with services that depend on location, e.g., scheduler program, personalized advertising, and instant messaging with location.
• Requirements:
  • Global privacy consensus
  • Simple and compact description, compatible with XML
  • Less transactions (wireless is not broadband)
  • Easy to view and accept/reject privacy policies from handset
  • Allow for user unconscious location notification for trusted web sites
  • Peer-to-peer privacy information exchange framework, from handset to handset

Question:

• Eric: Does peer-to-peer not require URI namespaces?
  • Danny: Not necessarily, though I don’t see why it couldn’t use them.

 

Ricarda Weber, Siemens

Ricarda presented an overview of her group’s research interests [see slides].

 

Main points:

• in Siemens (Germany), there are many data protection officers within company -- almost one in every department, and also one for company as a whole
• research interests of group [see also her slides]:
  • privacy in mobile environment
  • privacy protection through technology

Question: Trust in network?

• Ewan: perhaps one of your use cases would be a GPS phone interacting with network (end-to-end)
  • Danny: why I think that case is interesting is because user doesn’t see any difference.
• Sven [to Ewan]: I understand that using a GPS device involves user placing trust [in someone] -- elaborate.
  • Marc Le M: actually, there’s another view -- set up the architecture so that the first place data goes is to a trusted agent.
  • Ewan: I agree, but perhaps you have to think about the agent being on the network.
  • Mike M: what if you mess up?  We’re already at that stage -- data’s getting out and there’s danger of losing trust.

Sensitive information?

• Danny: basically, what we’re talking about is background transmission of sensitive data, and the fact that it’s location is not really important
  • Ewan: but it happens everyday
• Danny: that’s right, but when it happens with sensitive information, that’s when you get headlines.  On one level, the idea of a trusted agent is nice.  The PC does not do that, but it does have some transparency (not perfect transparency, though) that helps ease consumer concerns.

 

Garland Phillips, Motorola

[see position paper]

 

Main points:

• Motorola would like solution to be not only for wireless, but for “whole” Internet
• Want a global privacy solution
• List of issues specific to mobile devices [see slides]
• High roundtrip request/response latency is unacceptable: “users are impatient”
• Suggestions [see paper]
  • Privacy mechanism should consume little over-the-air (OTA) communication bandwidth

Question: Display size?

• Lukas Gundermann (Independent Centre for Privacy Protection): is display size really a problem?  I can download a whole book on to my Palm Pilot.
  • Garland: I see Palm and phones in different categories.
  • Mike M: we have to accept that phone has to be small, fit in your pocket; mass market phones will be small.
• Frank: but that brings us back to question of what web access is for.
  • Mike M: phone access to web is very different from wire line -- uses will be different.  You’ve got to remember that for iMode, the killer app was Tamaguchi.

Forwarding of policies?

• Eric: your service seems to require forward transport of policies.  What do you do when you have a profile and you want to pass this on?  (e.g., L.L. Bean forwards policy onto FedEx)
  • Mario: @@??@@

Gatekeeper/trusted party?

• [??]: since mobile network is always on, shouldn’t the mobile operator be the first to protect users’ information?
  • Marc Le Maitre: CTIA is petitioning the FCC to make the subscriber the “intellectual property owner” of his/her location information.  Then, a carrier should not exploit that relationship, but instead has to earn trust of the subscriber.
  • Danny: I would observe that the role you’re looking for is a trust management (almost fiduciary) role of necessity between 2 parties.  I’m a little skeptical about designing an architecture where the carrier would always come in-between user and the web.
  • Marc Le M: if we do this well, then there’s a business plan down the road.  We can monetarize this if we earn users’ trust.  Otherwise, carriers will just become pipes, like ISPs.  There’s no value in being an ISP, you have to be a portal, etc.
• Brian: “walled garden” -- how to add value to user’s experience when they move outside the walled garden (of carrier-based access).
  • Ewan: I would love to agree, but we also need to address scenarios where carrier is the pipe.
  • Mike M: I think we’ve been running around the question.  The person whom the user trusts (whether operator, third party, etc.) is not the issue.  The question is how you build trust in first place -- this is an enforcement question.  [i.e., how do you guarantee your privacy policy?]
    • Marc Le M: in the short-term, it’s going to be the carriers that are determining the architecture (e.g., E911) for interpreting/creating location information.  You have to look at them.
  • Alan: BTW, NTT DoCoMo users never see the hardwired web.  If you read a lot of the market research, their vision is there’s going to a lot of cheap phones, accessing the web.  We have to address this.

Control in handset or network?

• Eric: I have a series of questions.  First, it seemed you were looking for a policy announcement in reverse: from a handset to the core?
  • Garland: no, although that’s one way to do it
• Roaming: would you want a proxy query in the handset?
  • yes
• Is “push” actually required?  Can an “end-user-initiated beacon-event” replace “push”?  Push requires us to know people’s locations.  Beaconing and query places total control in the handset.
  • Garland: I think the power of push comes when you do mass announcements, mass marketing.
• Put another way: instead of always knowing where user is, can we wait for user to disclose where they are?
  • Garland: that’s limited, isn’t it?
  • [maybe not??]
• Where does agency for location actions reside, in the handset or in “the network”?
  • [??]: “Push” involves sending an HTTP request -- agency is clearly not in the handset.
  • Mario: but the network’s always going to be required (e.g., what if you get jumped in a parking lot?).  For beacon-initiated events, you’d have to continuously send out beacons, and that’s not good for the network to always be updating location information.

 

Day 1 Wrap-up:

A very brief wrap-up by Danny: [a more comprehensive wrap-up took place on day 2]

 

Danny: I want to just pick up on 4 things:

1. Just about everyone has agreed that the goal is to give users control over their information.
2. The difference that’s struck me is the different user expectations that users have: there really is a higher level of expectation about security, trust, and maybe enforcement in the mobile environment.
3. It’s been suggested that there will often be a network operator in the middle of user-web interaction.
4. But, then again, maybe not -- are we looking at multiple architectural scenarios?

 

Marc Le M: I just want to add that my thing about carriers being the trusted agent is more of a wish than a statement of fact at the moment.

 

[Day 1 ends at 18:00]