espinr
commented
1 year ago Thanks @QingAn . We need to solve these issues as soon as possible, I agree.
1) About the origin model
If the MiniApp is served through HTTP, we can guarantee the same-origin policy if we always recommend secure transmission (TLS and OCSP), as the Web resources work. So, when a user agent fetches a MiniApp using the Web, it might preserve the origin model.
If there was no such control (because the user agent cannot control the origin, like if you share a MiniApp through other potential protocols or means), the user agents should show some warning, like when browsers access non-secure environments.
In this case, the URL we fetch represents the origin so that we can solve the problem.
We have also proposed an additional member for a security policy (CSP) (w3c/miniapp-manifest#42) in the manifest (i.e., trusted sources). It could identify the origin for those cases that user agents cannot get from the HTTP exchange.
What if we don't have the MiniApp on the Web?
I agree the package should be verified, even if there are no HTTP requests. Should we recommend a Web-based mechanism to confirm that the package comes from a specific origin?
One potential scenario is that different origins distribute the same MiniApp (like different marketplaces), and the package is stored locally in the device. In this case, the user agent doesn't need to fetch the package because it is already in the local filesystem. Still, the MiniApp is the same.
If we need to preserve the concept of origin, we could specify an optional URI to identify the publisher. This could become the origin of the MiniApp?
It could be a field in the manifest, part of the Content Security Policy.
¨content-security-policy" :
{
"origin": "trusted1.example.org",
"default-src": [ "trusted1.example.org", "trusted2.example.org" ],
}Adapting the previous example, we would have something like this:
2) Package can be modified by an intermediary
Yes, this is a challenge. The current packaging specification is flexible to include any signatures (and methods) to preserve the identity of the original developer and publisher. We don't recommend any specific encryption method or algorithm to offer flexibility.
Signed HTTP exchanges might be a good solution, but we cannot rely on them because the user agent may not have access to these HTTP headers. For instance, if we have a MiniApp in the file system and we want to install it into your super app. The HTTP exchanges were made before using a Web Browser; they are not accessible to the MiniApp user agent.
The current model enables something like this: adding several signatures (the user agent may verify) and proof of the integrity of the package.
I may be missing something here. But I think we might cover the challenge (although we don't recommend anything specific, we could do it explicitly).
3) ZIP
ZIP could be less efficient, and a large file might cause poor UX. It was already identified in the earliest analysis and explainer. The choice was made based on current practices, the availability of tools, and the nature of MiniApps (light by definition).
I hope this serves as food for thought and start the discussions with some options on the table. Comments?
Sharonzd
Hi, I open an issue to discuss the comments from TAG. @espinr @MichaelWangzitao @Sharonzd
The first comment "Origin model" are related to MiniApp specs as a whole.
The second and third comments I think are more directly related to MiniApp Packaging.
For clarity, we'd like to separate the concerns we have in terms of priority.
On the Web, it is done cryptographically via TLS and OCSP. In app stores, native applications are using validation done by the app store (like universal link), but this is not a first-hand verification (see the point below about responsabilities of the intermediary).
Note that files contained in the package act as a local cache for content relative to the origin, and as such should be verifiable to ensure that the origin-model is applicable here, even if no HTTP request will ever reach the network but would always be dereferenced to the content of the mini app package.
There are notions about digital signatures in the response, but without knowing exactly when the signing happens by who, there isn't a guarantee that the content is as it came from the origin. If there is strong enforcement to guarantee that the signing is done at the point where it leaves the origin (or an equivalent first-party), this would be a way forward.
We are empathetic to the choice made here, but if there is a possibility for swapping this out to something that is friendlier to low-bandwidth environments (e.g. following the game example - you don't need stage 2 content of a game unless you actually reach stage 2, and there are no guarantees that the user will play that long) as saving on transmission is beneficial to the user. (It also allows for faster loading, even for users on performant networks.)
An alternative design would be to use Service Workers as a delivery mechanism, and keep the packages light - but this comes at a cost of complicating the developer experience. Alternatively one could argue this is doable with fetch(), but these are high-level alternative approaches one could take to move away from a monolithic package which is suboptimal with ZIP.