Re: User agent context for rendering the presentation

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.
>

​This is a balance between allowing sites that care to do the best thing
for UX vs preventing sites that don't care from messing up.

In the Netflix case, what I would like to happen is for this to be handled
by the application. If a new session is created, and the presentation side
finds there is information in IndexedDB, then it would first check whether
the user id being used by the controlling device matches the credentials in
IndexedDB (it would get the user id from my own secure
controller<->presentation protocol​.) - if they match, then I can avoid a
login process and get straight to doing the user's bidding. If they don't
match, then I'll ditch the pre-existing information from IndexedDB and
start afresh.

I don't think this is so difficult for sites: for any site with a notion of
login credentials the first thing the presentation side is going to need to
know is what credentials to use to log in. Partitioning any local state by
login credential (or whatever makes sense for that site) is a basic thing
they need to do as a matter of course.

...Mark



>
> / Jonas
>