Dear Alison, > We should not implement capabilities that are unsafe and then disallow > them in a policy framework: we just shouldn't implement them in the > first place.
Fortunately, automotive industry is very conservative especially for safety. So, they will not allow IVI to control engine directly in the near future. But, in real world, there are already some potentially dangerous requirement such as 'remote door unlock' or 'engine disable'. The trouble is that it's hard to imagine which another one can be used for malicious purpose in advance. So we have to try to make proper solution to secure IVI system and it seems not a problem which we can evade. > a pub-sub (server-client) model of communication is adequate. Agreed. And in my opinion, Signal-Slot mechanism of Qt is good for it. > they need from a database or XML log, they need not communicate with the > producer at all. I'm afraid I misunderstood your intention, but I'm not sure that how it can be fit to publish-subscribe pattern. Although D-Bus provides nice way for it, is there any reason or advantage of logfile based IPC? > User abstraction - multiple inputs and displays I think it's a topic worthy to be discussed. And I agreed that your opinion. But it looks somewhat not directly relevant to the current security discussion for Car System APIs. Car System APIs must be protected in fine-grained policy, thus traditional multi-user based security policy is insufficient. Even though an application is executed by the same user, it should have different privilege based on its origin. And the APIs which the application can access must be differentiated and protected. Best regards, Justin -------------------------------------------------------------- Justin(Jong-Seon) Park AOP Gr., S/W platform Lab., LG Electronics Inc. 221 YangJae-Dong, Seocho-Gu, Seoul 137-130, Korea _______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
