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:
Afternoon:
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?
- 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?
- 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@@
- @@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?
- 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?
- Brian: we should distinguish between how subscriber ID
is used, and how an ID transferred over the network should be kept
anonymous.
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)
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?
- 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:
- Just about everyone has agreed that the goal is to
give users control over their information.
- 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.
- It’s been suggested that there will often be a network
operator in the middle of user-web interaction.
- 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]