Re: User agent context for rendering the presentation

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

Received on Tuesday, 26 August 2014 01:36:56 UTC