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

Dominig ar Foll (Intel OTC) dominig.arfoll at fridu.net
Fri Sep 5 14:12:58 GMT 2014

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).

> 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

More information about the Dev mailing list