Re: User agent context for rendering the presentation

With two different users, this suggests the problems that arise are 
privacy issues. Is it the case?

If I understand things correctly, with the suggested presentation ID 
mechanism, a presentation session would be identified by the origin of 
the presentation app and a presentation ID, typically generated by the 
controlling app.

In particular, in the 2-UA case, two different users will be able to 
(re-)connect to a running presentation as long as they have the right 
presentation ID. In the case when a first user leaves the presentation 
session opened, a second user can thus get access to the data left by 
the first one as long as the presentation session is opened, unless the 
controlling app takes care of that by using a user ID or an 
authentication token as presentation ID to control who can reconnect to 
the session.

My point here is that the API does not distinguish between users but 
leaves that to the controlling application. Couldn't the presentation ID 
be used to scope data that oulives a presentation session such as 
cookies, cache, local storage?

Note the reason why I insist on data being preserved is that it seems 
like a useful feature in many cases. After all, the very definition of 
Web Storage is "an API for *persistent* data storage" [1] and IndexedDB 
introduces itself on similar grounds [2].

Francois.

[1] http://www.w3.org/TR/webstorage/#abstract
[2] http://www.w3.org/TR/IndexedDB/#introduction


On 2014-08-20 17:05, Anton Vayvod wrote:
> The problems might arise when the same presentation is started by two
> different users. If there's any persistent state, then the second user
> might get access to the data left by the first one.
> Cache doesn't have to be cleared, perhaps, to accommodate the image
> collection use case.
>
> On Wed, Aug 20, 2014 at 3:04 PM, Francois Daoust <fd@w3.org
> <mailto:fd@w3.org>> wrote:
>
>     Do these features have to start empty and be emptied at the end of
>     each session though? It makes sense in incognito windows because the
>     goal is not to leave any trace. Presentation sessions do not have
>     that requirement.
>
>     Let's say the presentation content is a slideshow that uses local
>     storage to maintain the collection of images displayed, having to
>     retrieve that collection from some backend server each time the
>     presentation starts would take much more time than simply checking
>     whether the contents of the local storage is up-to-date on
>     subsequent loads. The app obviously needs to handle the case when
>     the local storage is empty, but it would be good if it could also
>     take advantage of the local storage across sessions.
>
>     Francois.
>
>
>     On 2014-08-20 15:15, John Mellor wrote:
>
>         Drive-by: perhaps it would be better to say that presentation
>         content
>         has access to all these features as usual, but they always start off
>         empty (and are emptied at the end of the session), as if the
>         presentation content were launched in its own incognito window.
>
>
>         On 20 August 2014 13:47, Anton Vayvod <avayvod@google.com
>         <mailto:avayvod@google.com>
>
>         <mailto:avayvod@google.com <mailto:avayvod@google.com>>> wrote:
>
>              Hi Francois!
>
>              The intent here wasn't to disable the feature for the
>         presented page
>              but to force the developers to only use the provided messaging
>              channel between the presented and presenting pages. If the
>         presented
>              page relies on the presenting one to store something in the
>         cache or
>              IndexedDB for it, it can be implemented to work in the 1-UA
>         case but
>              not in the 2-UA case. The presented page should have access
>         to these
>              HTML features if the user agent running the presentation
>         supports it.
>
>              I think the wording for the above list should be clarified that
>              there's "no access to cookies, local storage or IndexedDB
>         instances
>              in the browser context of the page that initiated the
>         presentation".
>              The same way as the same page loaded in a normal Chrome
>         window and
>              in an Incognito window will have no way of communicating
>         with its
>              instances through the use of cookies or storage APIs.
>
>              Hope it helps,
>              Anton.
>
>
>              On Wed, Aug 20, 2014 at 12:09 PM, Francois Daoust
>         <fd@w3.org <mailto:fd@w3.org>
>              <mailto:fd@w3.org <mailto:fd@w3.org>>> wrote:
>              >
>              > Hi Mark, Jonas, Anton, et al.,
>              >
>              > I have a question on the need to restrict the access to
>         certain features for presentation content.
>              >
>              > On 2014-08-14 02:05, mark a. foltz wrote:
>              > [...]
>              >>
>              >> 4. User agent context for rendering the presentation.
>              >>
>              >>
>              >> If we intend the same presentation content to be
>         rendered either in the
>              >> same user agent or a remote user agent, we need to
>         carefully define the
>              >> rendering context so that the application doesn’t get
>         different behavior
>              >> according to whether it is rendered remotely or
>         locally.  In particular
>              >> the presentation rendering context must have:
>              >>
>              >>
>              >> - No access to cookies, local storage or IndexedDB instances
>              >>
>              >> - No access to HTTP cache
>              >>
>              >> - No access to pre-existing SharedWorkers
>              >>
>              >> - Extensions are debatable - some may be required for
>         e.g. VPN or
>              >> firewalls to work correctly
>              >
>              >
>              > I understand the need to have the presentation rendering
>         context behave similarly whether it runs locally or remotely,
>         but I don't see the implications in terms of restricting access
>         to the features mentioned above. For instance, I don't
>         understand why having access to the local (or remote) IndexedDB
>         could pose a problem. A Web app that uses IndexedDB cannot
>         assume that the database exists, has the right version, or is
>         not being used by another tab that shares the same origin at the
>         same time. How is running a presentation context locally or
>         remotely any different?
>              >
>              > Could you clarify why it matters? What issues are you
>         trying to prevent?
>              >
>              > For example, in the AwesomeGame example that Jonas
>         presented elsewhere in the thread, it would make sense to me to
>         have the "full game" run on the TV set. If the game makes use of
>         IndexedDB when it's available, then not being able to use it on
>         the TV set could noticeably affect performances or available
>         features.
>              >
>              > From a developer perspective, it would also mean that
>         presentation apps would not have the same powers as regular Web
>         apps and would need to be specifically tailored as presentation
>         apps, which strikes me as odd. I would rather expect to be able
>         to take any Web app, even one that does not degrade gracefully
>         when e.g. IndexedDB is not available, complete it to run within
>         a presentation session, and be confident that it will work in
>         any environment that supports the features that the app is
>         using. Granted, it's always good practice to degrade gracefully
>         (or rather to enhance progressively) but it's not a reason to
>         make that practice a requirement, especially for features that
>         developers rightfully start to take for granted in most browser
>         environments.
>              >
>              > Thanks,
>              > Francois.
>
>
>

Received on Wednesday, 20 August 2014 16:47:26 UTC