Re: User agent context for rendering the presentation

A related but important point is that of user control over persistent data.

UAs generally provide clear means of accomplishing this by clearing
browsing data, cookies, etc.  This is in addition to private browsing /
incognito mode, where this data is not persisted to begin with.

In the 1-UA case, it seems relatively straightforward that both the normal
and presentation UA contexts can be cleared when the user takes such an
action.  In the 2-UA case, it seems much harder - and it may even be
impossible - to provide any means by which the user can clear any
persistent state on the presentation UA.

Making persistence optional (beyond the scope of a presentation session)
seems like a pragmatic way to approach this, but given the lack of user
control I suspect that for privacy reasons many implementations will opt
not to implement persistence beyond the lifetime of a session.

Mark.


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

> On Mon, Aug 25, 2014 at 5:39 PM, mark a. foltz <mfoltz@google.com> wrote:
> > 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.
>
> Sounds good.
>
> > 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.
>
> I generally agree. But I also think that if we just throw up our hands
> and say that this is a web developer problem, then we'll see a lot of
> security issues in websites. Very few applications deal with the fact
> that multiple users could be using the same device. This goes both for
> websites as well as traditional "native" apps.
>
> This is why OSes has always provided some form of account/profile
> management which has automatically handled separating data per-user
> for applications.
>
> / Jonas
>
>