Re: Automatic session resumption

Hi Anton, All,

On 17 Apr 2014, at 18:04, Anton Vayvod <avayvod@google.com> wrote:

> Hi Konstiainen,
> 
> Thanks for the prompt reply.

Sorry for the delay in replying. I was occupied with the things around chartering.

> My comments/questions are inline (hopefully removing the Gmail formatting will make it readable):
> 
> 
> On Thu, Apr 17, 2014 at 10:46 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
> >
> > I have couple of clarifying questions:
> >
> > * The use case you have in mind is to allow the session to persist so that user’s consent is not required as long as the session is not explicitly closed e.g. by invoking close() on the session. Correct?
> 
> The use cases we have in mind are in the rationale section of the OP. Basically, if the presenting website navigates within the origin or the user opens the same-origin page in another tab/window, the session object received from the requestShow() call is unavailable to the navigated page or the second page. However the developer might want to provide a session experience to the user: as long as the user navigates within the site, there's some control over the session; if the user opens the same page in another tab, the user still has control over the session from there.

Ok, got the use case. Do you think the same-origin restriction is enough? The following pages would have access to each others' sessions:

http://example.org/~joe/index.html
http://example.org/~evil/foobar.html

> > * Should the user be able to disassociate the session through the UA somehow (think evil.example.com establishes a session the user would like to get rid of)?
> 
> Yes, I believe this would certainly be a nice thing to have.

Ok. This is something we could add in the non-normative security and privacy considerations section.

Then, what are the other means to disassociate a session? I’m thinking of the following, please fix any bugs/omissions:

* the page calls close() on the PresentationSession
* the UA closes the session without user’s action (error condition etc.)
* the user closes the session via the UA-provided menu

Others?

[...]

> > Below further comments on the concrete proposal itself (assuming your proposal is extending the group’s recent thinking represented at [1]).
> >
> > > IDL:
> > >
> > > partial interface Presentation {
> > >   PresentationSession[] activeSessions();
> > >   EventHandler onsessionchange;
> > > }
> >
> > s/Presentation/NavigatorPresentation/ I guess?
> 
> Yes.

Ok.

> > Do you think activeSessions() can return the list of PresentationSession objects in a reasonable time so that you don’t block the main thread? If there’s a possibility this takes longer than couple(?) of milliseconds, it would be better to either use a callback or return a Promise instead. Also making this asynchronous would allow some implementations to optionally prompt the user if they wish to.
> 
> We considered having a Promise but then there would be two async ways of updating the state. What if onsessionchange event fires after the developer gets the promise but before the success callback is called? In the split browser-renderer architecture, the renderer would have to keep a copy of the active sessions list for the origin and update it to be able to provide activeSessions() in an async way.

Thanks for clarifying the implementation aspects.

Then, do we want to allow implementations to be able to prompt the user before sharing the sessions with another same-origin page?

Say, you navigate to the page at http://example.org/~evil/foobar.html. I’d say the UA should be able to ask the user the following question before sharing my sessions from http://example.org/~joe/index.html with the page:

“http://example.org wants to access your presentation sessions. [ Deny | Allow ]”.

For this to work without blocking the main thread we’d have to return the sessions asynchronously.

[...]

> > > presentation.onsessionchange = function(e)  {
> > >   var session = e.session;
> > >   if (session == mySession) {
> > >     // got an update for the session started/joined from this page
> >
> > What would be the PresentationSessionState here? We may need to rework the states (see the PresentationSession interface at [1]) for a better fit. Feel free to propose a set of states that would work for your use case.
> 
> I think 'connected'/'disconnected' is enough for onsessionchange. If we need to check the session state before it's connected, we need some 'initializing' state probably. We might want to add some 'invalidated' state to distinguish 'disconnected' by the origin or for some reason the origin/user can't control like connection failure or something started its own session with the same device, evicting our session this way. This distinction might be important for the developers to show the appropriate error message to the user.

The current states are:

enum PresentationSessionState { "connected", "disconnected" };

Your proposal:

enum PresentationSessionState { "connected", “disconnected”, “initializing”, “invalidated" };

If we have good use cases that require the “initializing” and “invalidated” states then we should add them.

> > >   } else {
> > >     // |session| isn’t a session this page has started/joined,
> > >     // use it or not - up to the page
> > >   }
> > > }
> > >
> > > Semantics:
> > >
> > > If the browser has previously connected to any session or multiple sessions via |requestSession()| called from the same origin, e.g. 'http://example.com/sender', the |activeSessions()| array will contain the list of the session objects that can be used immediately from the current page.

[...]

> What do you mean by inactive sessions?

After revisiting this, I think an inactive session can be considered a special case of a session that has its state set as ‘disconnected’.

> The presenting origin would only have active sessions that are the sessions actually running on some screens (we use an array here to allow presenting to more than one screen at a time) and once the session gets into 'disconnected' state it essentially becomes useless.

Ok, so all the entries returned by the activeSessions() are session in the “connected” state? Any sessions that transition to other states are dropped from the array, and we signal that by firing the ‘sessionchange’ event on the Presentation interface.

Sounds good to me.

[...]

> > Does it make sense to carve out something like “PresentationScreen” that represent the screen with its own states and handlers, to clearly decouple it from PresentationSessions?
> 
> I don't think this is necessary. Could you elaborate more on what states/handlers you would add?

It appears my thought experiment was not a good idea, so I save you from elaboration :-)

Thanks for your proposal, and please share your implementation feedback with the group so we can iterate further.

Thanks,

-Anssi

Received on Monday, 19 May 2014 08:22:30 UTC