[wg/secondscreen] Second Screen Working Group rechartering #444
Comments
plehegar
added
the
Advance Notice Sent
|
There has been several privacy issues raised against specifications developed by this Working Group. What's the status of those issues? cc @pes10k |
|
cc @louaybassbouss @anssiko (adding the WG co-chairs) |
Issues w3cping/tracking-issues#420 and w3cping/tracking-issues#330 related to the Open Screen Protocol have been addressed. The rest of the issues are for the Window Management API whose first version shipped in Chrome 100. Given this, changes to the specification require close coordination with the implementation and gathering input from early adopters on how these proposed changes would affect them. While the WG is gathering that input, the WG has improved the privacy considerations section to note concerns raised in the PING review comments and has attempted to explain associated privacy risks in a transparent manner, also note the same information can be inferred using legacy window.screen API that ships widely. To put a more positive spin on this, the WG has also observed gating legacy screen and window information on the specified permission may be feasible. We believe that ultimately we end up in a better place with the privacy story but that requires some extra time, one of the reasons for this recharter. In retrospect, we should have requested PING review even earlier. I take that as a lesson learned. I'm happy to conduct a more in-depth investigation on any of the topics as appropriate. |
|
Thank you @anssiko PING remains concerned about the Window Management issues and expect those issues to be resolved before moving the specification to Candidate Recommendation. We also noticed that Remote Playback and Presentation APIs were last reviewed for privacy back in 2016/2017. It may be that another review of those specifications should be done in the upcoming future. We're ok with the charter proceeding as-is. |
|
no comment or request from i18n |
|
no comments or requests from APA. |
|
The deliverables of the Second Screen Working Group are very important from a security point of view because they include protocols and APIs that allow access to third party systems. Therefore I would like to propose to add a sentence in the paragraph "4. Success Criteria":
The structure of this section is indicated by the Security and Privacy Questionnaire and in the referenced RFC3552 - Guidelines for Writing RFC Text on Security Considerations. In this specific case, this approach has already been taken by the WG with regard to the Open Screen Protocol, so the current feedback is positive. I remain available for further analysis. |
Could the additional sentence be scoped to the protocols and APIs that do allow access to third party systems? Namely, the Presentation API, the Remote Playback API and the Open Screen Protocol? The Window Management specification is restricted to directly connected displays, no third party access there. |
I consider it in general since threat actors are normally very interested in a target's screen, and the issue of having third-party device information is an additional element of risk. |
I guess I'm not clear what "third-party" means. I associated it in my mind with "systems on the network". The Window Management API does not consider screens that are not part of the system where the browser runs, only "first-party" screens. |
Adds a sentence to note an additional requirement to include a threat model with threats, attacks, mitigations and residual risks, as requested by horizontal review: w3c/strategy#444 (comment)
|
@simoneonofri See related PR on draft charter, which is scoped to specifications that enable access to third party systems. I plan to proceed with next chartering stage with that change. If that's not good enough, let me know. |
|
@tidoust, thank you. I would structure the security considerations like that. The point I was trying to make was that access to third-party systems is an added plus, not that that was the only reason. Right now, the content is already there, particularly for the Protocol. Then, there are several cross-references (which are good for not deduplicating the text), which is already a good job. Structuring the section this way (briefly, it's what RFC 3552 referenced by the Questionnaire requires) allows for quick identification of scenarios/risks/threats considered or not. |
* Add security considerations requirement Adds a sentence to note an additional requirement to include a threat model with threats, attacks, mitigations and residual risks, for specs that enable access to third-party systems, as requested by horizontal review: w3c/strategy#444 (comment)
|
The group's public mailing list was removed from Section 6 Participation:
but in Section 7 Communication the charter says the group will still be using its mailing list to collect feedback:
I hope the charter can be consistent in the usage of its mailing list. |
|
It might be good to be a little more clear on the OSP potential split that new control protocols are not in scope of this charter. It is currently implied, and the reference to Matter can makes things a bit more fuzzy. |
|
@siusin, I'm not sure I understand the inconsistency. Section 7 Communication does not say that the group will be using its mailing list to "collect feedback", but rather for "calls for consensus", which are the sort of group-wide calls organized to decide on rechartering, specific resolutions, publication requests, etc. Using the mailing-list seems a good thing to me, because it's easy to miss a call for consensus that runs on GitHub. For feedback, the section explicitly notes that technical discussion will be on GitHub. |
|
I agree with @tidoust that there is no inconsistency here - GH for discussion, list for CfC |
|
@tidoust Thank you for the explanation regarding this issue. Now I think the current text is acceptable and doesn't require any changes. |
Via w3c/strategy#444 (comment) Goal is to clarify that the control protocol targets messages requiresd to implement the APIs, and not e.g., all of Matter. Note the Out of scope section is already clear that protocols "not required to implement the APIs developed by this Working Group" are out of scope.
|
@ylafon, re.:
The "control protocol" is the set of commands that can be exchanged between the controller and the receiver to implement the Presentation API and the Remote Playback API. I would argue that it is "new" ;) The Out of scope section is more explicit that "Any protocol not required to implement the APIs developed by this Working Group", which I suspect is what you'd like to see more clearly expressed in the text that describes the envisioned split. I proposed w3c/secondscreen-charter#44 to clarify what the control protocol means, leaving the "no new protocol" bit to the out of scope section. |
Via w3c/strategy#444 (comment) Goal is to clarify that the control protocol targets messages requiresd to implement the APIs, and not e.g., all of Matter. Note the Out of scope section is already clear that protocols "not required to implement the APIs developed by this Working Group" are out of scope.
|
W3C Technical Lead Team (TiLT) approval requested and granted. Next up: AC review. |
plehegar
moved this from Chartering
to Strategy Work Concluded
in Strategy Team's Incubation Pipeline (Funnel)
New charter proposal, reviewers please take note.
Charter Review
See proposed charter for 2024-2026
What kind of charter is this?
Where would charter proponents like to see issues raised?
Anything else we should think about as we review?
The Second Screen WG is still discussing possible updates to the charter. This may lead to additional revisions. Also see:
I will request horizontal review when discussions in the group are over.
The text was updated successfully, but these errors were encountered: