Re: User agent context for rendering the presentation

I responded in a different fork of this thread, but I'll try to summarize
the issues here.

For the 1-UA case:

1a.  It seems reasonable for the browser to persist data across
presentations.
1b.  Persistent storage for presentations should be separate from the
storage used by the controlling page, so that the presentation can be
rendered in a separate UA without dependency on the controlling page's
storage.
1c.  It may not be mandatory to provide persistence across presentations.
 However it should persist across navigations within the same presentation
session (otherwise no point).
1d.  The presentation should function normally if initially loaded with
empty storage (because the user cleared it, or the browser did not
implement persistence across sessions, etc.).  However it will be slower,
requiring more messages/round trips to the server.

For the 2-UA case:

2a.  Concern that hardware vendors will not implement storage management
correctly (or at all?)
2b.  Concern about mixing information from multiple users.
2c.  User experience requirement to leave the presentation UA "logged in"
to a user account but also allow a controlling page to use their logged in
account instead.

To address 2a I think making the persistence across sessions optional (not
mandatory) will simplify the life for hardware implementations.  This means
they can use one persistent store and clear it after each session.  As
implementations improve they can adopt more sophisticated storage
management.

At first glance 2b and 2c is really a Web developer problem.  The concept
of "user account" is really from the application domain and I can imagine a
number of ways to solve this.  For example:

- The presentation URL requires parameters with the account id and
authentication token vended by a trusted server.
- Presented page verifies token with the server and accepts account id for
the session if successful.
- Presented page stores current account id in a cookie.  If it sees a new
id it clears state (cookies) from the old id.
- Partition the IndexedDB by user account and use the cookie-stored id to
keep track of which partition is in use.

...among other solutions.   However, it would still be worthwhile to make a
working prototype of this sort of scenario as it will be common for content
providers.

m.


On Mon, Aug 25, 2014 at 5:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Aug 25, 2014 at 10:09 AM, Mark Watson <watsonm@netflix.com> wrote:
> > Let's forget about apps and TVs and just consider regular UAs (one or
> two of
> > them): All I am saying is that if the presenting page stores something in
> > IndexedDB, then next time that same presenting page is loaded on the
> same UA
> > it should be able to retrieve the stuff it stored in IndexedDB, unless
> the
> > user has cleared it, of course. It had been proposed that IndexedDB is
> > *always* cleared before a presenting page loads, and that's what I'm
> > reacting to.
> >
> > As far as the controlling and presenting pages are concerned, they should
> > not be able to distinguish the 1-UA and the 2-UA cases.
> >
> > I believe a consequence of this on UAs that support rendering both the
> > presenting and controlling pages (i.e. a UA that supports the 1-UA case
> or a
> > UA that supports both presenting and controlling sides of the 2-UA case)
> is
> > that IndexedDB needs to be scoped not just by origin but by the pair (
> > origin, presenting | controlling ).
>
> I'm fine with allowing the presentation page to persist data across
> restarts. I don't think that we can mandate it because UAs need to be
> free to toss out data at will due to security/privacy/storage
> policies.
>
> Another issue is that UAs need to take care not to expose wrong user
> data. If for example I used the presentation API to look at my
> facebook feed on a TV, and then my room mate the next day uses his
> laptop to do the same thing, I think both him and I would be
> disappointed if the TV showed a jumble of his and my facebook data.
>
> We could certainly say that it's the website's responsibility to make
> sure to clear or separate any stored data if a different user
> connects. And that if it doesn't do so it's a bug in the website. But
> I think that would result in a lot of buggy websites.
>
> It seems like a reasonable UA policy to make sure that if a new
> session is established with a different identifier (as pass to
> requestSession) that data previously created is not used. If this
> means that the data is deleted, or if the UA keys its storage on not
> just origin but also on session identifier, seems like a UA decision.
>
> / Jonas
>