Re: [Hls-interest] Accepting Playlist Variables via Query Parameter

["Cava, Zachary" <[e-mail]>]

Thanks for the update Roger!
________________________________
From: Hls-interest <[e-mail]> on behalf of Roger Pantos <rpantos=[e-mail]>
Sent: Thursday, February 16, 2023 14:53
To: Cava, Zachary <zachary.cava=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Hls-interest] Accepting Playlist Variables via Query Parameter

Updating this thread with some news: we have incorporated support for this feature into iOS 16.4 (and parallel releases for tvOS and macOS). A formal update to https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis is in the works.

Here’s an example of the syntax:

Given a URL: https://example.com/playlist.m3u8?token=abc123&service=“Dingbats"

And a playlist:

#EXTM3U
#EXT-X-VERSION:8
#EXT-X-TARGETDURATION:6
#EXT-X-DEFINE:QUERYPARAM=“token”
#EXT-X-DEFINE:QUERYPARAM=“service”
#EXTINF 6,
Segment0.mp4?cdn-token={$token}&origin={$service}

The resolved segment URL will be https://example.com/Segment0.mp4?cdn-token=abc123&origin=“Dingbats"

You can try it out today with the iOS 16.4 seed that we made available earlier this week.


Roger.

On Aug 26, 2022, at 11:35 AM, Cava, Zachary <zachary.cava=[e-mail]> wrote:

After I wrote that I heard from some other folks who pointed out that quoted strings aren't really significant in URL query parameters and feel somewhat artificial. Given that, I'm willing to reverse the rule and say instead that payload of the query parameter must not have quotes. (I do think that it should be a hard rule, one way or the other.)
Agree with making it a hard rule, but I'd strongly advocate for query parameters not having quotes.

Agreed. So let's say both that the client will not search for a query parameter missing from the Media Playlist URL in the MVP URL, and also that QUERYPARAM variables in the MVP are eligible for IMPORT in the Media Playlist.
Sounds great.

Regarding this part:

| 2) A playlist containing an EXT-X-DEFINE with a QUERYPARAM coming from a URL without such a query parameter will fail to pars

I got a question about whether we should make some provision for a default value for a variable that fails to import. I haven't heard of a compelling case for that, and generally I prefer to make subtle errors visible. But I wanted to put the question out there in case anyone wanted to argue for it.
I omitted my initial response, but I agree with keeping this an error to prevent subtle integration misses similar to the reasoning I had on 2b.

Zack
________________________________
From: Roger Pantos <rpantos=[e-mail]>
Sent: Friday, August 26, 2022 09:47
To: Cava, Zachary <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Hls-interest] Accepting Playlist Variables via Query Parameter



On Aug 23, 2022, at 3:05 PM, Cava, Zachary <zachary.cava=[e-mail]<mailto:zachary.cava=[e-mail]>> wrote:

Hi Roger,

Great to hear the update from you, sorry it looks like my previous response got stuck in my drafts.

Net net, our previous investigations around security found there was no greater maliciousness permitted by allowing parameters via the query parameters than the body of the response. This was primarily due to our use of HTTPs only traffic though where any point or attack that gained the ability to manipulate the query parameters also gained the ability to modify the body. Similarly I concur with your comment on redirects.

For the constraints a few questions:

1b) The payload of the query parameter in the URL must be a quoted string
By this do you mean the query parameter must look something like this: http://example.com/stream/mv.m3u8?myparam="value<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fstream%2Fmv.m3u8%3Fmyparam%3D%2522value&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f5rNiQhbItn2NLZY4j4XHc%2BekojazDzPbr6ZSKwq9Jw%3D&reserved=0>"
Want to make sure I'm reading that right

After I wrote that I heard from some other folks who pointed out that quoted strings aren't really significant in URL query parameters and feel somewhat artificial. Given that, I'm willing to reverse the rule and say instead that payload of the query parameter must not have quotes. (I do think that it should be a hard rule, one way or the other.)


2b) (up for discussion)  if the query param is not present in a Media Playlist URL, we could look for it in its parent MVP URL.
I can go back and for on this one, while it might seem like a nice convenience, I can see implicit passing being more harmful than helpful. I think I would lean on the path of making things explicit to ensure all parties involved in the stream playout are participating and expecting the passing.

4) A Media Playlist can IMPORT a variable that was defined by a QUERYPARAM in the Multivariant Playlist.
Agree this would be a great case and hopefully help some backwards compatibility aspects for anyone with existing media playlists. I'd almost go as far as saying this should be the explicit import signal in place of 2b.

Agreed. So let's say both that the client will not search for a query parameter missing from the Media Playlist URL in the MVP URL, and also that QUERYPARAM variables in the MVP are eligible for IMPORT in the Media Playlist.

Regarding this part:

2) A playlist containing an EXT-X-DEFINE with a QUERYPARAM coming from a URL without such a query parameter will fail to pars

I got a question about whether we should make some provision for a default value for a variable that fails to import. I haven't heard of a compelling case for that, and generally I prefer to make subtle errors visible. But I wanted to put the question out there in case anyone wanted to argue for it.


Roger.


Thanks,
Zack

________________________________

From: Roger Pantos <rpantos=[e-mail]<mailto:rpantos=[e-mail]>>
Sent: Monday, August 22, 2022 17:40
To: Pyrmont Brewery <[e-mail]<mailto:[e-mail]>>
Cc: Cava, Zachary <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Jer Noble <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Hls-interest] Accepting Playlist Variables via Query Parameter

I'm not sure if allowing query parameters from redirects opens up a much larger hole for ad blockers. If an ad blocker has the means to forge a 30x response from the content server, it seems like it could equally forge a 40x or similar for an ad asset request, which would cause that asset to be skipped.


Roger.

On Aug 22, 2022, at 4:35 PM, Pyrmont Brewery <[e-mail]<mailto:[e-mail]>> wrote:

With 5 (obtains variables from redirects) just wondering if domain needs to be restricted (CORS like?) maybe not, but where I’m thinking here is if ad blockers, they can only proxy safari connections? (if not then they could modify the QUERYPARM and so any variables held en route)

Might be over thinking it
Kev


On 23 Aug 2022, at 8:11 am, Roger Pantos <rpantos=[e-mail]<mailto:rpantos=[e-mail]>> wrote:

Okay, we looked this over from a security perspective and we didn’t see anything that requires trust that isn’t already inherently being granted. So that’s fine.

As I wrote earlier, we can see how this would be a useful addition, particularly where different parties are involved in producing vs. serving the playlists. There are some details that need to be nailed down, though. We would propose the following additional constraints:

1) This adds a new attribute for EXT-X-DEFINE called QUERYPARAM. The value is a quoted string just like the existing NAME attribute. The QUERYPARAM value is the Variable Name; it must match a query parameter name in the URL. No other EXT-X-DEFINE can use the same Variable Name. URLs allow characters in query parameters that are not legal in HLS variables. Such characters must not be used in Variable Names.

1b) The payload of the query parameter in the URL must be a quoted string

2) A playlist containing an EXT-X-DEFINE with a QUERYPARAM coming from a URL without such a query parameter will fail to parse (just as the IMPORT case would). Except possibly for the case of:

2b) (up for discussion)  if the query param is not present in a Media Playlist URL, we could look for it in its parent MVP URL.

3) The value of the query parameter will NOT be percent-decoded before performing variable substitution in the playlist. (I’ve gone back and forth on this one. On one hand, percent-decoding would enable variable replacement of certain special characters. On the other, the target of variable replacement is most often a URL itself, where values should be percent-encoded. And, I’d like to avoid the complexity of requiring the client to know if variable replacement is being done inside a URL or not.)

4) A Media Playlist can IMPORT a variable that was defined by a QUERYPARAM in the Multivariant Playlist.

5) If the URL is redirected, the client will look for the query parameter in the 30x response URL

6) Pathway cloning manifests allow PARAMS. Replacement of pathway-defined query parameters would apply AFTER playlist variable substitution.


Roger.

On Jul 26, 2022, at 2:46 PM, Roger Pantos <rpantos=[e-mail]<mailto:rpantos=[e-mail]>> wrote:

Hi Zach. We've been discussing this internally since last week. I can clearly see how we could map query parameters into EXT-X-DEFINE imports. One concern I have is any new attack vectors it might open up.

Have you guys done any threat analysis on this sort of approach, or ran it past any security experts (at W3C or elsewhere)?

Is there an existing precedent for this kind of processing? (It wouldn't necessarily have to be in streaming.)


thanks,

Roger.

On Jul 21, 2022, at 3:49 PM, Cava, Zachary <zachary.cava=[e-mail]<mailto:zachary.cava=[e-mail]>> wrote:

Hi Everyone,

In continued discussions around interoperability of DASH and HLS, a question has been raised about bringing great scale interoperability to Playlist variables.

By way of background, a common industry use case is to provide token authentication to manifest / playlists and all subsequent resources. A common pattern to enable this is for the primary token to be attached to the manifest / playlist URI and to use real-time generation / manipulation to carry the token through to other URIs present in the document (and subsequent documents). This is typically done in place of headers / cookies as they are not available across all serving scenarios and environments. While this approach functionally works, a more ideal state would be the ability to semantically describe in the manifest / playlist how to copy tokens from the document source URI to a subsequent URI described in the document. Doing this would allow for highly cacheable manifest / playlist files in place of real-time manipulation providing better scalability.

This capability is enabled in DASH by the Annex I Flexible Insertion of URL Parameters functionality which introduces an element that describes how to the player how to build query strings and which subsequent requests to attach the query string to. This looks something like:

MPD URI: https://cdn.example.com/content/content.mpd?token=12345<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdn.example.com%2Fcontent%2Fcontent.mpd%3Ftoken%3D12345&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6gqTbLANlkWupJRWIf15pprirkuU7hVkD8t%2FQtVZI0E%3D&reserved=0>
MPD Body:

<MPD ...>
    <EssentialProperty schemeIdUri="urn:mpeg:dash:urlparam:2014" xmlns:up="urn:mpeg:dash:schema:urlparam:2014">
        <up:ExtUrlQueryInfo includeInRequests="segment steering" queryTemplate="token=$query:token$" useMPDUrlQuery="true"/>
    </EssentialProperty>
    <Period>...</Period>
    ...
</MPD>

In HLS the Playlist variables introduced with the EXT-X-DEFINE tag provide the ability to pull variables from the Multi-Variant to the Variant. Our question is if this could be extended to allow playlists to pull from the playlist URIs?

Conceptually this could look something like the following:

MV URI: https://cdn.example.com/content/mv.m3u8?token=12345<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdn.example.com%2Fcontent%2Fmv.m3u8%3Ftoken%3D12345&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rb611VQNZ6kDcrm5sNp4IvO2muRsNGBsVTaoo210Qlo%3D&reserved=0>
MV Body:

#EXTM3U
#EXT-X-DEFINE:QUERYPARAM="token"
#EXT-X-CONTENT-STEERING:SERVER-URI="/steering?token={$token}"
#EXT-X-STREAM-INF:BANDWIDTH=8000000,PATHWAY-ID="CDN-A"
high/variant.m3u8?token={$token}
#EXT-X-STREAM-INF:BANDWIDTH=4500000,PATHWAY-ID="CDN-B"
high/variant.m3u8?token={$token}
...

Variant URI: https://cdn.example.com/content/high/variant.m3u8?token=12345<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdn.example.com%2Fcontent%2Fhigh%2Fvariant.m3u8%3Ftoken%3D12345&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xjs8HbJJL%2BRZUsQTliUfWAfLdyzdQ4WSwvl6u97FmI0%3D&reserved=0>
Variant Body:

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXT-X-DEFINE:IMPORT="token"
#EXT-X-MAP:URI="map.mp4?token={$token}"
#EXTINF 4,
segment1.mp4?token={$token}
#EXTINF 4,
segment2.mp4?token={$token}
...

The variant could also optionally have QUERYPARAM="token" to pull it in instead of import which lets MV-less streams also use this functionality.

Any thoughts on this functionality extension?

Thanks,
Zack
--
Hls-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhls-interest&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qIMGKDarv45UqA5cnmnvL03J8PKD1511YEA%2B5b9dFQg%3D&reserved=0>

--
Hls-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhls-interest&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qIMGKDarv45UqA5cnmnvL03J8PKD1511YEA%2B5b9dFQg%3D&reserved=0>

--
Hls-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhls-interest&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qIMGKDarv45UqA5cnmnvL03J8PKD1511YEA%2B5b9dFQg%3D&reserved=0>
--
Hls-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhls-interest&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qIMGKDarv45UqA5cnmnvL03J8PKD1511YEA%2B5b9dFQg%3D&reserved=0>

--
Hls-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fhls-interest&data=05%7C01%7Czachary.cava%40disneystreaming.com%7Cadfd4614d5d04a32265208db1070db46%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C638121849146100676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qIMGKDarv45UqA5cnmnvL03J8PKD1511YEA%2B5b9dFQg%3D&reserved=0>

--
Hls-interest mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hls-interest