Bug 272525 – REGRESSION (iOS 17.4): HLS Videos with AES Encryption in combination with data-uri's fail to start

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[markmeeus]

In our web app we use data-uri's for loading hls encoded videos.

These videos are AES encrypted and the key url is also passed as a data-uri.

This used to work up to iOS 17.3, but after upgrading to 17.4 our videos fail to start.

In the developer console, we do see a request to the first fragment, so I assume the manifests are parsed correctly.

[markmeeus]

We are not able to reproduce this issue on a simulator. Only real devices seem to have this problem

[Alexey Proskuryakov]

Thank you for the report! Would it be possible to share a URL where we can reproduce this?

[Radar WebKit Bug Importer]

<rdar://problem/126294263>

[Vipul Firodiya]

We are also facing the same issue, manifest is getting parsed correctly. There is a problem in the decryption of the fragments.
Non encrypted HLS is working fine.

[markmeeus]

@Vipul Firodiya is your key url also a data uri? It seems that at least someone solved this issue by using a key on https, see this ticket:
https://github.com/videojs/video.js/issues/8641

[markmeeus]

Also, maybe a wild guess, but this seems a recent change that might be related:
https://bugs.webkit.org/show_bug.cgi?id=267804

[markmeeus]

We just did a test with a key on an https url, and that does seem to work.

[Ahmad Saleem]

(In reply to markmeeus from comment #5)
> @Vipul Firodiya is your key url also a data uri? It seems that at least
> someone solved this issue by using a key on https, see this ticket:
> https://github.com/videojs/video.js/issues/8641

I just checked and it seems to work fine in iOS 17.4 as well.

Can you share the URL, with 'http' so we can reproduce where it does not work.

[markmeeus]

It's a bit tedious to set up a sample, because our hls fragments are generated on the fly.
But I think it can be easily reproduced by using a stream manifest with a key definition that looks like this:

#EXT-X-KEY:METHOD=AES-128,URI="data:application/octet-stream;charset=utf-8;base64,REDACTED-KEY-IN-BASE64",IV=0XFB84E8FB21A0D6170945E0D0C2FD6E35

so it's not related to http, but to having the key in a data uri like this.

[Vipul Firodiya]

(In reply to markmeeus from comment #9)
> It's a bit tedious to set up a sample, because our hls fragments are
> generated on the fly.
> But I think it can be easily reproduced by using a stream manifest with a
> key definition that looks like this:
> 
> #EXT-X-KEY:METHOD=AES-128,URI="data:application/octet-stream;charset=utf-8;
> base64,REDACTED-KEY-IN-BASE64",IV=0XFB84E8FB21A0D6170945E0D0C2FD6E35
> 
> so it's not related to http, but to having the key in a data uri like this.

are you using "data:application/octet-stream;charset=utf-8;
> base64,REDACTED-KEY-IN-BASE64" this format to resolve the issue or purely https
url like> blob:https://example.origin/e2094e7c-218c-42ca-8898-79a2f94a632c

I am having url like this blob:https://example.origin/e2094e7c-218c-42ca-8898-79a2f94a632c. but it is not working.

One of the way I have used to resolve this issue for now, is decrypt the HLS content first and remove #EXT-X-KEY: line from .m3u8 file and pass that to src of video

[markmeeus]

yes, blob's don't work either.
You have to have the key url with https to work around this issue.

in your case something like

#EXT-X-KEY:METHOD=AES-128,URI="https://example.origin/video/xyz/key",IV=0XFB84E8FB21A0D6170945E0D0C2FD6E35

[Jean-Yves Avenard [:jya]]

Do you have a HLS manifest available to test this?

thank you

[markmeeus]

We created a small demo here:

https://www.romenov.com/streaming/

It has 2 links, the first one shows a video with encrypted segments where the key is loaded with an http request.
The key line in the m3u8 looks like this:

#EXT-X-KEY:METHOD=AES-128,URI="oceans.key"

This video works in Safari and Mobile Safari on iOS devices.

The second link has the exact same video, except it loads the key using a data uri.
The key line looks like this:

#EXT-X-KEY:METHOD=AES-128,URI="data:application/octet-stream;charset=utf-8;base64,9XG/7P0aua2wXOb6Aw79gQ=="


This one does work in Safari, but not in Mobile Safari on a 17.4 iOS Device. (Make sure to test on an actual device because it does work in a simulator)

[Jean-Yves Avenard [:jya]]

Here is a test page:
https://www.romenov.com/streaming/

17.4.1:
https://www.romenov.com/streaming/aes-key-link/index.html plays
https://www.romenov.com/streaming/aes-key-data/index.html doesn’t play

17.5 (21F62): 
https://www.romenov.com/streaming/aes-key-link/index.html plays
https://www.romenov.com/streaming/aes-key-data/index.html plays

So it appears fixed.

[Jean-Yves Avenard [:jya]]

likely the same as bug 245428 which is resolved in iOS 17.5

[Jean-Yves Avenard [:jya]]

ignore above comment, I entered it in the wrong bug. Apologies