Re: Proposal from Web-based Signage BG

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.

Thanks,

-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