We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


  • Created by Unknown User (gururja.n), last modified on Nov 22, 2016

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Wiki page for logging review comments and discussions.

Base version:

Concept document
GENIVI Application Framework

7th July 2016
Document Author: Simon McVittie
Document Reviewer: Sjoerd Simons
Document Reviewer: Philip Withnall
Document Reviewer: Guy Lunardi
Document Owner: Collabora - Guy Lunardi
E-mail: guy.lunardi@collabora.com
Tel: : \+1-801-200-3848
Collabora Document Number: GEN0001
Collabora Document Version: v0.3 (draft)
Author Date Version Change Approved
SM 29-06-2016 0.1 Initial version SM
SM 04-07-2016 0.2 Revised internal version SS
GL 23-06-2016 0.3 First draft shared with GENIVI GL
link to the document : Application Framework scope and requirements

Application Framework scope and requirements

This document outlines requirements relevant to the GENIVI Application Framework effort. However some of these requirements may well be considered out of scope for requirements to the GENIVI Application Framework due to overlap with other GENIVI initiatives. They are included here as they are perceived to be within the context of an application framework. This document does not aim to specify a particular implementation for any requirement. The terms privilege, privilege boundary, confidentiality, integrity and availability have their usual information-security meanings (for definitions, please refer to Apertis Security design). This document is authored by Collabora. The content of this document is made available under the Attribution-ShareAlike 4.0 International license (CC BY-SA 4.0).

 

Table of Contents

 

What's in an app

NOTE: Initial IDs are assigned equal to the line number in the original document.

 

copy here


 

IDText
25There are two commonly-used definitions of an "app": either a user-facing launchable
program (an entry point) such as would appear in launcher menus, or a user-installable
package or bundle such as would appear in an app store.
 Comments: 
GN - info - Within GENIVI scope, 'Managed Apps' and 'Native Applications' has been defined
GA: A fair assumption is that a bundle will never contain both managed and
native apps and an app is either native or managed. I think we are fine
with the current definitions and they can be used in combination with the
defintions here without any conflict between them.
GA: A clear definition of "bundle" would help here (because of later usage e.g. entry-points)
GM: Please clarify how this definition is related to "Managed Applications" and "Native Applications" as defined inside the GENIVI Reference Architecture
GM: Also "package or bundle" should be better defined (notice that the GENIVI Compliance Specification already defines a "Package Manager")
PW: ‘bundle’ is defined on line 27 as a concept similar to an app on Android, for example. The definition is refined over the course of the document. We could try and expand the summary here a bit.
GA: This week 2016-11-08 it seems we said that Bundle = A collection of zero or more
executable files, zero or more libraries and zero or more meta-data files (for the last case imagine for example a "Skinning/theming bundle containing Icon graphics and configuration files only.". In an app store what would be presented to the user as one app would technically be downloaded as one bundle of files.
 Extracted requirement:

 

IDText
28A user-installable bundle would most commonly have exactly one entry point. However, it
might not have any entry points at all, for example if it is a theme or some other extension
for the operating system. Conversely, it might have more than one entry point: for example,
a user-installable bundle for an audio player might contain separate menu items for music
and audiobooks, launching different executables or the same executable in different modes
to provide an appropriate UX for each use-case.
 Comments:
GN : Ok, Multi entry points for Apps need to be translated into requirement.
GA: Put definitions at top, e.g. what is a bundle according to our previous discussions.
 Extracted requirement:

 

IDText
34In this document, when we need to distinguish between the two meanings,
we will say that a user-installable bundle contains zero or more entry
points. Entry points are similar in scope to Android activities.
 Comments:
GN :OK
GA: I am still not sure that the Android comment helps.
From android docs: "An Android Activity is an application
component that provides a screen with which users can interact in order to
do something". Activity requires a graphical view? Is that also required
for each entry point? Let's put down an actual definition table at the
start of this document - for bundles, entry-points, etc.
PW: You're right. Entry points do not require a graphical view. I agree with
putting a definition of entry points at the start of the document.
 Extracted requirement:

 

IDText
37Some vendors might decide to restrict the apps available in their app
stores to have at most one entry point, but that is a policy decision by
those vendors and should not be reflected in the more general app
framework.
 Comments:
GN : Should vendor specific config be a part of manifest?
PW: Vendor-specific configuration should be a part of the vendor’s platform policy, which will be encoded in their app store guidelines, and implementations of vendor-specific components in the platform. Manifests contain metadata, which should be kept separate from policy. It would be redundant to encode a general vendor-wide policy of “maximum number of entry points” in the manifest for each app.
Type: INFO.
 Extracted requirement:

 

IDText
40Entry points might be written as native code (for example compiled from C
or C++), or they might run under an interpreter or JIT in a runtime
environment that provides GUI functionality analogous to native code (for
example if the app is written in Java, Python, or JavaScript for the
node.js, gjs or seed runtime environments), or they might run in a HTML5
runtime environment. We treat all of these as fundamentally similar: they
result in the execution of app-author-chosen code.
 Comments:
GN : OK
GA: OK
GM: OK
Type: INFO
 Extracted requirement:

 

IDText
46(Note that whether an app is written in native code has no bearing on
whether it is what GENIVI calls a native application, which is an app that
is built into the platform, or a managed application, which is one of the
user-installable apps discussed here: either may be written in either
native code or an interpreted/JITted environment.)
 Comments:
GA: Good paragraph but I would consider if the words "compiled code" are
any help here.
PW: I suspect that ‘compiled code’ was chosen against, because a large variety of programming languages are ‘compiled’, even if the end result is managed or native code. The term ‘native code’ is loosely defined on line 40 — does the definition need to be bolstered?
 Extracted requirement:

 

IDText
50The app framework must be capable of running native-code (C or C++)
executables.
 Comments:
GA: Policy decision? If we're aiming for one framework to rule them all, I
guess I agree. If we are aiming for a shared requirement set for many
different environments, it might not be true.
PW: The approach we’ve taken is that applications written in interpreted or managed languages are treated as the combination of their interpreter and the code, where the interpreter is invariably native code. So native code support is always required. However, this would be an unnecessary complication on systems which only have managed/interpreted apps. This could be changed to be a policy detail; I don’t know what the consequences would be for the rest of the document.
GN : OK
 Extracted requirement:

 

IDText
51The app framework must be capable of running programs that require an
interpreter/JIT-based runtime environment such as Java or Python. It may
require that the runtime environment provides suitable library
functionality to work with the framework (for example, if the framework
uses D-Bus for IPC, then it does not need to support runtime environments
that do not have a D-Bus implementation or binding).
 Comments:
GA: See previous
GN : OK
 Extracted requirement:

 

IDText
56
  • The app framework must be capable of running programs that run in a
    HTML5 runtime environment: in other words, it must be possible to package a
    web application into a form suitable to be an app bundle. The entry points
    to an app might include GUIs and/or background services (agents, daemons).
 Comments:
GA: See previous
GN : OK
 Extracted requirement:

 

IDText
59
  • It must be possible for an app to contain zero or more GUI entry
    points. Each of these Application framework concept document might appear
    in menus (see App launching) and/or be available for launching by other
    means (see Document launching, URI launching, Data sharing).
 Comments:
GA: See below
 Extracted requirement:

 

IDText
64
  • It must be possible for an app to contain zero or more background services with no
    GUI, which can be launched for purposes such as Data sharing. For example, a search
    provider for a global search feature similar to GNOME Shell search or Unity Lenses,
    such as the one described in Apertis Global Search design, might be implemented in
    this way.
 Comments:
GA: So the definition is that these are not entry-points. Entry-points
require a GUI is the definition
PW: No, the definition on line 59 is that entry points may be GUIs or background services. The definition on line 26 does not contradict this, but could be clarified as it currently sounds like an entry point must have a GUI. That’s not the case.
PW: Note that we could cross-reference this to ~line 28.
 Extracted requirement:

 

IDText
69
  • It must be possible for the GUIs and background services to be implemented by the
    same executable(s) run with different options, or by separate executables.
 Comments:
GA: OK
GM: OK
 Extracted requirement:

 

IDText
71Some vendors might decide to restrict the apps available in their app stores to have
at most one executable, or to have at most one GUI and one non-GUI executable, but
that is a policy decision by those vendors and should not be reflected in the more
general app framework.
 Comments:
GA: OK
GN : OK
GM : OK
Type: INFO
 Extracted requirement:

 

IDText
75Each bundle should have bundle metadata to represent the app in situations like an app
store, a system settings GUI or a prompt requesting app permissions.
 Comments:
GA: OK
GN : OK
GM : OK
Type: Requirement
 Extracted requirement:

 

IDText
77
  • As a minimum, this metadata should include a globally unique identifier, an icon,
    and an international (English) name and description.
 Comments:
GA: OK
GN : Need to define a minimum set as mandatory requirement including privileges/permissions
Type: REQ
 Extracted requirement:

 

IDText
79
  • Additionally, app bundles should be able to contain translations (localization) which
    replace the international name and description, and any other fields that are marked
    as translatable (internationalization), when displayed on devices configured for a
    specific language and/or country.
 Comments:
GA: OK
GN : OK
GM : OK
Type : REQ
 Extracted requirement:

 

IDText
83
  • The metadata fields in an entry point should be in line with what is typically present
    in other interoperable package metadata specifications such as freedesktop.org
    AppStream and the parts of Android manifests that do not relate to a specific
    <activity>.
 Comments:
GA: OK
GN: OK
 Extracted requirement:

 

IDText
87
  • The base set of metadata fields should be standardized, in the sense that they are
    described in a vendor-neutral document shared by all GENIVI vendors and potentially
    also by non-GENIVI projects, with meanings that do not vary between vendors. For
    example, AppStream XML would be a suitable implementation.
 Comments:
GA: OK
GN:OK
Type:REQ
 Extracted requirement:

 

IDText
91
  • We anticipate that vendors will wish to introduce non-standardized metadata, either
    as a prototype for future standardization or to support vendor-specific additional
    requirements. It must be possible to include new metadata fields in an entry point,
    without coordination with a central authority.
 Comments:
GA: OK
GN:OK
Type:REQ
 Extracted requirement:

 

IDText
95
  • For example, this could be achieved by namespacing new metadata fields using a
    DNS name (as is done in D-Bus), namespacing them with a URI (as is done in XML), or
    using the X-Vendor-NewMetadataField convention (as is done in email headers, HTTP
    headers and freedesktop.org .desktop files).
  
 Comments:
GA: Discussion point. Shall we define this and if so what to choose?
PW: It should be standardised if and only if the metadata
format is standardised, as discussed on line 87. If so, we recommend
AppStream XML, plus ancillary files for custom metadata.
GA: OK. I propose we make AppStream XML a recommended format. Are there any other format proposals?
PW: None from me. For reference, here's the Apertis specification for it: https://appdev.apertis.org/documentation/bundle-spec.html#bundle-metadata
 Extracted requirement:

 

IDText
99Apps are expected to be numerous.
  • The app framework must be designed such that it does not need to place an arbitrary
    limit on the number of apps installed on the system, as long as their total size on
    storage (flash) fits within the available space.
 Comments:
GA: OK
GN: OK
Type: REQ
 Extracted requirement:

 

IDText
103
  • The app framework must be designed such that it does not need to place an arbitrary
    limit on the number of apps running at the same time, as long as their total size in
    RAM fits within the available space.
 Comments:
GA: OK
GN: OK
GM: OK
Type: REQ
 Extracted requirement:

 

 

Data management

 

IDText
107The app framework must provide a location where app programs can write their private
data.
 Comments:
GA: I would rephrase "location" to mechanism. There are several ways to do
this, one would be through a defined interface, like GENIVI Persistence
Client Library
GN : Is this expected to have a separate set of API's.
PW: We used ‘location’ because Apertis does not require use of a persistence library (robustness is left to the file system and kernel to implement), but it could be rephrased to ‘mechanism’. The only API defined here is the existence and path of the shared location.
 Extracted requirement:

 

IDText
109Open question: is this in-scope for the app framework, or is there some other platform
component that does it?
 Comments:
GA: The deep implementation of persistence must be a platform issue. The
API for applications should be defined here. We must discuss the solution
and the app-to-platform interface
  • if every app interaction shall be over IPC for example, then some kind of
    persistence daemon is required?
    GN : Since persistence management  from platform takes care of this. In my opinion this is a requirement for platform. but if some filtering to be done about the api's exposed,
    then its need to be handled appropriatelyPW: If the API for this needs to be defined in the application framework design, then I suggest defining the private data location for each application, which it can then pass to the persistence library. I am not sure how apps interacting over IPC (or not) fits in with this — what is your query?
 Extracted requirement:

 

IDText
111The framework should provide a location that is treated as private data in which to store
cached data, defined as data that can be recovered in a straightforward way by downloading
it from the Internet or computing it from non-cached data.
 Comments:
GA: OK
GN: should be ok.
 Extracted requirement:

 

IDText
114
  • The framework may delete files from the cached data area at any time to free up
    storage space, and apps should be written to expect this.
 Comments:
GA: OK. (This is a requirement on the framework but also needs to also go into app writing guidelines)
GN : OK.
GM : OK
 Extracted requirement:

 

IDText
116
  • For app author convenience, the framework may also provide conventional locations
    for other sub-categories of private data such as configuration (data that has a useful
    default, but can be reconfigured by the user, and whose deletion would be considered
    to be data loss) and state (data with no useful default, whose deletion would likewise
    be considered to be data loss).
 Comments:
GN : OK
 Extracted requirement:

 

IDText
121The app framework must provide a mechanism by which an app program's private data can
all be deleted by another system component, for example as part of removal or a factory
reset.
 Comments:
GN : Ok as requirement.
GA: OK
 Extracted requirement:

 

IDText
124The app framework should provide a mechanism by which all app programs' private data
can be deleted in a single operation during a factory reset, so that the factory reset
procedure does not need to enumerate app programs and iterate through them.
 Comments:
GA: OK
 Extracted requirement:

 

IDText
127Deleting per-user data and per-device data during a factory reset is also anticipated to be
necessary, but is outside the scope of this framework.
 Comments:
 Extracted requirement:

 

 

Sandboxing and security

 

IDText
130App processes should run in a sandbox which partially isolates them from the rest of the
system.
 Comments:
GA: OK
GN : OK
GM : OK
Type : Info ?
 Extracted requirement:

 

IDText
132We anticipate that each app bundle will act as a security domain, similar to the concept of
an origin on the Web: in other words, there is a security boundary between each pair of appbundles,
but for simplicity there is no privilege boundary within an app bundle (for example
between two programs in the same app bundle).
 Comments:
GA: OK
GN: OK
GM: OK
 Extracted requirement:

 

IDText
136Each app is assumed to store private data which is specific to that app. On a multi-user
system, this private data is also specific to a user: in other words, there is one private data
location per (app, user) pair.
 Comments:
GA: The later descriptions are clearer. I might suggest rewriting this first
paragraph.
GN: same as above
Type : REQ
 Extracted requirement:

 

IDText
139
  • Any data with this access model is considered to be private data, whether it is in files
    directly written by the app, files written by platform libraries used by the app, or other
    data stored on behalf of the app by platform services (for example accessed via interprocess
    communication).
 Comments:
GN : Is this list final or only an example?
PW: It’s meant as an example.

Type :
 Extracted requirement:

 

IDText
143
  • Private data availability: when a specific user runs a program that is part of a specific
    app, that program can read and write the data owned by that (app, user)
    pair.
 Comments:
GN :OK
type : REQ
 Extracted requirement:

 

IDText
145
  • Private data confidentiality and integrity: an app must not be able to read, add, change or
    delete data owned by a different app and the same user without the other app
    specifically sharing it. The program must also not be able to read, add, change or
    delete data owned by the same app but a different user.
 Comments:
GN :OKtype : REQ
 Extracted requirement:

 

IDText
149Note that the App confidentiality requirement below imposes a stronger requirement
than this: the first app must not even be able to know that the second app's private
data exists.
 Comments:
GN :OKtype : REQ
 Extracted requirement:

 

IDText
152Some categories of data might be specific to a single app but common to all users. We call
these per-app data.
 Comments:
GN :OKtype : Info
 Extracted requirement:

 

IDText
154
  • The app framework may have support for per-app data. If it does, the availability,
    confidentiality and integrity requirements are analogous to those for private data.
    The per-app data is considered to be jointly owned by all users, therefore there is no
    expectation of confidentiality or integrity for the per-app data of programs from the
    same app bundle running as different users.
    Some categories of data are not necessarily specific to a single app; instead, they might be
    shared between all apps. We call these per-user data. For example, the user's address book
    (contacts) and the user's calendar (appointments) might be among these
    categories.
 Comments:
GN :OK
 Extracted requirement:

 

IDText
162
  • Any data with this access model is considered to be per-user data, whether it is in
    files directly written by multiple apps, files written by platform libraries used by
    multiple apps, or other data stored on behalf of multiple apps by platform services
    (for example accessed via inter-process communication).
 Comments:
GN : Is this list final or only set of way of handling?
PW: It’s an example.
Type :
 Extracted requirement:

 

IDText
166
  • We anticipate that in practice, per-user data would most commonly be kept outside
    apps' sandboxes and accessed via inter-process communication to a shared service.
    For example, Android contacts provider services, GNOME evolution-data-server and
    KDE Akonadi all use this model for address books.
 Comments:
GN : OK
 Extracted requirement:

 

IDText
170
  • User data availability (read): the apps that require access to this per-user data must be
    able to read it. For example, a messaging application might require access to the
    address book so that it can read the thumbnail photos representing contacts and
    display them in its user interface.
 Comments:
GN : OK
 Extracted requirement:

 

IDText
174
  • User data availability (write): the apps that require write access to this per-user data
    must be able to add, change and delete it. For example, a messaging application
    might require write access to the address book so that it can add contacts' instant
    messaging addresses to it.
 Comments:
GN: OK
GA: "Write" is general. As requirements go, additional precision might be needed, e.g. delete != modify?
 Extracted requirement:

 

IDText
178
  • User data confidentiality with least-privilege: an app must not be able to read per-user
    data without user consent, other than what that app needs to carry out its normal
    function. For example, a compromised messaging app would still be able to read the
    address book until the compromise was somehow detected, but would not be able to
    read (for example) the user's appointments calendar.
 Comments:
GN : OK
type : REQ
 Extracted requirement:

 

IDText
183
  • User data integrity with least-privilege: an app must not be able to modify per-user
    data without user consent, other than what that app needs to carry out its normal
    function. For example, a compromised messaging app would still be able to modify
    the address book until the compromise was somehow detected, but would not be
    able to modify the user's appointments calendar.
 Comments:
GN : OK
 Extracted requirement:

 

IDText
188Some categories of data are not necessarily specific to a single app or to a single user;
instead, they might be shared between all apps and between all users, like Android's
/sdcard. We call these per-device data.
 Comments:
GN: OK
 Extracted requirement:

 

IDText
191
  • The app framework may have support for per-device data. If it does, the availability,
    confidentiality and integrity requirements are analogous to those for per-user data,
    except that there is no expectation of confidentiality or integrity for per-device data.
    The user might install a malicious app that has been written or modified by an attacker, or
    the user might install an app with a security flaw that leads to an attacker being able to
    gain control over that app (referred to below as a compromised app). Either way, the attacker
    is assumed to be able to execute arbitrary code in the context of that
    specific app.
 Comments:
GN: OK
 Extracted requirement:

 

IDText
198
  • The requirements stated above for private and user data confidentiality and integrity
    mitigate this attack by restricting what the malicious or compromised app
    can do.
 Comments:
 Extracted requirement:

 

IDText
200
  • App integrity: a malicious or compromised app must not be able to modify the
    executables and static data of other apps.
 Comments:
GN : OK
type : REQ
 Extracted requirement:

 

IDText
202
  • App confidentiality: in general, a malicious or compromised app must not be able to
    list the other apps that are running on the system or the other apps that are
    installed, either by their bundle names, by their entry points, or by inferring their
    presence from private or per-app data that they have written. Both are potentially
    sensitive information that could be used to "fingerprint" a particular user or class of
    users (for example customers or employees of a particular organization).
 Comments:
GN:OK
type : REQ
 Extracted requirement:

 

IDText
208
  • Note that if an app has written per-user data or per-device data, then it has
    potentially given up its own app confidentiality, in the sense that a malicious or
    compromised app could potentially identify it from the per-user or per-device data
    that it has written out. We recommend minimizing the number of apps able to write
    per-user and per-device data for this reason, and preferring to use content selection,
    document launching and data sharing to satisfy the use-cases for which other
    platforms would use a per-device filesystem.
 Comments:
GN: OK
 Extracted requirement:

 

IDText
215
  • Similarly, in general an app must not be able to communicate with other apps
    without user consent. Controlled exceptions to this general rule might exist for use
    cases such as data sharing.
 Comments:
GN: OK
type: REQ
GA: Needs some more details. Eg. is (direct) communication between apps even possible? User consent is a policy
question?
PW: We could expand on this a bit, but
since this section is about file system access, it would be a bit
distracting to devote a lot of discussion to inter-app communication. The
idea in Apertis is that apps cannot talk directly to each other — any
communication is mediated via an IPC service for ‘data sharing’ which can
enforce permissions on which apps can talk to each other. These permissions
might involve user consent (the precise policy is, as you say, a question
of vendor policy).
GA: OK, I think that makes sense.
 Extracted requirement:

 

IDText
218
  • System integrity: a malicious or compromised app app must not be able to violate the
    integrity of the system as a whole (for example by modifying the executables or static
    data of the system, or by altering the system's idea of what is a trusted app source).
 Comments:
GN : OK
type : REQ
 Extracted requirement:

 

IDText
221Resource limits: A malicious, compromised or buggy app might use more than its fair share
of system resources, including CPU cycles, RAM, storage (flash) or network
bandwidth.
 Comments:
GN : OKtype : REQ
 Extracted requirement:

 

IDText
223
  • Each app must have its own limit for these various metrics, for example by using
    cgroup resource controllers.
 Comments:
 Extracted requirement:

 

IDText
225
  • If this limit is exceeded, the vendor may choose how to respond to this. Options
    include killing or freezing the app, rate-limiting requests, denying requests, and/or
    reporting the app to the app-store as potentially malicious.
 Comments:
 Extracted requirement:

 

 

App permissions

 

IDText
229A very simple app, for example a calculator or a simple to-do list, might not need to do
anything other than the operations allowed to all apps: display a GUI when launched, run
code in a sandbox, store its own private data up to some reasonable limit, and so on.
 Comments:
 Extracted requirement:

 

IDText
232To carry out its designed purpose, a more complex app might need permission to carry out
actions that can compromise confidentiality (user privacy), integrity, or availability (the
absence of denial-of-service). For example, a more elaborate to-do list app might be able to
synchronize the to-do list to a cloud service, requiring it to have Internet access which
would make it technically able to copy whatever data it can read to a location not under the
user's control; it might ask to read the user's geographical location, to provide locationbased
reminders; and it might support attaching photos to its to-do items, requiring it to
read files that are not its private data.
 Comments:
 Extracted requirement:

 

IDText
240Some permissions have technical constraints that makes it impractical to request user
permission before they are used. For example, one possible permission flag is "has
unrestricted Internet access", which might be used for a voice-over-IP client app. To support
this control, the life-cycle manager would need to launch the app program with unrestricted
Internet access either allowed or forbidden: it cannot be adjusted later.
 Comments:
GA: "before they are used" really means "on-demand" or "interactively"?
Internet access, system might also ask consent on first use.
PW: Yes. In this case, we’re talking about situations where an entire session in an app would need to be torn down and recreated in order to change its behaviour after being granted/denied permission.
[App FW telco - 15-11-2016] Its agreed to change to "on demand". Provide possibility for having permissions before launch and after launch.
 Extracted requirement:

 

IDText
245
  • App bundles must be able to specify permissions without which they will not work,
    given in bundle metadata.
 Comments:
 Extracted requirement:

 

IDText
251
  • The user might be asked whether to grant those permissions on installing that app
    bundle or on launching any entry point from that bundle, or the framework might
    automatically grant certain permissions based on approval from an app-store
    curator without user interaction.
    Some permissions can usefully be granted or denied at runtime. For example, address book
    access on Android works like this: the permissions framework can be configured to prompt
    the user on each attempted access.
 Comments:
 Extracted requirement:

 

IDText
254
  • Operations that cross a privilege boundary between processes should include a step
    where a platform security framework is queried, to check whether the user's
    permission for the privileged action has been given. This should have at least three
    possible policy outcomes: allow, deny, or ask the user.
 Comments:
 Extracted requirement:

 

IDText
258Some operations that cross privilege boundaries naturally include an opportunity for the
user to reject the operation. To minimize driver distraction, the system should provide that
opportunity instead of having a separate permission prompt.
 Comments:
 Extracted requirement:

 

IDText
261
  • If an operation will naturally result in the user being prompted for a decision of some
    sort, there should not be an additional prompt for whether to allow the action.
    Instead, the user can indicate lack of consent by declining to make the requested
    decision. For example, content selection could use this approach: the user implicitly
    indicates consent to open or attach a file by selecting it, or indicates lack of consent
    by cancelling the file-selection dialog.
 Comments:
 Extracted requirement:

 

IDText
267
  • The framework might require that particular privilege-boundary-crossing operations
    are declared in advance even though they imply an opportunity for the user to reject
    the operation, for example if those operations are considered to be particularly
    sensitive or vulnerable to social engineering attacks. If it does, then it may make
    attempts to invoke those operations fail unconditionally, as if the user had canceled
    them but without prompting the user at all.
 Comments:
GA: I would say framework shall require all privilege-boundary-crossing operations
to be declared... (why not?). I mean they need to be declared - not every
operation might be in the category that requires user acceptance. User
acceptance and declaration are orthogonal concepts in my view of this.
PW: I see no problem with declaring them all in advance. As you say, declaring which permissions an application might request is orthogonal to whether those permissions are actually granted at request time.
[App FW telco - 15-11-2016] : agreed
 Extracted requirement:

 

IDText
273
  • Operations that cost money might be considered to be particularly sensitive — for
    example, a parent installing apps on behalf of a child is likely to want to prevent
    them — so the framework implementor might wish to ensure that operations like
    "send SMS" and "make in-app purchases" must be declared in advance.
 Comments:
Type: Information
 Extracted requirement:

 

IDText
277
  • Access to online accounts (such as social media) might be considered particularly
    susceptible to social engineering (since a user might not recognize when a request to
    fill in their social media account/password is or isn't legitimate), so the framework
    implementor might wish to ensure that operations involving these accounts must be
    declared in advance.
 Comments:
GA: As indicated above, I would change "declared in advance" to "require
user acceptance" or similar. Discuss and improve.
PW: I think we can treat declaring permissions as orthogonal to user authorisation of an app requesting those permissions in this case too. In this case, an example permission would be “let this app use my Facebook account to upload a photo”. If the permission is declared for the app, there are several policies which could be used at the time the app actually tries to start the upload: unconditionally allow the request, unconditionally deny the request, always ask the user, or ask the user if this is the first time the permission has been requested and use the answer from last time otherwise. I would agree with you, but I suspect that we should leave the exact policy to the vendors.
[App FW telco - 15-11-2016] similar to ID-267
 Extracted requirement:

 

 

App launching

 

IDText
283A bundle may contain zero or more entry points. These are typically started from a launcher,
which might take the form of a home screen, main menu or application list.|
 Comments:
GA: OK, although I think it's a little unclear with reference to the
defintion. OpenDocument(mimetype) is also an entry point right? At least
if it brings up a GUI, but it won't be on the home screen. Only some
entrypoints will?
PW: Correct, that’s why it says ‘typically’ rather than ‘always’. We could rephrase this to ‘for example, these might be started from…’?
[App FW telco - 15-11-2016] : Have the entry point topic collated together and make it explicit.
 Extracted requirement:

 

IDText
285
  • A launcher must be able to list all of the visible, available entry points in any installed
    bundle, together with enough metadata to display them in its menus. As a minimum,
    this would typically include a multilingual/localized name and an icon. Other
    metadata fields, such as categories, could be useful or unnecessary depending on
    the launcher's UX.
 Comments:
GA: Only those entrypoints that are not OpenDocument() type...
PW: There seems to be some confusion here over entry points which handle opening content by its content type (equivalently, its MIME type). Any entry point, including those which are listed in the launcher, can declare that it handles a list of content types. An entry point does not have to be listed in the launcher to declare that it handles a list of content types, either. For example, the Apertis music application has four entry points: three (artists, songs, albums) are listed in the launcher and don’t handle opening content; and a fourth (the ‘now playing’ view) is not listed in the launcher but does handle opening content (audio/mpeg, etc.). Different entry points within the same applications bundle can advertise different lists of content types they handle. Phrased differently, the set of entry points which handle opening content and the set of entry points listed in the launcher do not have to be disjoint or equal.
[App FW telco - 15-11-2016] : As agreed above wrt to entry points.
 Extracted requirement:

 

IDText
290
  • The metadata fields in an entry point should be in line with what is typically present
    in other interoperable menu-entry specifications, such as freedesktop.org .desktop
    files or the <activity> element in Android manifests.
 Comments:
GA: OK
 Extracted requirement:

 

IDText
293
  • The base set of metadata fields should be standardized, in the sense that they are
    described in a vendor-neutral document shared by all GENIVI vendors and potentially
    also by non-GENIVI projects, with meanings that do not vary between vendors. For
    example, .desktop files would be a suitable implementation.
 Comments:
GA: First part is OK but decision needs discussion. Does .desktop imply also the syntax? E.g. ini-file style...?
PW: .desktop implies the syntax, standard field names and semantics, and rules for defining custom fields. http://standards.freedesktop.org/desktop-entry-spec/latest/
GA: OK. Let's make .desktop format a recommended format. Are there any other proposals?
PW: I have no other proposals. For reference, here's the Apertis specification for it: https://appdev.apertis.org/documentation/bundle-spec.html#entry-points
[App FW telco - 15-11-2016] : agreed.
 Extracted requirement:

 

IDText
297
  • We anticipate that vendors will wish to introduce non-standardized metadata, either
    as a prototype for future standardization or to support vendor-specific additional
    requirements. It must be possible to include new metadata fields in an entry point,
    without coordination with a central authority.
 Comments:
 Extracted requirement:

 

 

 

 


 

 

 

 

 

 

 

  • No labels

Privacy Policy | Cookie Policy