Versions Compared

Old Version 9

changes.mady.by.user Unknown User (gururja.n)

Saved on

compared with

New Version 10

changes.mady.by.user Unknown User (gururja.n)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

IDText
899
  • The app bundle's private data and per-app data must be removed. This matches what
    is done on Android, and is necessary to prevent a "masque attack" in which a user is
    induced to install a malicious bundle of the same machine-readable name
    from a different origin (for example via social engineering), after which the malicious bundle
    would be able to gain access to the private and per-app data of the
    original bundle.
 Comments: 
GN : OK
 Extracted requirement:
IDText
904
  • Per-user data and per-device data must be unaffected.
 Comments:
GN : OK
 Extracted requirement:
IDText
905
  • Open question: it has been suggested that there should be a requirement that apps
    must not download in parallel, with at most one app at a time actively downloading,
    and the rest queued.
 Comments:
GA: Who suggests it and why? Let's discuss.
I'm not sure this requirement is needed - isn't that controlled by the App
Store and isn't it a (OEM) policy decision?
PW: This is potentially an Apertis requirement, aimed at restricting the peak bandwidth a vehicle uses. It should probably be a vendor policy decision, yes.
 Extracted requirement:
IDText
908Is this a requirement? This seems like something that should be a quality-ofimplementation
decision for implementations: an implementation that expects to
run on comparatively fast hardware might wish to maximize user convenience by
carrying out downloads and installations in parallel, while an implementation that
optimizes for implementor convenience or comparatively slow hardware might prefer
to impose a limit of one download or installation at a time.
 Comments:
GA: Agree, see above.
 Extracted requirement:
IDText
914On a multi-user system, each user might wish to have a different set of apps installed.
However, physically downloading and copying each app bundle for each user might be
considered to be unacceptably inefficient.
 Comments:
 Extracted requirement:
IDText
917
  • When a user installs an app bundle that is not yet physically installed, the system
    must carry out the actual installation.
 Comments:
GA: I'd like to discuss this. It pertains to Software download strategy,
OEM policy, and I think it could be controlled by AppStore just as well
the embedded system?
PW: It pertains to the software download strategy, and the way that user accounts are separated and where apps are installed — if apps are installed in any kind of system-wide prefix, then the converse of this requirement is hard to meet.
GA: I'd be just as happy leaving out this requirement - it adds little understanding in my opinion.
PW: OK. It's basically determined by whether the bundles are installed system-wide or not.
 Extracted requirement:
IDText
919
  • When a different user is active, the system should behave as if that app bundle was
    not physically installed: it must not be run, its entry points must not be available for
    launching or data sharing, and so on.
 Comments:
GA: Policy decision? But yes, agree the capability must be there.
PW: This could be a policy decision — the choice here basically depends on whether the vendor has chosen for users to have strong privacy from other users. If they have weak privacy, it would make more sense for all installed apps to be listed in each user’s launcher.
 Extracted requirement:
IDText
922
  • As an exception to that general rule, privileged app management GUIs should be able
    to enumerate the app bundles that are physically installed, for example so that they
    can illustrate how storage space has been used.
 Comments:
GA: OK
 Extracted requirement:
IDText
925
  • This could usefully be implemented by treating it as forbidden for the
    other users.
 Comments:
GA: OK
 Extracted requirement:
IDText
926
  • When a user installs an app bundle that has already been physically installed by
    another user, the system must stop hiding the app bundle from that user. For
    example, it must now be made available for launching by that user, assuming there
    is no other reason why it would be forbidden.
 Comments:
GA: For me this is implicit from the previous "store (code) only once" requirement (if we
keep that one)
PW: We wanted to make the user-visible effects of another user ‘installing’ the app explicit.
GA: I understand but I think at the high evel" of requirements we now have, whether apps are "unhidden" or installed anew is an implementation detail.
GA: I could live without this text as a requirement.
PW: OK. I think the important requirement overall in this section is that if user A installs an app,
user B (or their apps) must not be able to detect the app has been installed until they decide to
install it themselves.
 Extracted requirement:
IDText
930
  • If a user has installed an app from a particular origin, then another user is not
    required to be able to install an app of the same name from a different
    origin.
 Comments:
GA: Hmm. Same name means same identity? Let's dig into this a bit...
PW: ‘Same name’ means same identifier, yes. Identifiers for apps are meant to be globally unique; we have been using a reverse-DNS notation for this, for example ‘org.example.MyCalendarApp’.
GA: Let's change name to "application identifier" or similar - and put
whatever we choose into the definitions table.
PW: OK
GA: But I think it could be solved by simply stating that application
identifiers are unique, whether this is possible to enforce or
not, it ought to be the fundamental idea, right?

The requirement here sounds like a description of a strategy to handle an
exceptional event, i.e. in case we ever encounter two apps with identical
identifier, but it does not seem to cover every error case anyway: "another
user" - what if the same user is requesting the second installation?
Etcetera.
PW: This section exists in response to the iOS masque attack. I guess the
basic requirement is that application identifiers are globally unique, across all
installation origins.
 Extracted requirement:
IDText
932
  • If a user has installed an app at a particular version, then another user is not
    required to be able to install a different version of that app.
 Comments:
GA: Agree but it should be simple to understand. Basically just guarantee
all users have the same version. (follows from "store only once" idea).
PW: I think the wording is this way round so that it’s not disallowed for users to be running different versions of the same app — some implementations might allow this, and might strive for it in order to implement strong privacy between users. Apertis does not allow this: users must run the same version of each app.
 Extracted requirement:
IDText
934
  • If a user upgrades or rolls back an app, the app may be upgraded or rolled back for all
    other users.
 Comments:
GA: Agree. Basically I a simple model is desired. Are users at all
involved in which version of an app is being executed?
PW: Do you mean in terms of being prompted about upgrades?
I was assuming we would go with an Android-style model where the user is
told which apps are going to be upgraded soon, and then the upgrade
happens automatically unless the new version of an app requires the user
to give it more permissions. That would require user intervention.
However, as far as I am aware, no design work has happened on the user
interaction for this yet.
GA: This strategy I think is again OEM policy... So the possibility of doing this
should be there, but it's not the only way.
PW: Yes. This bullet point exists because it affects where and how apps are
installed: whether the system needs to keep multiple versions of a single app around
for different users. So the choice here significantly affects the application framework
implementation, but shouldn't affect the design too much.
 Extracted requirement:
IDText
936
  • Open question: do we want to mandate that the physical installation of apps must
    be per-device, or leave that open?
 Comments:
GA: Don't get it, please explain. AppStore/policy decision not affecting
the device right? Or do you mean "store only once" requirement.
PW: This is the ‘store only once requirement’ — installing apps per-device as opposed to per-(user, device).
GA: OK, first of I would then rewrite "per-device" into something better.
GA: Then I'm not sure. I waiver between thinking it is reasonable to
assume every code is only stored once, vs. this being an implementation
decision. If you have enough memory, and storing all applications inside a filesystem namespace that is
unique to each user might still be a simple and effective option?
Maybe even to the point of bundling all dependencies in app bundle...
PW: I think this could indeed be an OEM decision. It significantly affects the implementation of an application
framework, but shouldn't affect the design much.
 Extracted requirement:
IDText
938A vendor might wish to include app bundles in the original factory state of
the system, while subsequently allowing them to be upgraded and uninstalled by the user, in the same way
that Google apps are typically handled on Android devices.
 Comments:
 Extracted requirement:
IDText
941
  • Preinstalled apps: it must be possible to preinstall app bundles on the system, while
    leaving them available for installation management (upgrade, rollback, removal) in
    the usual way.
 Comments:
 Extracted requirement:

...

Conditional access

IDText
945App-store curators and app vendors might wish to provide publish apps on a time-limited
basis.
This is a complex topic and we recommend that it is considered separately. The Apertis
Conditional Access design has some proposed requirements for this topic.
 Comments:
GN : OK
GA: I agree. Isn't this simply covered by some general mechanism in which OEMs can
forcibly remove apps from the installation (security problem, time limited,
or deprecated for any reason). Then it becomes OEM policy decision
what to do with that possibility. Let's build in the requirements of
keeping track of installation time and other such mechanisms (must be
secure and not subvertible).
PW: Agreed. For the Apertis conditional access design, we need: timestamp of installation
or upgrade of a bundle; signature of bundle integrity from the app store; globally unique user,
device, vehicle and bundle identifiers (note that there might be multiple Apertis devices in a
single vehicle, and licensing could be separate for all of them); a way to work out when a
trip ends in a vehicle (so it doesn't remove access to an app part-way through a trip).
 Extracted requirement:

...

Appendix: mapping to GENIVI Platform Compliance Specification 10.0

IDText
951
  • SW-APPFW-AM-001 Manifest file for Application: this is the bundle metadata,
    the app permissions, and the entry point metadata (including the details
    demanded by document launching and URI launching). Open question: Do
    we need an explicit statement of what else would go in here, like required
    API levels?
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
956This appears to be taking an implementation detail (the manifest file) of
the motivating requirements (framework must be able to []) and declaring
it to be a requirement in its own right. We have attempted to re-state it in
terms of requirements.
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
960
  • SW-APPFW-AM-002 Support for LUC: Last-used context
 Comments:
GN : OK
 Extracted requirement:
IDText
961
  • SW-APPFW-AM-003 Failure handling in case of application doesn't respond on
    state change: Life-cycle management
 Comments:
GN : OK
 Extracted requirement:
IDText
963
  • SW-APPFW-AM-004 Launch application from another application: this is
    document launching, URI launching and perhaps app launching.
 Comments:
GN : OK
 Extracted requirement:
IDText
965
  • SW-APPFW-AM-005 Factory reset: Data management
 Comments:
GN : OK
 Extracted requirement:
IDText
966
  • SW-APPFW-AM-006 Prohibit to start an application: see Life-cycle
    management and specifically Forbidden apps.
 Comments:
GN : OK
 Extracted requirement:
IDText
968
  • SW-APPFW-AM-007 Activation of application, SW-APPFW-AM-008 Deactivation
    of application: What is activation?
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
970
  • SW-APPFW-AM-009 Support for activation of application (sic): from its
    descriptive text, this seems to actually be app launching.
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
972
  • SW-APPFW-AM-010 Support for switching the application (sic): from its
    descriptive text, this seems to actually mean stopping the application.
    Life-cycle management
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
975
  • SW-APPFW-AM-011 Support for pausing an application: Life-cycle
    management
 Comments:
 Extracted requirement:
IDText
976
  • SW-APPFW-AM-012 Support for resuming application: Life-cycle
    management
 Comments:
GN : OK
 Extracted requirement:
IDText
977
  • SW-APPFW-AM-013 Support for stopping application: from its descriptive text,
    this is specifically stopping a paused application. Life-cycle management
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
979
  • SW-APPFW-AM-014 Application framework shall provide a mechanism to tell an
    application to change its state: the states specified are START (not running),
    BACKGROUND (running and in background), SHOW (running and in
    foreground), RESTART (from its descriptive state not actually a state, and
    not the systemd-style restart action either, but in fact the "resume"
    transition from PAUSE to either SHOW or BACKGROUND), OFF (what is the
    difference between this and START in terms of states?), and PAUSE
    (understood to be essentially SIGSTOP'ed). See Life-cycle management.
 Comments:
GN : This being worked out.
 Extracted requirement:
IDText
987These state names demonstrate some confusion between states and state
transitions. We have specifically documented states, not transitions, and
provided details of the allowed transitions.
 Comments:
GN : This being worked out
 Extracted requirement:
IDText
990
  • SW-APPFW-AM-015 Application states: the states specified are either
    (INSTALLED, ACTIVATED, LAUNCHED, PAUSED) or (START, BACKGROUND,
    SHOW, RESTART, OFF, PAUSE) depending which column we believe. See Lifecycle
    management.
    It is unclear what these states mean, particularly ACTIVATED. We have
    described a different set of states in these requirements.
 Comments:
GN : This being worked out
 Extracted requirement:
IDText
996
  • SW-APPFW-AM-016 Installed application info: this is the part of app launching
    that deals with listing what we can launch.
 Comments:
GN : OK
 Extracted requirement:
IDText
998
  • SW-APPFW-AM-017 Access restriction for apps: this is our sandboxing and
    security. It's a big topic in its own right.
 Comments:
GN : Agreed. This is discussed under access mechanism.
 Extracted requirement:
IDText
1000
  • SW-APPFW-AM-018 Support for different applications running in different
    runtimes: the application framework should support JVM- or HTML5-based
    runtimes. Stated in What's in an app.
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:
IDText
1003
  • SW-APPFW-AM-019 Support for any number of applications: stated in What's in
    an app, under the assumption that this is referring to lack of arbitrary
    limits. If the intention is to cope with exceeding RAM by telling excess apps
    to shut down gracefully, that's harder but could be done. If the intention is
    to cope with exceeding flash space by "swapping out" apps to cloud
    storage or something, that's impractical for a device that might not have
    constant connectivity and should not be required.
 Comments:
GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
 Extracted requirement:

...

Appendix: mapping to Suma's proposed requirements

IDText
1011
  • App-FW-001 Protect the system against altering of any data by a malicious app:
    App integrity, System integrity, Per-user data, etc.
 Comments:
GN: OK,
type : Req mapping
 Extracted requirement:
IDText
1013
  • App-FW-002 Protect the system against collecting and sharing of any data by a
    malicious app: App confidentiality, Private data, Per-user data etc.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1015
  • App-FW-003 Protect the system against usage of system resources etc.:
    Resource limits
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1017
  • App-FW-004 An application shall not [~gunnar.andersson: ] interfere with [~gunnar.andersson: ] the … … other application:
    App integrity, App confidentiality, Private data
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1019
  • App-FW-005 read, alter or delete non-application data: System integrity, Peruser
    data.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1021As written, this requirement states that this must be forbidden entirely. We
have assumed that the intention was to forbid it with exceptions where
necessary for the app to do its job.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1024
  • App-FW-006 Users data are protected against access by another user: Private
    data, Per-user data
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1026
  • App-FW-007 deny access to APIs to which an App has not requested permission:
    Sandboxing and security
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1028This requirement wrongly conflates APIs with privilege boundaries. There is
never any reason to deny access to APIs that do not cross a privilege
boundary, because such APIs cannot do anything that the app could not do
itself.
 Comments:
GN : Agreed.
 Extracted requirement:
IDText
1032
  • App-FW-008 per-app rollback: Rollback
 Comments:
GN : under discussion
 Extracted requirement:
IDText
1033
  • App-FW-009 Shall support applications with UI or UI less: What's in an
    app
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1034
  • App-FW-010 Restore LUC: Last-used context
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1035
  • App-FW-011 information about mime type: Document launching
    Consideration has been given to possible ways to select file types, other
    than media types. We have included the recommendation that using
    anything other than IETF media types would be unwise.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1036
  • App-FW-012 Resource handling: Life-cycle management
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1040
  • App-FW-013 Inform apps about states: Life-cycle management
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1041
  • App-FW-014 shutdown: Life-cycle management
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1042
  • App-FW-015 Frozen state: Life-cycle management (we're calling it "pause" in
    this document)
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1044
  • App-FW-016 blacklist apps:
    We think this may be conflating two distinct behaviors. The first is to cope
    with apps that go into a crash loop, which must be rate-limited. The second
    is to have a way to stop apps executing altogether, which this document
    refers to as Forbidden apps.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1049
  • App-FW-017 apps with a validity period: Conditional access
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1050
  • App-FW-018 app requesting permissions every launch: App permissions.
    Note that we only really recommend this for permissions where there's
    nothing better we can do, like "unrestricted Internet access".
 Comments:
 Extracted requirement:
IDText
1053
  • App-FW-019 apps can communicate with other apps: Data sharing
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1054
  • App-FW-020 Content hand-over: Document launching, URI launching.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1055
  • App-FW-021 content type can be opened only by...: Document launching
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1056
  • App-FW-022 It shall be possible for an app to register a new content type: Adding
    media types
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1058
  • App-FW-023 Sharing a content to be transferred out of the system: (Androidstyle
    Sharing API): Sharing menu
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1060
  • App-FW-024 POI provider but no access to location data: implicit in sandboxing
    and security and app permissions.
    This requirement appears to be conjecturing that registering an app as a
    points-of-interest provider would cause it to have additional permissions
    somehow, but whether an app is registered as a points-of-interest provider
    should be entirely orthogonal to whether it has the permissions that would
    allow it to access location data.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1067
  • App-FW-025 to App-FW-032 Download manager: Download management
 Comments:
 Extracted requirement:
IDText
1068
  • App-FW-032 to App-FW-036 Internationalization: not mentioned here.
    As Gunnar says, this is a SDK API issue, not a platform services issue. It is
    entirely feasible to implement internationalization through a shared
    library provided by the platform (part of glibc in practice) and some data
    files in the app (gettext .mo files) without ever crossing a security
    boundary, and we recommend doing exactly that.
 Comments:
GN : Agreed
 Extracted requirement:
IDText
1074
  • App-FW-037 installation of application bundles: Installation
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1075
  • App-FW-038 Native application: we are unsure how this is relevant to a
 Comments:
GN : Not in the scope of Managed Apps handling.
 Extracted requirement:
IDText
1076GENIVI design, since the interaction between vendor-supplied native apps
and the vendor-supplied platform is presumably up to the vendor.
 Comments:
GN : We need to cover those areas which are coomon and can be generalized.
 Extracted requirement:
IDText
1078Terminology note: GENIVI's native applications are the same thing as Apertis'
built-in applications. It is nothing to do with whether the app is written in
native code compiled from C/C++. GENIVI applications that are not native
applications are said to be managed applications, which are the same as
Apertis' store applications.
 Comments:
 Extracted requirement:
IDText
1083
  • App-FW-039 Pre installed app vs. store downloadable apps: Preinstalled
    apps
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1084
  • App-FW-040a Install app from a storage device: Installation
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1085
  • App-FW-040b sync up with app store: We have interpreted this to mean that
    after installation from removable media, it must still be possible to
    upgrade via the Internet.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1088
  • App-FW-041 facilitate handling of permissions: app permissions
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1089
  • App-FW-042 provide data storage structure to an app: private data and
    optionally per-app data, per-device data, per-user data.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1091
  • App-FW-043 an app can't contain more than one program … or more than one
    agent/service: What's in an app
 Comments:
 Extracted requirement:
IDText
1093There has been some resistance to this requirement, and we have written
the requirements in this document to say that vendors may impose this
limit, but the framework should not.
 Comments:
GN : Agreed.
 Extracted requirement:
IDText
1096
  • App-FW-044 system extensions: What's in an app
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1097
  • App-FW-045 downloaded and installed only once (i.e. apps appear to be peruser
    but are really system-wide): Installation management
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1099
  • App-FW-046 queueing mechanism for app download (i.e. apps do not install in
    parallel): Software download limiting
 Comments:
GN: OK, type : Req mapping
 Extracted requirement:
IDText
1101
  • App-FW-047 App upgrades shall be checked periodically: Upgrade.
 Comments:
GN: OK, type : Req mapping
 Extracted requirement: