SM: These folks asked if they could join our call either 28th or 11th of Sept?

PL: Either date is OK with me.

SM: The esteemed chair can decide!

DS: I'm chair of the group but didn't write the spec.

DS: 2 problems they are trying to solve in this spec - (1) you want to present a lecutre and [allow the user to manipulate the stream] as it is being watched. richer multimedia experience. also ad insertion. that's sync of web & media technologies (2) they also want to package that into a single [delivery]. that is where ISOBMFF comes in. if you are retreiving a package from a web server then local names can be treated as relative resources. there is a packaging desire and a sync desire. i think there is too much in the specification. they package many kinds of resources together - html, css, js, images, timed resources, overlays... This has been going through MPEG for a while. I think we need to get [various experts] and tech suppliers together in a workshop.

Yves: when the mpeg container is transfered through eme does that mean that eme black box can run js trackers and privacy invasive things without being noticed? is that desirable?

DS: The ability of the web page connected to the same origin - there is no attempt to package things from other origins or resources.

Yves: if it's encrypted through eme then the browser may not have complete control of what is going on.

Dan: concerns from TAG in context of this, and of HBBTV, have to do with security, e.g., knowing what the origin is, and that the security model of the web is so tightly bound to origin. Are these packages being retrieved over the internet, are they being broadcast, etc.?

DS: In order not to run afoul of multiple origin problems... where the spec says URL, it should have said local name, which you can compose with the package's URL. You got the package from somewhere, that's your base for any operation.

Dan: what if the package comes down over a broadcast channel?

DS: Like FLUTE, MBMS or ...?

Dan: or ...

DS: FLUTE names resources by URLs -- so you get a URL for that.

Dan: We also spent a lot of time on securing the web -- securing the web is about tying the security model to the HTTPS delivery as well.

DS: The only aspect I've looked at is the HTTP delivery. I don't think MBMS and FLUTE have enough security inspection because nobody's thought of deplopying them. You could construct an MBMS multicast that claims to have URL names claiming to come from example.com, and then presumably example.com would be same origin. That's not a problem with this packaging, it's a problem with FLUTE MBMS protocol.

Dan: Sounds like something to discuss at this theoretical workshop. Seems like packaging itself should be something more like signed exchanges.

DS: This problem would come up with simple HTML pages over FLUTE MBMS.

Dan: Then it's inherently unsound.

DS: We're talking about just synchronization of web resources and packaging.

Dan: We've been looking at signed exchanges -- if we say web packaging must have those kinds of properties, that seems to me to be something that could hlep -- we're removing the issue from the delivery.

Tess: From 10000 feet, feels like there have been so many attempts at packaging web content. Curently there are several simultaneous mutually incompatible attepts. Seems like publishing people, AMP people, MPEG people -- not talking to each other, may have incompatible requirements, will something work for all or most of them.

Dan: +1

DS: may also be an opportunity -- publishing people talk about books, audio books, narrated books. Video people approaching same user space from opposite ends. Image file format packaging untimed resources together -- new adif image format, in Mac OS, Windows, android builds. A lot of the technology already there. I have no particular axe to grind here. Getting the interested parties together to work out uses and what to solve.

Peter: curious where this intersects with ttml

DS: i've wanted to use a text track as a metadata track. ... one waay to tie slides to video time ranges...

Yves: in webrtc they have separated data, audio and vidoe channels there may be something here.

DS: w3c is obvious place to catalyze such a worksho.

Tess: there could be interest this year. typically w3c workshops are looking longer term and are about breaking new ground.

Peter: anything else TAG can do?

Tess: we had a finding on packaging?

Dan: Could we get this MPEG group looking at the security & privacy self check?

Peter: thanks david!

Dan: thanks!

--

• TAG review request: Verifiable Credentials Data Model 1.0 - @hadleybeeman

Manu: the v.c. working group chartered to work on a data model - we were not cleared to work on a protocol or crypto - spec is going into candidate rec. Broad consensus. We've had multiple reviews from i18n. There is a group called "rebooting the web of trust" - meets every 6 months - through that venue we've had a lot of engagements out of the traditional community... so quite a bit of review.

We are looking for a sanity check from the TAG from an architectural perspective and on the data model itself. Multiple organisations implementing the spec. Being used in product now. Most of the focus after in CR - and if the work gets to rec is going to be standardizing moving the credentials around. Protocols...

Dan: what is the time frame?

DanB: asap

Lukasz: fairly large privact & security section - i like it. might even be too verbose.

DanB: i wanted to comment on lengh and verbosity - PING wanted our best thinking of how it cold be used by others. so we definitely look at your suggestions for compressing the text but PING has requested detail.

Dan: I will ask Hadley to feed back to you asap

Dan: I'll (hopefully) discuss with next week during the AC meeting.

• [CSS Properties and Values API Level 1](https://github.com/w3ctag/design- reviews/issues/318) - @hober, @alice, @dbaron
• IndexedDB Transaction Explicit Commit API - @cynthia, @kenchris
• hrefTranslate attribute - @torgo, @hadleybeeman
• The web platform needs a service discovery mechanism - @cynthia, @hadleybeeman, @plinss
• Media Capabilities - @cynthia, @travisleithead, @plinss
• ads.txt - @slightlyoff, @torgo, @ylafon
• Trusted Types - @hober, @cynthia, @alice, @slightlyoff, @hadleybeeman, @travisleithead, @plinss
• Task Scheduling - @dbaron
• Clear Site Data - @hober

---

Sangwhan: I had a chat with Cyril (?) abot this at TPAC ... seemed unconvinced about the issues we raised. We can't tell them it's a bad idea, if they pursue a bad idea in some other standardisation body we can't really do antyhing about it.

... Suggest we leave a last comment saying we had a short chat about this... don't know why a bunch of new types, seems like it's trying to reinvent a file system... maybe this should be consiolidated into a package inside a video.

... Could end up creating a loop since you can put a video inside the data inside the video...

... I want to close this, I don't think we're going to get any traction here. Seems like a really bad idea