Le 20/11/2014 15:08, Counihan, Tom a écrit : > > How do you identify the user on the head unit? In Tizen 3 we have been focussing on User private data protection. As currently in Bluetooth the paring is unique and base at device level, we have introduced a constrain which allow to pair a given device only to a given user. This enable us to have a 1:1 mapping between the remote device and a given user. > The remote device sending - let's say a business card - need never be > associated with the vehicle, nor have any user account there in? > > To add to the complication, GAP authentication is optional and perfectly > legal use case. We can do a lot but not miracle. Incoming pairing (on the fly or not) will be presented to the first privileged user connected on the system. If not privilege user is connected the pairing will be rejected. > > User confirmation is probably desirable, because I can see a very simple DoS > attack flooding on your file system if it simply/automatically accepts and > persists any type of files from random sources. The notification service allows to push request to a given user. > > Finally the formats, as defined int the BT spec are; > Formats: 0x01 = vCard 2.1 0x02 = vCard 3.0 0x03 = vCal 1.0 0x04 = iCal 2.0 > 0x05 = vNote (as defined in [9]) 0x06 = vMessage (as defined in [9]) 0xFF = > any type of object. > > Would all types be planted in the top level dir, or should a more logical > structure [/contacts /calendar /Notes /Messages] be formulated? > And I wonder for 0xFF - which could be anything from pdf, jpeg, mp3 - is some > kind of mime control/management needed? That level of details is not defined yet but simple to manage. The reception of done by the bluetooth internal user which then transfer the file and ownership the the destination user. Adapted tree structure is simple to implement at that level. If you have a proposition, please create a wiki page and submit your idea to the community via this mailing list. > > Finally some infrastructure to determine whether your received file is what > it claims to be would be beneficial too - i.e. someone renaming a pdf to > vcard, or worse some nefarious content in the payload.... > > These are the interesting question that spring to mind perhaps worth > considering? Tizen AppFW supports Mimes type to provide a valid association to a given type of file. Adding support of extension when Mime type is unknown is simple.
-- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
