On 11/27/2014 06:30 PM, José Bollo wrote: > Le jeudi 27 novembre 2014 à 18:11 +0900, Carsten Haitzler a écrit : >> this sounds like it's all co-operative. since an app itsdelf >> determines via metadata (manifest) what its purpose is. i assume you >> could download/replac your reverse camera app with another one, (maybe >> it's better at guiding you into parking spots?), so in the end it's >> really up to the developer to identify the class of app. >> >> but an app may have more than one window. one window may play video - >> another may not. so don't use manifest. use window properties. in x11 >> it'd be some extended atoms you add indicating window purpose - in >> wayland, a protocol extension to do that to a surface. the compositor >> would then decide what gets displayed or hidden based on these >> properties. the compositor would know/track current state (reversing, >> moving, still etc.) and enforce this policy. this is the "correct" >> solution. > Hi, > > I'm sure that a reliable system can not trust data published by > applications through an API that is not secured or trustable. If I'm > correctly understanding what you wrote, it would be of the > responsibility of applications to publish "metadata" using X11 or > wayland features. And I don't see here how prevent applications to fake > the system. But maybe am I missing something... > > Your ideas are however good: tagging by window could be the best and > expecting applications to collaborate is a wish that should be inspected > and that should receive a default implementation if the application > lacks it. What is missing is a trusted API, an API that would prevent > lying application to raise their sad goal and buggy ones to pollute. > > Best regards > José
notice my suggestion is based on the premise that the application manifest file is also metadata advertised by an app - the developer can claim anything they like in there, so i'm assuming it an equivalent of the app havnig an api to set such metadata on the window (api via webruntime apis or via native apis as needed). the manifest can be reviewwed.. as can the application behavior at runtime. the description of this is not one of a security issue but a regulatory one. only apps of "class x" can run now. apps claim to be class x either by api or by manifest. claiming to be something they are not is not a security breach, but a legal breach and it can happen in either case (as property on window or in manifest). so that was my basis for the suggestion. manifest is not "better" than property, but property is far cleaner and more fine-grained, allowing a single package/app to have multilpe windows/tools that have different tasks and appropriately advertise them. >> On 11/27/2014 05:42 PM, Puustinen, Ismo wrote: >> >>> Hi Casey, >>> >>> In IVI domain the car manufacturers may want to place "regulations" that >>> limit the applications that can be shown on the screen in different car >>> use cases. For instance: >>> >>> * When the car is moving, applications that play video are not allowed >>> on the screen. >>> * When the car is in reverse gear, the application that shows reverse >>> camera video must be shown on the screen. >>> * When the car is not moving, all applications are allowed on the >>> screen. >>> >>> You can easily think up a large number of possible use cases such as >>> these ones. >>> >>> It's "easy" to enforce similar audio policies since we have a pretty >>> good idea who is playing audio to PulseAudio. In order to do such screen >>> policy enforcement (even in collaborative way, when the application is >>> announcing it's true capabilities in the manifest file) we have to >>> somehow know which surface belongs to which application. >>> >>> Ismo >>> >>> >>> On Wed, 2014-11-26 at 17:00 +0000, Schaufler, Casey wrote: >>>> Why does the package name get used to determine if a window gets >>>> displayed? What policy do you really want to enforce? There has got to >>>> be a less convoluted way to get what you want than this. >>>> >>>> >>>> >>>> >>>> >>>> From: Dev [mailto:[email protected]] On Behalf Of Manuel >>>> Bachmann >>>> Sent: Wednesday, November 26, 2014 5:10 AM >>>> To: [email protected] >>>> Subject: [Dev] [RFC] AUL UI request for multi-process applications >>>> (ICO/Crosswalk...) >>>> >>>> >>>> >>>> >>>> Hi folks, >>>> >>>> >>>> This RFC is about bug TC-1691, TC-159... >>>> >>>> >>>> >>>> >>>> >>>> (The problem happens with Crosswalk today, but it could happen with >>>> any other application) >>>> >>>> >>>> AUL provide somes function calls, like "aul_app_get_pkgname_bypid >>>> ()", which permit to get the application package name associated with >>>> a running PID. >>>> >>>> >>>> Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses >>>> these calls to determine if it should show a window, by getting the >>>> PID of its process, and then comparing it will the package name. If if >>>> does not match, the window stays hidden. >>>> >>>> The problem is : >>>> >>>> >>>> In Crosswalk, the process which creates the window (the GPU process) >>>> is *not* the same that the one (the browser process) which registers >>>> itself as a Tizen application. >>>> >>>> >>>> Crosswalk has a dedicated process for UI operations, which is >>>> different of the one that does the application logic. >>>> So, the name is never found, and Web applications never show. >>>> >>>> >>>> >>>> >>>> >>>> In this respect, we need a way for an application to "pass" its >>>> application identifier to the graphical layer (in this case, ICO).Here >>>> are 2 options : >>>> >>>> 1) in Crosswalk itself, have a package name passed from application >>>> layer to the UI/GPU one (won't probably be upstream). Then, have a >>>> Weston plugin "receive" and store the information. When requested by >>>> the "aul_app_get_pkgname_bypid ()" call, AUL will also request the >>>> plugin for this information and respond. >>>> >>>> >>>> Requires modifications in : 3 packages (crosswalk, weston, aul-1) >>>> >>>> >>>> >>>> >>>> >>>> 2) in Crosswalk itself, have a package name passed from application >>>> layer to the UI/GPU one (won't probably be upstream). Then, store this >>>> data in a local database or specific tmpfs. When requested by the >>>> "aul_app_get_pkgname_bypid ()" call, AUL will also request this base >>>> or tmpfs for this information and respond. >>>> >>>> >>>> Requires modification in : 2 packages (crosswalk, aul-1) >>>> >>>> >>>> >>>> >>>> >>>> The 2nd idea modifies less packages but may be trickier to implement. >>>> Any opinion on this ? >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> https://lists.tizen.org/listinfo/dev > -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
