[Dev] Tizen 3 services: use case for multi user

Counihan, Tom tom.counihan at intel.com
Fri Sep 5 15:10:18 GMT 2014


Many Thanks Dominique for the considered response.

> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Dominig ar Foll
> (Intel OTC)
> Sent: Friday, September 5, 2014 3:13 PM
> To: dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3 services: use case for multi user
> 
> Le 05/09/2014 13:05, Counihan, Tom a écrit :
> >> Furthermore the requirement from Genivi is that a user application
> >> can be moved from one seat to an other without disconnection, so the
> >> binding between a seat an a user does not exist.
> >> We need to share BT adaptor between users which is why we need a BT
> >> framework on top of BlueZ to manage those issues.
> > In a shared adaptor model, with multiple potential users, how is it expected
> Murphy, the policy engine, interacts?
> > You may want to consider that a product may wish to employ policy on
> > top of functionality - i.e. just because you can practically allow
> > 4 devices to pair, you might not want to allow this because it doesn't match
> your UI behavior expectations? Having hooks to control this may be
> useful....?
> In Tizen OS,  we cannot manage by default all the potential use cases but we
> focus on enabling platform creators to implement their own use case.
> We have a service BT-service which is acting as a proxy between the App run
> in a user context and the BT middleware.
> This management of HW ressource limitation is a platform specific issue
> which will depend of the exact HW and middleware configuration. It could be
> implemented either with Murphy which is a generic resource manager or
> directly in the BT-service or with an other resource manager.
> Tizen is focussing on the use bases described in the Wiki as validation of our
> enabling concepts. We are working on step 1 and once done, we will do step
> 2. What will be the step 3 is still open (ideas and better code are welcome).
> https://wiki.tizen.org/wiki/Multi-user_Architecture#Multi_User_use_cases
> 
> >
> > Then to the concrete example of contact sync. Perhaps the thought
> process should expand beyond muti-user vis-à-vis devices and encompass
> how to handle/manage the data and the type of data?
> > I could think of some scenarios where I would have a userA wanting to pair
> (own) UserB's device.
> > If you sit the contacts into the user home dir, you could end up with a
> duplication of the contact db on the system - No?
> Following Tizen3 default security concepts we do not plan to store in
> permanent storage the data from a paired device.
> It drags a lot of security issues and complexity the storage management
> (when to clear the data) We will create cache when access to remote data is
> slow, in the case of contact where the volume of data is low, a RAM storage
> should do.
> 
> Until we have a valid (and simple) model to ensure that UserA is willing to
> share it's data with UserB, we do not plan to enable private data sharing by
> default.
> Once again, in the Tizen project we enable private data isolation, would a
> platform creator decide to by-pass that security, he will still have that option
> (it's simpler to share than to protect).
> >
> > Second angle to consider here is this. If I've enough access to the vehicle,
> the likely hood is I'm in the same social circle as others who also share that
> vehicle.
> As a generic OS, we cannot assume that proximity. Vehicles are used by all
> sort of groups who do not want to share their data ranging from company
> and rental cars to couple with "things" to hide.
> > Ergo a high probability that two users overlap on contacts. That observation
> could also expand to the corporate car market, where the social circle is the
> enterprise address book. It may break down for the shared car or rental
> sector. With a per user storage solution, you have challenges in optimizing for
> storage - why store and identical contact in 2 locations? Why store 2 identical
> albums on the device? It may seem like unnecessary complication, but
> consider knock on impact to eMMC wearout issues and 15year lifetime
> expectations in the auto sector.
> Once again, the most demanded use case in IVI is based on the hand free
> remote profile where the contact info are (and should remain) on the phone.
> A quick check shows that 1000 contact entries, once compressed take at
> most 50kB. Knowing that a simple photo would require from 10 to 100 time
> more space, contact temp storage for a few user should not be an issue.
> >
> > Would it be worth considering, from a device perspective it knows only of
> its MAC address and a PIN to auth.
> > PIN is loosely coupled to the user, but from a BT spec perspective, the
> protocol has no real concept of the user.
> That is why we have a BT service in proxy.
> > Then following this, could it make sense that you store the contacts in
> some [whateverpath/BTMACADDR]? Or have a central storage location and
> tag the contact to the btaddr - identify duplicates and augment the
> association with the additional btaddr?
> So far the model is to favour private data protection. If the community would
> come with a clear preference for sharing data, we would have to change our
> steering.
> > Then layer user meta data above this.
> > At the end of the day, some OEMs (IVI) may view it a feature that it has 1
> system contact address book, it may choose to a) segregate this so the
> contacts are viewed per device or b) harmonize the address book into 1 list
> (perhaps filtering out duplicates - after all if you are willing to share a ride
> with someone, you probably know the same people too). I could also
> foresee that it reasonable that when sitting with my partner, I want to use
> my device to make a call to a contact stored in her addressbook.
> This not very far from the model that we are considering for Multimedia
> meta data, where the risk of miss-sharing and the data volume are the
> reverse of contact data.
> > Finally, having a device orientated store structure could offer some
> advantage to purging data - for rental cars, I may want to have a generic
> 'guest' (or even have a pay-per service model where when renting, could
> 'upgrade' guest to enable navigation for a fee), so I may want to invoke the
> user concept to bucket different services, but I need a way to legally adhere
> to the data protection act by purging the addressbook without having to
> delete /recreate the user profile - less erase/rewrites helps my flash
> memory longevity - which is a far bigger issue for IVI than multiuser, as the
> typical head unit replacement cost - parts and labor - could reach $3000.
> For guest user, current plan to not copy any data in permanent storage what
> should provide a satisfactory solution to your worry.
> 
> --
> Dominig ar Foll
> Senior Software Architect
> Open Source Technology Centre
> Intel SSG
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.




More information about the Dev mailing list