Re: User agent context for rendering the presentation

On Tue, Aug 26, 2014 at 11:31 AM, Mark Scott <markdavidscott@google.com>
wrote:

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

​This is all fine for me. My objection was only to the idea of prohibiting
persistence in the specification.

...Mark​




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