W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2017

Re: Proposal from Web-based Signage BG

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Tue, 3 Oct 2017 12:52:51 +0000
To: Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp>
CC: W3C Devices and Sensors WG <public-device-apis@w3.org>, "public-websignage@w3.org" <public-websignage@w3.org>
Message-ID: <CFB406B6-11EB-44DD-9EF3-3ED404620A10@intel.com>
Hi Tanaka-san, Web-based Signage BG members,

Thank you for your proposal.

I'd ask you to kindly provide us further information by responding to a couple of questions that were raised in initial discussions with DAS WG participants.

First, we observe your charter proposes two normative deliverables [1], and we focus on them, namely:

Power Status Management
Contextual Information

# General comments

We are not clear whether the proposed APIs are signage-specific. It seems they are not meant to be implemented in a typical user agent, that is a web browser running on a mobile device or desktop.

The DAS WG Charter [2] states that:


APIs that cannot be demonstrated to be implementable securely within the default browser context will not be released.


That suggests the proposed APIs might be out of scope for DAS WG given its current charter.

# Power Status Management

There is no input draft for the Power Status Management deliverable. The DAS charter explicitly states [2]:


The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase.


We would prefer to see incubated drafts for any deliverables considered to be added to the DAS WG Charter.

We encourage you to review the Battery Status API [3] and evaluate whether it satisfies your requirements with respect to Power Status Management. You could also propose extensions to the said specification if they are not signage-specific, that is address a generic requirement that is not signage-specific. Feel free to open such feature requests directly on the specification's GitHub repo.

# Contextual Information

[Comments based on the input draft [4] linked to from the charter proposal.]

We have a concern that the proposed API exposes a fingerprinting vector (see [5]) and feel the use case [6] would be better addressed using a different mechanism. We would like to hear what are your plans to mitigate the fingerprinting issue.

We also observe the spec targets a class of devices called "web-runtime" [7] distinct from a web browser. As noted earlier, the DAS WG is scoped to develop APIs implementable in web browsers.

# Follow-up

DAS WG will discuss your proposal on its next bi-weekly teleconference 7 October 9am ET / 2pm GMT / 4pm EST (agenda to be sent shortly to public-device-apis). Since the timing of the call may not be friendly for Japan-based participants, I'd suggest we have another call to discuss your proposal based on your preference.


-Anssi (Device and Sensors WG Chair)

[1] https://w3c.github.io/charter-drafts/web-based-signage-2016.html#normative

[2] https://www.w3.org/2016/03/device-sensors-wg-charter.html

[3] https://w3c.github.io/battery/

[4] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html

[5] https://www.w3.org/TR/fingerprinting-guidance/

[6] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#use-cases

[7] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#term-web-runtime

> On 1 Oct 2017, at 16.01, Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp> wrote:
> Dear Device and Sensors WG members,
> (Cc: Web-based Signage BG members)
> I'm one of co-chairs of Web-based Signage BG [1].
> I have a proposal to add new items (APIs) to your charter.
> The proposal is following.
> Please let me know your questions or comments on this topic!
> ---
> Web-based Signage BG has discussed about Web-based Signage Player (JavaScript) not only for playing contents on the signage terminal but also for controlling the signage terminal device [2-4].
> Web-based Signage BG has considered new APIs for getting the terminal device information and controlling the terminal device via a user agent,
> and created a draft charter [5] for a new WG to study these APIs.
> However, the proposed APIs seem to have a high affinity with Device and Sensors WG, so Web-based signage BG decided to propose to ask Device and Sensors WG to add the proposed API to the deliverable of Device and Sensors WG [6].
> Since the initial idea of one of the proposed API (Signage Operational Information) [6] includes the security description, so please refer this, too.
> I want to ask you to consider this proposal and to discuss how two groups collaborate on this issue with us.
> Thank you in advance for your cooperation!
> [1] https://www.w3.org/community/websignage/

> [2] https://www.w3.org/2016/websigns/core/

> [3] https://www.w3.org/2016/websigns/basic-media/

> [4] https://www.w3.org/2016/websigns/storage/

> [5] http://w3c.github.io/charter-drafts/web-based-signage-2016.html

> [6] https://www.w3.org/2017/06/22-websignage-minutes.html

> [7] http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html

> Best regards,
> Kiyoshi
> ---
> Kiyoshi Tanaka, Ph.D.
> NTT Service Evolution Laboratories
>  mailto: tanaka.kiyoshi@lab.ntt.co.jp

Received on Tuesday, 3 October 2017 12:53:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:40 UTC