JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
...
ID | Text |
---|---|
899 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
904 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
905 |
|
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: |
ID | Text |
---|---|
908 | Is 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: |
ID | Text |
---|---|
914 | On 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: |
ID | Text |
---|---|
917 |
|
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: |
ID | Text |
---|---|
919 |
|
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: |
ID | Text |
---|---|
922 |
|
Comments: GA: OK | |
Extracted requirement: |
ID | Text |
---|---|
925 |
|
Comments: GA: OK | |
Extracted requirement: |
ID | Text |
---|---|
926 |
|
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: |
ID | Text |
---|---|
930 |
|
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: |
ID | Text |
---|---|
932 |
|
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: |
ID | Text |
---|---|
934 |
|
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: |
ID | Text |
---|---|
936 |
|
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: |
ID | Text |
---|---|
938 | A 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: |
ID | Text |
---|---|
941 |
|
Comments: | |
Extracted requirement: |
...
ID | Text |
---|---|
945 | App-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: |
...
ID | Text |
---|---|
951 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
956 | This 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: |
ID | Text |
---|---|
960 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
961 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
963 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
965 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
966 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
968 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
970 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
972 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
975 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
976 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
977 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
979 |
|
Comments: GN : This being worked out. | |
Extracted requirement: |
ID | Text |
---|---|
987 | These 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: |
ID | Text |
---|---|
990 |
|
Comments: GN : This being worked out | |
Extracted requirement: |
ID | Text |
---|---|
996 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
998 |
|
Comments: GN : Agreed. This is discussed under access mechanism. | |
Extracted requirement: |
ID | Text |
---|---|
1000 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
ID | Text |
---|---|
1003 |
|
Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance. | |
Extracted requirement: |
...
ID | Text |
---|---|
1011 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1013 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1015 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1017 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1019 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1021 | As 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: |
ID | Text |
---|---|
1024 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1026 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1028 | This 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: |
ID | Text |
---|---|
1032 |
|
Comments: GN : under discussion | |
Extracted requirement: |
ID | Text |
---|---|
1033 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1034 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1035 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1036 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1040 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1041 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1042 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1044 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1049 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1050 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
1053 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1054 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1055 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1056 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1058 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1060 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1067 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
1068 |
|
Comments: GN : Agreed | |
Extracted requirement: |
ID | Text |
---|---|
1074 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1075 |
|
Comments: GN : Not in the scope of Managed Apps handling. | |
Extracted requirement: |
ID | Text |
---|---|
1076 | GENIVI 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: |
ID | Text |
---|---|
1078 | Terminology 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: |
ID | Text |
---|---|
1083 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1084 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1085 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1088 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1089 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1091 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
1093 | There 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: |
ID | Text |
---|---|
1096 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1097 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1099 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |
ID | Text |
---|---|
1101 |
|
Comments: GN: OK, type : Req mapping | |
Extracted requirement: |