Meeting minutes
Welcome, agenda bashing
Anssi introduces Jake who will share multicast thoughts. Other participants are more usual WG participants. Quick round table.
anssik: Overview of today's agenda:
… discuss changes to:
… 1) Open Screen Protocol since FPWD
… 2) Presentation API (at CR)
… 3) Remote Playback API (at CR)
… 4) discuss WG Charter 2022 plan, review CG incabations for WG readiness, discuss OSP changes subject to the PAG progress
… 5) Multicast CG intro by Jake Holland / Akamai & discussion
… questions, proposals?
Open Screen Protocol
Proposed modifications to sections 9.2, 9.3, and 12.1.1 #286
anssik: this PR proposes "changes related to IPR policy considerations"
Proposed modifications to sections 9.2, 9.3, and 12.1.1 #286
anssik: relatedly, Patent Advisory Group (PAG) launched Aug 2021 study issues and propose solutions related to patents and claims disclosed and excluded by Apple, Inc.
mfoltzgoogle: I looked at the PR and don't object to the PR
… I don't think it changes the meaning of implementability of the protocol
… neutral from the technical point of view
… not discussing IPR issues on this forum, on technical merit no objections
… there are two parts, one addresses how we describe audio formats, we have a field in the protocol
… for sample rate, it does not affect the meaning, another part is in non-normative section on networks, again, removes some clarifying text, but I don't think it affects the meaning of the spec
anssik: We asked the PAG to take a position on this PR. The PAG says that it's ok to discuss this PR on its technical merits.
PROPOSED RESOLUTION: WG is fine with changes proposed in PR #286 and ok to merge the PR
Resolution: Working Group is fine with changes proposed in PR #286 and ok to merge the PR
Allow additional discovery mechanisms. #283
Allow additional discovery mechanisms. #283
anssik: a few comments from the David Schinazi, any concern in updating PR per David's comments?
mfoltzgoogle: Two parts to mDNS.
… Multicast DNS, and DNS-SD to advertise services.
… You can do DNS-SD without doing mDNS.
… David wanted to clarify that these mechanisms are different.
… The PR looks good to me, ready to merge. It's been around since April, hopefully people have had time to review by now.
anssik: Does it impact existing implementations?
mfoltzgoogle: Supporting anything else other than mDNS would be a feature in our ongoing implementation, but that's doable.
PROPOSED RESOLUTION: PR #283 on additional discovery mechanisms is ready to merge
Resolution: PR #283 on additional discovery mechanisms is ready to merge
Reference Media Capabilities ColorGamut for color space capability #225
Reference Media Capabilities ColorGamut for color space capability #225
anssik: discussed at our previous meeting
Second Screen WG/CG virtual meeting Q1 2021
mfoltzgoogle: The context here is that if we want one agent to be able to send HDR content to a receiver, we need to know that the receiver is capable of rendering the HDR content.
… We were waiting for the Media WG to clarify how they would expose that in the Media Capabilities API so that we could align.
… They settled on a set of enums on media decoding capabilities.
… This should be ok to land.
… I haven't been plugged in Media WG discussions since last time. As long as the values align, that's good.
anssik: Who would be the best contact point for the capabilities spec?
mfoltzgoogle: For Google, Chris Cunningham edits the spec but others are involved.
… I'm happy to check with Chris Cunningham. If others have other people in mind, feel free to tag them on the pull request.
Action: mfoltzgoogle to reach out to Chris Cunningham re. media capabilities for PR #225
Security tracker issues
OSP issues with "security-tracker" label
<mfoltzgoogle> Link to slideshttps://
mfoltzgoogle: Some feedback from security folks on certificates. It turns out that there are lots of rules to follow for certificates.
… Most of the feedback is relatively straightforward.
… One area may require a deeper dive.
… Beyond certificate use, the second topic is the PAKE that we propose. I have a few updates but not a fully fledged proposal yet.
… Starting with certificates feedback.
… Some context: Open Screen Protocol includes authentication sub-protocol to prevent person-in-the-middle attacks.
… Alice and Bob generate an agent certificate and they exchange that certificate to create a TLS connexion. It's not crucial who is the server/client here.
… Since we don't have certificates that are signed by a mutually trusted authority, or we don't assume that
… we use a PAKE to validate where one device shows a code, user enters the code and that along with info about the certificates is used to validate things.
… When we designed the certificate, we made a number of design choices.
… It wasn't clear exactly what information to put in these certificates.
… We did a best effort to fill out the blanks.
… Many rules for using certificates. It's probably a good idea to follow as many as we can so that these certificates get accepted by TLS agents, etc.
… Some suggestions and incompatibilities that were suggested
TLS SNI requirement is incompatible with TLS SNI definition #275
mfoltzgoogle: are not blocker per se, but good to adopt
… First one is #275, around the TLS SNI definition. There are restrictions on the SNI where underscores cannot be used. So the full name we advertise for discovery cannot be used as-is
… Three options: remove underscores, alternative SNI syntax or remove SNI.
… My current thinking is that this is unlikely to be used in most scenarios.
… I'm find removing SNI. I would probably need to circle back and make sure that's ok, but I think that would simplify things
jake: I'm not sure that's compatible with TLS. My understanding is that it what's used for the hostees.
… Maybe I'm wrong here.
anssik: Maybe Jake should be tagged in this issue. Do you know someone particular who could be helpful for this issue?
jake: I would reach out to one of the OpenSSL maintainers, [missed name]
… Why don't you tag me and I will forward that to Rich.
mfoltzgoogle: Moving on to issue #277
… Ryan suggested removing support for P-521. That is the most complex of the elliptic curves.
… I wonder whether anyone has benchmarked implementations on low-end devices to have some data to back this up.
… Having better cryptography means that devices are more secure for a longer period of time.
… I wanted to at least get additional data.
… If folks have it, feel free to tag it in the issue otherwise I'll look into possible measures.
mfoltzgoogle: Issue #278. Some feedback on how we set the commonName.
Consider removing support for P-521 #277
Do not use Distinguished Name to convey protocol details #278
<jake> btw, I'm @GrumpyOldTroll on github.
mfoltzgoogle: Ryan indicated that having human-readable text in the distinguished name may cause interoperability issues.
<jake> if you're trying to tag me.
mfoltzgoogle: It's not critical for the Open Screen Protocol, more for debugging.
… I believe that the two proposals made should address the concerns of the issue
The keyUsage name is digitalSignature, not signing #279
mfoltzgoogle: Issue #279. Specific token from the RFC that we didn't use. Straightforward.
Clarify the supported signature algorithms for certificates #280
mfoltzgoogle: Issue #280. Again, more syntax. We list supported signature algorithms. There are specific tokens to embed. It would be more precise to refer to these specific tokens.
… The issue cites the RFC. Relatively straightforward as well.
mfoltzgoogle: Issue #282. This is the issue that probably requires a bit more discussion.
mfoltzgoogle: We probably won't have time to completely sort it out. We currently don't define any lifetime for the certificates.
… You should be able to rotate your certificates regularly as a security best practices or to switch to more secure ones.
… In the WebTransport protocol, they choose a lifetime of two weeks.
… Two things we need to figure out: 1) How do we identify certificates, which info to include in the hash. That is certainly doable, there is an algorithm to do this.
… It seems to provide more flexibility to the device's certificate management process.
… The second thing is about rotating entire certificates without having to redo the SPAKE-2 exchange.
… That requires more thoughts.
… I wonder how WebTransport plans on handling this. It also makes the implementation quite a bit more complicated.
<jake> I mentioned "how plex does it", for which I'll reference this: https://
mfoltzgoogle: I don't want to propose anything yet, but potentially an extension to the protocol later.
… Mostly, I solicit feedback on ideas and options for that second part.
… I'll probably come up with a PR for first part.
jake: I shared a link to a post from Plex on how they handle this. I would suggest looking into it.
mfoltzgoogle: Next, I took a quick look through recent discussions on PAKE at IETF.
… A little bit of context: we chose SPAKE-2 based on usage, wide availability. However the IETF wanted to recommend a specific PAKE. That effort concluded recently. They recommend CPACE. It has some interesting properties.
… The authors published a new draft a couple of months ago.
… They have different implementation properties: one for hardware-constrained devices, targeting TPM I think.
… The other is more suitable for general CPUs.
… CPACE has a session identifier that seems to be important. Lots of discussion around it.
… If you look around, a lot of people are implementing this on GitHub, but I don't believe this has been adopted per se.
… We should look at a more detailed comparison. Probably a topic for another meeting.
… Still a bit of a work in progress.
… Implementations are still experimental at this stage.
anssik: OK. Thanks. We are planning to request horizontal reviews of the spec. We will refer to these issues.
Wide review
mfoltzgoogle: Regarding wide review, it probably makes sense to land the outstanding PR first.
mfoltzgoogle: For some of the newer security issues, we can highlight them in the spec as needing updates, or we can try to create an updated spec that incorporates the feedback.
anssik: I would integrate low-hanging fruits and reference other issues.
… Good practice is to request horizontal review as early as possible following publication as First Public Working Draft.
Seek horizontal reviews on the spec #284
mfoltzgoogle: Anyone in the group can help fill out the questionnaires to prepare the requests for horizontal reviews.
Presentation API
Possibility for UA to close the connection when it is no longer operational #485
Possibility for UA to close the connection when it is no longer operational #485
Add a note about keep-alive mechanism at the app level #498
anssik: issue #485 has a PR #498 from Francois
… anything else to discuss for Presentation API?
Remote Playback API
anssik: this spec is almost ready to advance to a Proposed Recommendation
Transitioning to Proposed Recommendation, remaining work
anssik: the only remaining Proposed Rec blocker is Remote Playback API test automation to satisfy "must show adequate implementation experience except where an exception is approved by the Director"
Transitioning to Proposed Recommendation
anssik: we have a tracking issue for test automation, it is substantial amount of work and Louay took at TPAC 2020 an action to figure out if we want to move forward with test automation or manual testing, to unblock PR publication
Remote Playback API test automation #92
anssik: Louay has done investigation on this
Louay: In the CTA WAVE Project, we came up with some sort of manual process, starting with a Mezzanine file. You run the tests in the browser, and something happens in the remote device.
… For these reasons, one approach could be that you point a camera at the remote playback.
… You need some kind of observation capabilities.
… We're planning to release this in the CTA WAVE Project.
… And this will be fed back into Web Platform Tests.
… This is semi-manual. Good thing is that it doesn't require extensions e.g. to WebDriver.
… and you can test a real implementation instead of using a fake remote device.
… I didn't manage to get students to work on testing topics.
… I list 4 different projects in the GitHub issue.
… There's some automation on the observation but you still need some recording mechanism.
… I think the slides are also being discussed in the Media & Entertainment IG
anssik: Thank you Louay for helping with this activity.
… Any thoughts on the Remote Playback API test automation plan?
mfoltzgoogle: I think this looks promising. I'd like to learn more about it. It may be possible to automate this further, but I need to find out more details about the different modules.
Louay: Maybe we don't need all of them. Here, it was more for device capabilities tests.
… If we have QR codes, we could automate things further to make sure that videos are actually playing back on the remote device.
mfoltzgoogle: I think I can provide some feedback based on our experience testing similar features in Chrome.
… I'd be interested to learn whether this could work with Apple's implementation.
Louay: The good thing about this approach is that it is agnostic of the browser. You need to point out the recording device to the remote device.
tidoust: where do we need to stop for the tests? w-p-t tests do not really test rendering of frames but current time advancing, for example
Louay: Yes, we'll have to figure out what updates these tools may need.
WG Charter 2022-2024
[PROPOSED] Second Screen Working Group Charter 2022-2024
anssik: we're rechartering for the next 2-year period
… Francois has done an editorial update to the boilerplate
… now is a good time to review CG incabations for WG readiness
… as for the schedule, we're probably quite late for other than extension at this point, given 6 week review time and holiday period
… it seems reasonable to seek for a 3-4 months extension, that's also allow time for PAG to possible announce its recommendation?
tidoust: important is for the WG to agree what to do next, what incubations are ready to advance
… extension is doable, we do not know how long PAG takes to conclude, hard to evaluate
… would not personally base chartering on hypothetical PAG recommendation
… but can ask for a short extension while we plan for a new charter in a more pieceful way
mfoltzgoogle: when WG needs to have its draft for review outside WG
tidoust: in theory, we're already late, 6 days from now we should take the charter draft to W3M
… in practice, we can be a bit late, if we slip by a few weeks
mfoltzgoogle: getting an idea on the scope of change, would give me an idea if we should move on a faster timeline
anssik: Main point is that we should review incubations during the CG meeting tomorrow.
mfoltzgoogle: if we are adding significant new deliverables, that usually takes extra time to get them defined clearly and implementers to agree
mfoltzgoogle: if it is back and forth on new deliverables, then extension seems good approach
Multicast Community Group introduction
<jake> https://
jake: I'll paste a link to the video I prepared to explain the motivation. For now, just assume that it is a useful topic :)
… I'll briefly cover why I think it's important, what our mission is, and jump ahead to privacy issues that I'd like to discuss with this group
<jake> https://
jake: Our mission is to get multicast IP working for Web traffic. Been working on that at IETF for several years. Now I'd like this to be available in Web browsers.
… [skipping motivation, teaser: upcoming Multicast CG meeting on Wednesday, same time]
… On to privacy issues. Got feedback from Ryan Sleevi on Chromium dev channel.
… Basic problem to get this turned on in Web contexts: it's a different type of traffic.
… Multicast is unidirectional transport at the basic. Different kind of content delivery system and this has some privacy implications.
… For the purposes of a web integration, some of the privacy issues may be similiar to the ones you're facing.
… One issue: when someone joins a multicast group, this leaks some information to the upstream devices so that the multicast content can flow but that also leaks some information to other devices on the same network.
… We're not quite sure that it exposes new information.
… The other question is: what can we do about it?
… There are some similar things that are already exposed. e.g. discovery requests with mDNS.
… I'm not sure that this is a real problem. I'm hoping to get good insights on the issues.
… Some questions: Do you have a privacy threat model on the LAN?
… E.g. Are there risk profiles written up?
… Have you considered whether incognito mode would help any of this?
… Users have this idea that you are covering your tracks a bit better in incognito mode, smaller footprint of things being exposed.
… It prevents certain kinds of things from being discovered.
… Does it make to disable certain features? Have you measured how well it works?
anssik: Floor is now open for discussion.
jake: There's been a quite recent exchange in multicast about a new permissions that apps need in the app store in order to use multicast. Added a few months ago.
… It might help with some of these issues.
mfoltzgoogle: At the Web API layer, for example Remote Playback, Presentation API, how the user agents or devices discover each other and exchange information, I don't think that the specs mandate that any information get exchanged between devices that the user has not explicitly approved.
… Before that consent is made, it's up to the protocols.
… For Open Screen Protocol, we try to make sure that agents exist in one of two modes: unauthenticated and authenticated.
… We try to make sure that personal info is only exchanged in authenticated mode.
… The spec is pretty clear that you should not trust any discovered info before authentication.
… There's a division between agent metadata and user data.
… We don't expose specific parameters before we have some confidentiality.
… You still need to exchange some information to bootstrap the connection
jake: Feedback I got is that maybe we don't need this.
… Do we know if anything looks for it? Have we seen abuses of this kind? Because there are some discovery packets that expose what web pages are doing on the LAN.
… The default is that you should be worried about privacy fingerprinting increasing activities, but where to draw the line?
… How does this get exploited if there is a privacy problem here?
mfoltzgoogle: Two cases. One is complete access to your local network. Regardless of what authentication you may add, that type of software is going to learn about whatever runs on your LAN. If that software is able to report back to a server, I don't think there's much in current protocols that can stop it.
… If your discovery mechanism is also publishing any user information, URLs or content, I think that's slightly worse, because normally that wouldn't be published through mDNS.
… In terms of web exposing kinf of local multicast. Multicast allows others to listen to what others are doing and could use that for fingerprinting. Also, ability to scan for software versions and security exploits.
… If you can leverage this directly or indirectly, that's a problem.
jake: I should clarify that the intent is receive-only. You try to join a multicast group. It might be reasonable to restrict that to SSM streams.
… What we're looking is integrating into WebTransport and then other mechanisms.
… With that kind of approach, none of these can even do the kind of scanning that we're talking about.
anssik: Is there a repo already for this work?
jake: Yes. I haven't been very good at making issues, but I think I should start.
<jake> https://
anssik: Motivation is very clear. This is also more energy-efficient. Fewer CO2 emissions.
<jake> https://
<jake> that has meeting coordinates
anssik: Multicast Community Group TPAC meeting at 27 Oct 15:00 UTC to 16:00 UTC (8am PDT, 11am EDT)
anssik: Thanks everyone for joining and discussions. In not so many hours, we have the Second Screen CG meeting. See you soon!