[Dev] Tizen 3 services: use case for multi user
patrick.ohly at intel.com
Mon Sep 8 07:29:59 GMT 2014
On Fri, 2014-09-05 at 16:12 +0200, Dominig ar Foll (Intel OTC) wrote:
> Le 05/09/2014 13:05, Counihan, Tom a écrit :
> > 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.
But following the "enabling platform creators" approach, we have the
necessary components for contact data available should someone want to
do that .
> It drags a lot of security issues and complexity the storage management
> (when to clear the data)
Following the "secure by default" approach, the data ends up in the
user's home directory where the OS protects it from accidental or
malicious access by other users. It gets removed when the user gets
removed. What we don't have is a selective "erase some data" or a
> 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.
The volume may be low, but transfer via Bluetooth is still so slow
(several minutes) that it does not meet user expectations (instantaneous
access once they turn on the car).
> 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).
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the Dev