After investigating this issue further, I'm going to update what I found here. --- First, this issue was a regression, which is caused by bug1443942, in which we blocked mid-flight redirect since Fx61. However, sometimes FB does that during video playback on its mobile version website. According to the comment [1], > Most media CDNs do dynamic load balancing by spewing users across many servers. This traffic spewing is usually intelligent, but almost always non-deterministic; the necessary state to map users consistently to the same node in a way that was also traffic-fair is too big. I don't know how many media CDNs in the wild are working on this way, but I indeed found out that the mobile version FB sometime rediects us to different origin to access media resource when seeking occurs. From [2], we can see that server response `302` status code with new location refering to `video.xx.fbcdn.net` to our request to old location `video-sea1-1.xx.fbcdn.net`. And then requesting new data [3] from the new location. However, we have blocked all types of mid-flight redirect in bug1443942, and the initial reason, which drove us to do that, is to prevent content length leaking from WAV file in bug1441153. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 [2] https://drive.google.com/file/d/1SUtk7XJ20Ah2iSCrsEelVge51MC4uiVm/view?usp=sharing [3] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing --- Second, let's see if this whole process follows the current spec, is it proper to block the mid-flight redirect based on the spec perspective? First, every time when we fetch media data, we would check media element's `crossorigin` attribute to decide what kinds of request we should send, [4] and the request mode would `no-cors` by default [5]. Therefore, from the spec's perspective, it seems that the spec doesn't prohibit us to load media resource from different origins. However, the spec mentions about possible security issues, in which it's danger to expose some sensitive data like metadata, duration.. e.t.c [6]. [4] https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource:create-a-potential-cors-request [5] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request [6] https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations --- Back to our current issue, since I don't know how many media CDNs in the wild would perform the mid-flight redirect during playback, so I think it's less pratical to ask all those websites adding `crossorigin` on their video element in order to solve this issue. We can also notice that, even if we send `no-cors` mode request to the remote server, it actually response to us with `cors` mode [3], where the response contains `access-control-origin` and `access-control-expose-header`. Even the response mode, which we actually expect for our request, is `opaque` though. [7] So here I have two proposals for solving this issue. (1) stop blocking mid-flight redirect, but we restrict showing sentive media information, such as media type, duration, in this situation. (2) if the response is `cors` mode, then check if we can pass CORS policy or not, even if the media element doesn't set `crossorigin`, to decide whether we should block this cross-origin access. It seems a way which Chrome implemented before [8], but I couldn't find their current implementation for this case, those codes has been removed from their codebase. [7] https://fetch.spec.whatwg.org/#ref-for-concept-filtered-response-opaque [8] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 --- Hi, jya, baku, May I have your opinion on this issue? Thank you.
Bug 1566572 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
After investigating this issue further, I'm going to update what I found here. --- First, this issue was a regression, which is caused by bug1443942, in which we blocked mid-flight redirect since Fx61. However, sometimes FB does that during video playback on its mobile version website. According to the comment [1], > Most media CDNs do dynamic load balancing by spewing users across many servers. This traffic spewing is usually intelligent, but almost always non-deterministic; the necessary state to map users consistently to the same node in a way that was also traffic-fair is too big. I don't know how many media CDNs in the wild are working on this way, but I indeed found out that the mobile version FB sometime rediects us to different origin to access media resource when seeking occurs. From [2], we can see that server response `302` status code with new location refering to `video.xx.fbcdn.net` to our request to old location `video-sea1-1.xx.fbcdn.net`. And then requesting new data [3] from the new location. However, we have blocked all types of mid-flight redirect in bug1443942, and the initial reason, which drove us to do that, is to prevent content length leaking from WAV file in bug1441153. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 [2] https://drive.google.com/file/d/1SUtk7XJ20Ah2iSCrsEelVge51MC4uiVm/view?usp=sharing [3] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing --- Second, let's see if this whole process follows the current spec, is it proper to block the mid-flight redirect based on the spec perspective? First, every time when we fetch media data, we would check media element's `crossorigin` attribute to decide what kinds of request we should send, [4] and the request mode would `no-cors` by default [5]. Therefore, from the spec's perspective, it seems that the spec doesn't prohibit us to load media resource from different origins. However, the spec mentions about possible security issues, in which it's danger to expose some sensitive data like metadata, duration.. e.t.c [6]. [4] https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource:create-a-potential-cors-request [5] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request [6] https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations --- Back to our current issue, since I don't know how many media CDNs in the wild would perform the mid-flight redirect during playback, so I think it's less pratical to ask all those websites adding `crossorigin` on their video element in order to solve this issue. We can also notice that, even if we send `no-cors` mode request to the remote server, it actually response to us with `cors` mode [7], where the response contains `access-control-origin` and `access-control-expose-header`. Even the response mode, which we actually expect for our request, is `opaque` though. [8] So here I have two proposals for solving this issue. (1) stop blocking mid-flight redirect, but we restrict showing sentive media information, such as media type, duration, in this situation. (2) if the response is `cors` mode, then check if we can pass CORS policy or not, even if the media element doesn't set `crossorigin`, to decide whether we should block this cross-origin access. It seems a way which Chrome implemented before [9], but I couldn't find their current implementation for this case, those codes has been removed from their codebase. [7] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing [8] https://fetch.spec.whatwg.org/#ref-for-concept-filtered-response-opaque [9] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 --- Hi, jya, baku, May I have your opinion on this issue? Thank you.
After investigating this issue further, I'm going to update what I found here. --- First, this issue was a regression, which is caused by bug1443942, in which we blocked mid-flight redirect since Fx61. However, sometimes FB does that during video playback on its mobile version website. According to the comment [1], > Most media CDNs do dynamic load balancing by spewing users across many servers. This traffic spewing is usually intelligent, but almost always non-deterministic; the necessary state to map users consistently to the same node in a way that was also traffic-fair is too big. I don't know how many media CDNs in the wild are working on this way, but I indeed found out that the mobile version FB sometime rediects us to different origin to access media resource when seeking occurs. From [2], we can see that server response `302` status code with new location refering to `video.xx.fbcdn.net` to our request to old location `video-sea1-1.xx.fbcdn.net`. And then requesting new data [3] from the new location. However, we have blocked all types of mid-flight redirect in bug1443942, and the initial reason, which drove us to do that, is to prevent content length leaking from WAV file in bug1441153. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 [2] https://drive.google.com/file/d/1SUtk7XJ20Ah2iSCrsEelVge51MC4uiVm/view?usp=sharing [3] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing --- Second, let's see if this whole process follows the current spec, is it proper to block the mid-flight redirect based on the spec perspective? First, every time when we fetch media data, we would check media element's `crossorigin` attribute to decide what kinds of request we should send, [4] and the request mode would `no-cors` by default [5]. Therefore, from the spec's perspective, it seems that the spec doesn't prohibit us to load media resource from different origins. However, the spec mentions about possible security issues, in which it's danger to expose some sensitive data like metadata, duration.. e.t.c [6]. [4] https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource:create-a-potential-cors-request [5] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request [6] https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations --- Back to our current issue, since I don't know how many media CDNs in the wild would perform the mid-flight redirect during playback, so I think it's less pratical to ask all those websites adding `crossorigin` on their video element in order to prevent this issue. We can also notice that, even if we send `no-cors` mode request to the remote server, it actually response to us with `cors` mode [7], where the response contains `access-control-origin` and `access-control-expose-header`. Even the response mode, which we actually expect for our request, is `opaque` though. [8] So here I have two proposals for solving this issue. (1) stop blocking mid-flight redirect, but we restrict showing sentive media information, such as media type, duration, in this situation. (2) if the response is `cors` mode, then check if we can pass CORS policy or not, even if the media element doesn't set `crossorigin`, to decide whether we should block this cross-origin access. It seems a way which Chrome implemented before [9], but I couldn't find their current implementation for this case, those codes has been removed from their codebase. [7] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing [8] https://fetch.spec.whatwg.org/#ref-for-concept-filtered-response-opaque [9] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 --- Hi, jya, baku, May I have your opinion on this issue? Thank you.
After investigating this issue further, I'm going to update what I found here. --- First, this issue was a regression, which is caused by bug1443942, in which we blocked mid-flight redirect since Fx61. However, sometimes FB does that during video playback on its mobile version website. According to the comment [1], > Most media CDNs do dynamic load balancing by spewing users across many servers. This traffic spewing is usually intelligent, but almost always non-deterministic; the necessary state to map users consistently to the same node in a way that was also traffic-fair is too big. I don't know how many media CDNs in the wild are working on this way, but I indeed found out that the mobile version FB sometime rediects us to different origin to access media resource when seeking occurs. From [2], we can see that server response `302` status code with new location refering to `video.xx.fbcdn.net` to our request to old location `video-sea1-1.xx.fbcdn.net`. And then requesting new data [3] from the new location. However, we have blocked all types of mid-flight redirect in bug1443942, and the initial reason, which drove us to do that, is to prevent content length leaking from WAV file in bug1441153. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 [2] https://drive.google.com/file/d/1SUtk7XJ20Ah2iSCrsEelVge51MC4uiVm/view?usp=sharing [3] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing --- Second, let's see if this whole process follows the current spec, is it proper to block the mid-flight redirect based on the spec perspective? First, every time when we fetch media data, we would check media element's `crossorigin` attribute to decide what kinds of request we should send, [4] and the request mode would be `no-cors` by default [5]. Therefore, from the spec's perspective, it seems that the spec doesn't prohibit us to load media resource from different origins. However, the spec mentions about possible security issues, in which it's danger to expose some sensitive data like metadata, duration.. e.t.c [6]. [4] https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource:create-a-potential-cors-request [5] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request [6] https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations --- Back to our current issue, since I don't know how many media CDNs in the wild would perform the mid-flight redirect during playback, so I think it's less pratical to ask all those websites adding `crossorigin` on their video element in order to prevent this issue. We can also notice that, even if we send `no-cors` mode request to the remote server, it actually response to us with `cors` mode [7], where the response contains `access-control-origin` and `access-control-expose-header`. Even the response mode, which we actually expect for our request, is `opaque` though. [8] So here I have two proposals for solving this issue. (1) stop blocking mid-flight redirect, but we restrict showing sentive media information, such as media type, duration, in this situation. (2) if the response is `cors` mode, then check if we can pass CORS policy or not, even if the media element doesn't set `crossorigin`, to decide whether we should block this cross-origin access. It seems a way which Chrome implemented before [9], but I couldn't find their current implementation for this case, those codes has been removed from their codebase. [7] https://drive.google.com/file/d/1QEvsYlX8tOoByQ_T5e0T2LtSYF_5w9ma/view?usp=sharing [8] https://fetch.spec.whatwg.org/#ref-for-concept-filtered-response-opaque [9] https://bugs.chromium.org/p/chromium/issues/detail?id=532569 --- Hi, jya, baku, May I have your opinion on this issue? Thank you.