Vidible videos from m.huffpost.com are not displayed on Fenix with Strict ETP ON
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: sergiu, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Whiteboard: [tp-yellowlist-active][tp-shim-complex][tp-embedded-media])
Attachments
(1 file)
(deleted),
image/png
|
Details |
Browser / Version
Firefox Preview Nightly 200109 (🦎 74.0a1-20200107215758)
Operating System
Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
Steps to reproduce:
- Navigate to: https://m.huffpost.com/us/entry/us_5c58a482e4b09293b2075f74
- Observe the video placeholder.
Expected Behavior:
The video placeholder is displayed.
Actual Behavior:
The video placeholder is not displayed.
Notes:
- Screenshot attached.
- Setting the ETP to Standard, fixes the issue.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
The video comes from vidible.tv, which is on the Disconnect tracking protection list.
Comment 2•5 years ago
|
||
Thankfully, the site embeds the video along with a placeholder image, and a script tag which specifies a callback when the video is ready via a JSONP landing:
<div data-aria-label="Video"
data-provider="vidible"
id="56ccbfa6e4b0d32d2ea6d99e"
class="vdb_player"
vdb_params="(snip)&m.onLoad=vidibleOnPlayerReady"
data-placeholder="//img.vidible.tv/prod/2019-02/04/5c58bc05523dc3560d7be1a3/5c58bd4be39d15435c3b8541_o_U_v1.jpg?w=2880&h=1800&q=60">
<script type="text/javascript" src="https://delivery.vidible.tv/jsonp/bid=5b7607b4faf63600013b9821/pid=56ccbfa6e4b0d32d2ea6d99e/vid=5c58bc05523dc3560d7be1a3/56000e19e4b0e4e194b84b31.js?(snip)&m.onLoad=vidibleOnPlayerReady"></script>
</div>
As such, we should be able to show the placeholder image and let the user click on it to allow the video to load. For instance, we could replace the network-load of the JSON request above with something like this:
const src = document.currentScript.src;
const id = src.match("/pid=(.*?)/")[1];
const container = document.getElementById(id);
if (!container) return;
container.innerHTML = "";
const t = document.createElement("span");
t.innerText = "Click to unblock video";
t.style.position = "absolute";
t.style.fontSize = "40pt";
t.style.color = "white";
t.style.margin = "1em";
t.style.pointerEvents = "none";
container.appendChild(t);
const i = document.createElement("img");
i.src = container.getAttribute("data-placeholder");
i.style.cursor = "pointer";
i.addEventListener("click", function() {
container.innerHTML = "";
// allow the request from this script to bypass tracking protection:
const s = document.createElement("script");
s.src = src;
container.appendChild(s);
});
container.appendChild(i);
But this is just a start. We'll also need to allow requests to https://cdn-ssl.vidible.tv/prod/player/js/*
for that script tag, as they load scripts such as vidible_min.js
, rapid.js
, and player-hls-latest.js
just for the current version of the player they are using, along with images for the player's skin.
These scripts also make a ton of requests to other ads/trackers as the video loads, and I haven't been able to confirm if all of them can simply be blocked without additional effort. It would be much easier to continue testing this once I have an API which allows bypassing specific requests in strict mode, letting others continue to be blocked.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I just checked again, and I'm confident that the above shim should be workable, if we whitelist enough resources. It's an encrypted HLS video, and I can't whitelist all of the resources being loaded via urlclassifier.trackingSkipURLs
(the string gets too long), but it seems that if we whitelist enough, we should be able to get it working:
https://delivery.vidible.tv/jsonp/bid=5b7607b4faf63600013b9821/pid=56ccbfa6e4b0d32d2ea6d99e/vid=5c58bc05523dc3560d7be1a3/56000e19e4b0e4e194b84b31.js (the script we initially block)
https://delivery.vidible.tv/placement/56ccbfa6e4b0d32d2ea6d99e (the video's ID which the script knows)
https://img.vidible.tv/prod/2019-02/04/5c58bc05523dc3560d7be1a3/5c58bd4be39d15435c3b8541_o_U_v1.jpg (the data-placeholder URL we also know)
https://cdn-ssl.vidible.tv/prod/player/js/21.1.216/skins/skin6.js
https://cdn-ssl.vidible.tv/prod/player/js/21.1.216/coverings/skin6.js
https://cdn-ssl.vidible.tv/prod/player/js/21.1.216/extras/rapid.js
https://cdn-ssl.vidible.tv/prod/player/js/21.1.216/html5/player-hls-latest-min.js
https://cdn-ssl.vidible.tv/prod/player/js/21.1.216/vidible-min.js
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/playlist_v2.m3u8
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_853x480_v2.m3u8
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_640x360_v2.m3u8
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_1920x1080_v2.m3u8
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_1280x720_v2.m3u8
https://hlsrv.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_426x240_v2.m3u8
https://videos.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_853x480_v2-encryption-00001.key
https://videos.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_640x360_v2-encryption-00001.key
https://videos.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_426x240_v2-encryption-00001.key
https://videos.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_1920x1080_v2-encryption-00001.key
https://videos.vidible.tv/prod/5c58bc05523dc3560d7be1a3/2019-02-04/hls/segment_1280x720_v2-encryption-00001.key
So the spoofer would ostensibly need to un-block URLs of this form (in addition to the JSONP URL that was initially blocked, and the data-placeholder
URL):
https://delivery.vidible.tv/placement/(video ID)
https://hlsrv.vidible.tv/prod/*/*.m3u8
https://videos.vidible.tv/prod/*/*.key
https://cdn-ssl.vidible.tv/prod/player/js/*/*.js
(Though I wonder if we ought to just whitelist the URLs for the video sources and player in general, since they are loaded dynamically by a script which strict tracking protection normally blocks?)
Comment 4•5 years ago
|
||
Actually, it turns out that the list of URL wildcards above should do it, as the following value for urlclassifier.trackingSkipURLs
unblocks the video in strict mode:
https://delivery.vidible.tv/jsonp/bid=5b7607b4faf63600013b9821/pid=56ccbfa6e4b0d32d2ea6d99e/vid=5c58bc05523dc3560d7be1a3/56000e19e4b0e4e194b84b31.js,https://delivery.vidible.tv/placement/56ccbfa6e4b0d32d2ea6d99e,https://img.vidible.tv/prod/2019-02/04/5c58bc05523dc3560d7be1a3/5c58bd4be39d15435c3b8541_o_U_v1.jpg,https://hlsrv.vidible.tv/prod/,https://videos.vidible.tv/prod/,https://cdn-ssl.vidible.tv/prod/player/js/
And the click-to-play script in comment 2 works on top of that, so a shim should be quite possible here.
Updated•5 years ago
|
Comment 5•4 years ago
|
||
The issue still occurs, with ETP - Strict the video is not displayed.
https://prnt.sc/y56n9w
Tested with:
Browser / Version: Firefox Nightly 210202 (🦎 87.0a1-20210202095107)
Operating System: Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
Comment 6•4 years ago
|
||
I've managed to create a shim which lets users opt into seeing these videos, I'll try to post a patch ASAP.
Comment 7•3 years ago
|
||
This is now working on nightly desktop builds, and will also end up on Android nightly builds by Fx93. We will need more time to ensure that the UX is where we want it before we let it ride the trains to release, though.
Comment 8•3 years ago
|
||
The site has changed, and now it seems as though they rely on other blocked trackers. This will require re-diagnosis.
Comment 9•2 years ago
|
||
The problem here is that they are now using Connatix player, which is blocked as a tracker. There is no simple way around this, we would need to allow users to opt into allowing the tracking to see the video.
Comment 10•2 years ago
|
||
Still reproducible.
Tested on:
• Browser / Version: Firefox Nightly 106.0a1-20220903093211
• Operating System: OnePlus 6 A6000 (Android 11) -1080 x 2280 pixels, 19:9 ratio (~402 ppi pixel density)
Updated•2 years ago
|
Description
•