W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2008

RE: FW: ACTION-660: Input to BP2, on Security and Privacy

From: Sullivan, Bryan <BS3131@att.com>
Date: Fri, 15 Feb 2008 13:40:15 -0800
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD05D9400E@BD01MSXMB015.US.Cingular.Net>
To: "Holley Kevin (Centre)" <Kevin.Holley@o2.com>, "Sean Owen" <srowen@google.com>
Cc: "BPWG-Public" <public-bpwg@w3.org>

I agree, those are important examples. For the BP2 though from a practical perspective we might be limited to recommending what applications *do* with personal information once they have obtained it, e.g. how securely it must be exchanged and how to ensure if it is not secure, then it is at least ensured to be non-personally-identifiable.

We can make references to the overall security frameworks that developers may need to comply with (e.g. OMTP's Application Security Framework, or MIDP 2.0 Security) to gain user-friendly access (e.g. unprompted) to certain API's, but as a *testable* recommendation I don't think there's much we could say. A developer will either get an application signed into a specific trust level/domain, or not. If not, the underlying platform should (per OMTP and MIDP for example) ensure the user is prompted. If the application is signed and trusted, then presumably it will have simplified access (e.g. unprompted) to the related API's. The remaining issues are then if/how the application informs the user of the nature/implications of its use of data obtained through those API's, and further how that data is protected as exchanged. These are the current recommendations I have included.

My reference to the increasing variety of information available to applications through API's, and how that includes web browsers in particular, is meant to say that by the nature of such API expansion, more personal data will be finding its way into applications and be exchanged across the network. So the overall priority of security/privacy recommendations is increasing. Thus there are specific recommendations on user awareness/control and information security. 

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Holley Kevin (Centre) [mailto:Kevin.Holley@o2.com] 
Sent: Friday, February 15, 2008 1:06 AM
To: Sean Owen; Sullivan, Bryan
Cc: BPWG-Public
Subject: RE: FW: ACTION-660: Input to BP2, on Security and Privacy

I think that the main concern is the following scenario:

A mobile user downloads an application for a specific purpose.  Say it's an IM chat client.  This IM chat client needs access to the internet.  The user is happy with this access to the internet for IM purposes.  But does that mean that the IM chat client automatically gets access to the user's location information from cell site IDs or GPS?  What about the phone book?  History of who the user has called?  Private emails?  Bank account details?

And what about an application which uploads the user's location to an internet-based service?  Does that application get access to emails/phone call logs etc?  Does it get to send the user's location to lots of places or only the one server?

These are the kinds of issue which Brian is highlighting.



Kevin Holley
Manager, Application Standards
Group Technology
Telefónica O2 Europe plc,

Direct Line: +44 1473 782214
Mobile: +44 7802 220811
Fax: +44 7711 752031
Email: kevin.holley@o2.com
IM: kevinaholley (MSN/Y!/AIM etc.)


-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Sean Owen
Sent: 14 February 2008 23:54
To: Sullivan, Bryan
Cc: BPWG-Public
Subject: Re: FW: ACTION-660: Input to BP2, on Security and Privacy

On Thu, Feb 14, 2008 at 6:25 PM, Sullivan, Bryan <BS3131@att.com> wrote:
>  Because the related web/internet technologies are standardized, the  
> specific methods may not be mobile specific, but the basic fact that  
> their use is more important in the mobile environment is what is  
> important. That's why the recommendations are included, and verifying  
> compliance to the recommendations is important.

I may be splitting hairs too early, but, you're saying that while security in general is not an unimportant issue in mobile, of course, it is not specific to mobile. So sure, we do not need to go over general security stuff again, and if that's what you're thinking, I agree. Then we need to see what's mobile-specific here...

>  Any network API's or device API's (data or device internal functions)  
> that are callable from a web application context can result in private  
> information exchange. Certainly these functions are callable as device  
> vendors publish API's for their use, and MIDP for example provides  
> specific API's. Some browsers may be more isolated than others, and 
> not  provide application access to these functions. But others do, and 
> web  applications can likely call the functions natively.

Again we go back to scoping. We are not writing about MIDP (right??) and I don't know of any HTML or HTTP mechanisms that transmit location info or contacts (unless there are X- headers that are semi-standard?) If no in-scope, existing technologies raise this problem, what will we say about this?

We aren't chartered to write a document musing on future issues for potential mobile technologies -- well, are we? I don't want to do that, it's not what I had in mind.

This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address below) immediately.

Switchboard: +44 (0)113 272 2000

Telefónica O2 Europe plc   Registered Office:  Wellington Street, Slough, Berkshire SL1 1YP
Registered in England and Wales:  5310128 VAT number: GB 778 6037 85
Received on Friday, 15 February 2008 21:40:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:51 UTC