What are sessions?

[pes10k]

This issue is being filed as part of of PING's horizontal review

The Privacy Considerations section states:

The user agent SHOULD implement mechanisms to remember their preferences, and the end-user SHALL explicitly decide if this information is stored across sessions. No other information related to the manifest should persist across sessions.

What a session is, how long it lasts, etc is not defined in the spec. This is critical to define since "session" is being used as a privacy boundary here (things that stay in one session shouldn't, by default, be available in other sessions). The spec should either define what a session is for MiniApps, or if its defined in another spec, link to where a session is defined

[espinr]

It's a very good point, @pes10k

I was referring to 'session' as the period starting with the launch of the app and when it is destroyed (so the cached information is deleted). We could define it accurately based on the two events and status changes produced in the mini app engine. The Lifecycle spec describes the launched global state, but it doesn't mention anything regarding the termination or destruction (similar to the controversial window.unload event).

I did some quick research to understand how the current mini app implementations in this group handle this (most of the documentation in Chinese so my apologies if I missed anything).

Alipay Mini Programs have the launch event when the mini app is initialized. The app runs in the background and is destroyed after some time, based on the following: "Only when the mini app goes in background state for a certain time, or takes up too much system resources, will it be destroyed." So, in this case, the session depends on the configuration of the mini app engine, but there is no event triggered when the app terminates the session.

Baidu Smart Program triggers the launch event and it doesn't allow users to force the destruction of the app. The user agent will destroy the app only in the following cases:

• "Enter the background for more than 5 minutes;"
• "System resource usage is too high;"
• "The number of open mini apps exceeds the limit supported by the system (the system destroys the applets in the order in which they were opened)." But there is no specific information about resource usage and the number of mini apps allowed in the background.

The case of Quick Apps (Xiaomi, Huawei) is simpler, so we could consider a session as the period between the create and destroy page events and subsequent change of status. See the documentation.

Implementation	Session starts when	Session ends when
Alipay Mini Programs	launch event	X time in background state; or exceeds Y resources
Baidu Smart Programs	launch event	5m in background state; or Y mini apps launched; or exceeds Z resources
Quick App (Xiaomi, Huawei)	create event	destroy event

I'm raising a question to understand if there is a plan to introduce a destroy event in the app lifecycle. Otherwise I think we need to include some text to clarify when the app and its cached information is destroyed in the system (we can use to mark when the session is finished).

[pes10k]

Thanks @espinr this is all very helpful. I think its important to specify this in the spec though, since it seems like differences in "session" definition would cause interop problems (and so kinda undo a main purpose of the standard), no?

[Sharonzd]

@espinr Thanks for your hard work.

'session' as the period starting with the launch of the app and when it is destroyed

I agree with the definition of "session", and we indeed need to add destroy event.

The user agent SHOULD implement mechanisms to remember their preferences, and the end-user SHALL explicitly decide if this information is stored across sessions. No other information related to the manifest should persist across sessions.

But I am sorry to point out another comment under this quotation, not about the definition of the session, but about where the permission information should be placed.

In the existing vendor implementations, if a user approves granting a requested permission from a MiniApp, the permission will remain until the user goes to the MiniApp setting page to cancel the authorization, just like the App authorization mechanism on an iPhone.

I think this is necessary because if the authorization information is only stored in the session, it means that users need to repeat the granting operation every time reopen the same MiniApp, which would reduce the user experience.

( Maybe I need to create another issue, right?)

[espinr]

Thanks @Sharonzd. The definition of session seems to be solved. This is another (good) point.

I'll open another issue, based on your comments.

[espinr]

Closing this issue, after merging w3c/miniapp-packaging#65, that includes the definition of a session based on events. Conversation about keeping preferences data across sessions continues in #67 .