Open Bug 1608067 Opened 2 years ago Updated 5 months ago

Vidible videos from m.huffpost.com are not displayed on Fenix with Strict ETP ON

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

74 Branch
ARM
Android
defect

Tracking

()

Tracking Status
firefox74 --- affected
firefox87 --- affected

People

(Reporter: sergiu, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [tp-yellowlist-active][tp-shim-complex][tp-embedded-media])

Attachments

(1 file)

Attached image Screenshot_1.png

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:

  1. Navigate to: https://m.huffpost.com/us/entry/us_5c58a482e4b09293b2075f74
  2. Observe the video placeholder.

Expected Behavior:
The video placeholder is displayed.

Actual Behavior:
The video placeholder is not displayed.

Notes:

  1. Screenshot attached.
  2. Setting the ETP to Standard, fixes the issue.
Blocks: etp-breakage
No longer blocks: tp-breakage

The video comes from vidible.tv, which is on the Disconnect tracking protection list.

Blocks: tpvideo
No longer blocks: etp-breakage

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&amp;h=1800&amp;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.

Summary: Videos from m.huffpost.com are not displayed on Fenix with Standard ETP ON → Vidible videos from m.huffpost.com are not displayed on Fenix with Standard ETP ON

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?)

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.

Whiteboard: [tp-yellowlist-active][tp-shim-complex][tp-embedded-media]

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)

Summary: Vidible videos from m.huffpost.com are not displayed on Fenix with Standard ETP ON → Vidible videos from m.huffpost.com are not displayed on Fenix with Strict ETP ON

I've managed to create a shim which lets users opt into seeing these videos, I'll try to post a patch ASAP.

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.

You need to log in before you can comment on or make changes to this bug.