The new third party policy of cookies, blocks all cookies from a third party media server, making it impossible to track the state of the player. The RFC specifically states: HTTP requests often include session state ("cookies"), which may contain private user data. Implementations MUST follow cookie restriction and expiry rules specified by "HTTP State Management Mechanism" [RFC6265] to protect themselves from attack. See also the Security Considerations section of that document, and "Use of HTTP State Management" [RFC2964]. Besides still not supporting MSE.
<rdar://problem/35087119>
(In reply to ealarcon from comment #0) > The new third party policy of cookies, blocks all cookies from a third party > media server, making it impossible to track the state of the player. > > The RFC specifically states: > > HTTP requests often include session state ("cookies"), which may > contain private user data. Implementations MUST follow cookie > restriction and expiry rules specified by "HTTP State Management > Mechanism" [RFC6265] to protect themselves from attack. See also the > Security Considerations section of that document, and "Use of HTTP > State Management" [RFC2964]. > > Besides still not supporting MSE. Can you provide a test case? And is this behavior any different for image resources?
(In reply to Jer Noble from comment #2) > (In reply to ealarcon from comment #0) > > The new third party policy of cookies, blocks all cookies from a third party > > media server, making it impossible to track the state of the player. > > > > The RFC specifically states: > > > > HTTP requests often include session state ("cookies"), which may > > contain private user data. Implementations MUST follow cookie > > restriction and expiry rules specified by "HTTP State Management > > Mechanism" [RFC6265] to protect themselves from attack. See also the > > Security Considerations section of that document, and "Use of HTTP > > State Management" [RFC2964]. > > > > Besides still not supporting MSE. > > Can you provide a test case? And is this behavior any different for image > resources? Hello, i've created a demo for testing: http://www.altavoz.net/hls_test/ If you try it, the player will play for about 15 seconds before coming to a stop, this is because the state cookies that the media server sets up for the player are ignored and not returned, so the media server doesn't know if the player is working. The media server is in another domain, so i expected the cookies to be kept only for the playing session, and then erased. I've made the test of visiting de media server "home" and then going back to the site with the embedded media, and it plays fine but makes it impossible to use the media content on multiples sites and have a central media server.
(In reply to ealarcon from comment #3) > (In reply to Jer Noble from comment #2) > > (In reply to ealarcon from comment #0) > > > The new third party policy of cookies, blocks all cookies from a third party > > > media server, making it impossible to track the state of the player. > > > > > > The RFC specifically states: > > > > > > HTTP requests often include session state ("cookies"), which may > > > contain private user data. Implementations MUST follow cookie > > > restriction and expiry rules specified by "HTTP State Management > > > Mechanism" [RFC6265] to protect themselves from attack. See also the > > > Security Considerations section of that document, and "Use of HTTP > > > State Management" [RFC2964]. > > > > > > Besides still not supporting MSE. > > > > Can you provide a test case? And is this behavior any different for image > > resources? > > Hello, i've created a demo for testing: > > http://www.altavoz.net/hls_test/ > > If you try it, the player will play for about 15 seconds before coming to a > stop, this is because the state cookies that the media server sets up for > the player are ignored and not returned, so the media server doesn't know if > the player is working. > The media server is in another domain, so i expected the cookies to be kept > only for the playing session, and then erased. > I've made the test of visiting de media server "home" and then going back to > the site with the embedded media, and it plays fine but makes it impossible > to use the media content on multiples sites and have a central media server. Are you looking for the cookies on the request for the .m3u8, or for the requests on each of the .ts segments?
(In reply to Jer Noble from comment #4) > (In reply to ealarcon from comment #3) > > (In reply to Jer Noble from comment #2) > > > (In reply to ealarcon from comment #0) > > > > The new third party policy of cookies, blocks all cookies from a third party > > > > media server, making it impossible to track the state of the player. > > > > > > > > The RFC specifically states: > > > > > > > > HTTP requests often include session state ("cookies"), which may > > > > contain private user data. Implementations MUST follow cookie > > > > restriction and expiry rules specified by "HTTP State Management > > > > Mechanism" [RFC6265] to protect themselves from attack. See also the > > > > Security Considerations section of that document, and "Use of HTTP > > > > State Management" [RFC2964]. > > > > > > > > Besides still not supporting MSE. > > > > > > Can you provide a test case? And is this behavior any different for image > > > resources? > > > > Hello, i've created a demo for testing: > > > > http://www.altavoz.net/hls_test/ > > > > If you try it, the player will play for about 15 seconds before coming to a > > stop, this is because the state cookies that the media server sets up for > > the player are ignored and not returned, so the media server doesn't know if > > the player is working. > > The media server is in another domain, so i expected the cookies to be kept > > only for the playing session, and then erased. > > I've made the test of visiting de media server "home" and then going back to > > the site with the embedded media, and it plays fine but makes it impossible > > to use the media content on multiples sites and have a central media server. > > Are you looking for the cookies on the request for the .m3u8, or for the > requests on each of the .ts segments? I'm looking for the cookies on the requests for the m3u8, i haven't checked on the segments, at this time the segments doesn't need cookies
I generated some test pages which load <video> and <img> resources in a third-party context, and where those resources respond with a Set-Cookie header. In both the case for <video> and <img>, the cookies are not sent with the next request for the same resource. This is as intended. Here's why: The entire purpose of third-party cookie blocking is to disallow requests to a third-party origin from setting cookies, at all. However, for your use case, cookies are not the correct tool to be using; cookies are saved across page reload, and potentially across browser instances, and it sounds like you're trying to track individual player instances. If you want to track per-player instance, I suggest you try adding a UUID parameter to the playlist URL. You could even do an XHR to the media server to request the session ID to use first (assuming you set the correct CORS headers on the media server). These techniques are perfectly compatible with third-party cookie blocking, and even 1st party cookie blocking.
Yes, the cookies are used to track every player instance specifically because every player instance needs something diferent that changes over time, you can't change the url of a tag video or audio while playing wihtout restarting, or can you?. The techniques you mention do not work for the intended purposes, so anyway thanks for the time reviewing the issue
(In reply to ealarcon from comment #7) > Yes, the cookies are used to track every player instance specifically > because every player instance needs something diferent that changes over > time, you can't change the url of a tag video or audio while playing wihtout > restarting, or can you?. No, but why should the client change its identifier mid-playback? The token just tells the server which player is doing the requesting; if the server needs to change, mid session, there's no reason for the session identifier to change as well. And importantly, there's nothing the client can do to change what cookie is sent to the third-party origin, even when third-party cookie blocking is disabled; all the changes must take place server-side, not client-side. At least with the identifier technique, the client could use the identifier to make side-channel requests of the media server. Anyway, I'm not trying to tell you how this feature should be implemented; I'm just pointing out that Set-Cookie is not the right tool for the job, and that other techniques exist.
Thank you for your comments, but i assure you that all the other alternatives that you mention have been tested and discarded, thanks anyway.