1799210 - mail.ru playback error

Status: NEW

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

Description

[Andrew Jarvis]

Attachment: HTML page exhibiting playback error with mail.ru video.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

Loaded the attached file locally.
Loaded the file from https://ooltra.net/Mail_ruVideoBug.html using both FireFox and Microsoft Edge.

Actual results:

The embedded video plays when the file is loaded locally and also when loaded remotely using Microsoft Edge.
When run using FireFox, the message 'Playback error' is displayed. Running under the debugger reveals that a cross-origin reference error is occurring.
This happens with any mail.ru video. I have had no problems with other video hosting sites.

Expected results:

The video should play.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[John Lin [:jhlin][:jolin]]

It looks like the content from 'my.mail.ru' is blocked by 'Enhanced Tracking Protection' (ETP). Clicking on the shield icon in the address bar and turning off the protection for this site makes the video playable.

Moving this to 'Privacy: Anti-Tracking' and mark as 'WONTFIX'

Comment 3

[Emma Zühlcke [:emz]]

Thanks! Let's open this back up for triage.

Comment 4

[Tim Huang[:timhuang]]

The playback error is because we block cookie access of mail.ru as a tracker. We don't block the resource load.

Comment 5

[Benjamin VanderSloot [:bvandersloot]]

Finally getting to this. mail.ru is listed as a Social tracker by Disconnect and is also hosting content, e.g. the video here. Interestingly, the video works and can be downloaded, but some script in the iframe seems to cause failure when it can't set/read cookies.

I think it makes sense to request this be moved to the "Content" list. At this point breakage will only affect strict mode. However, this is a continuation of a broader trend of domain re-use between tracking and content increasing and that concerns me.

If :pbz or :timhuang agree, I'll put the PR in to disconnect citing this issue.

Comment 6

[Tim Huang[:timhuang]]

I think it makes sense to open an issue to disconnect.

Comment 7

[Benjamin VanderSloot [:bvandersloot]]

Filed: https://github.com/disconnectme/disconnect-tracking-protection/issues/306

Comment 8

[Emma Zühlcke [:emz]]

I've tried shimming localStorage to be a no-op for the embedded frame, but it looks like the video endpoint still replies with a 403. There is probably some authentication involved. It's also worth nothing that this makes use of EME.

Comment 9

[Emma Zühlcke [:emz]]

The request for the video results in a 403 from the server. This is most likely caused by cookies not being included in the request. Doesn't appear to be easily shim-able.

https://cdn32.my.mail.ru/hv/61359201.mp4/stream.mpd?slave[]=s:http://10.146.243.4:9091/video4/61359201-hv&p=f&expire_at=1673301600&touch=1487879602&reg=202&sign=ed78b0212c123cf47480bed4b2a3b2b583e23e53

We could consider unblocking just the required tracker when the user clicks the play button (and consents).

Comment 10

[Thomas Wisniewski [:twisniewski]]

Yeah, it looks like they need that request to have the video_key cookie defined, which is being blocked.

The cookie's value is of course defined on the frame's document (https://my.mail.ru/video/embed/1686092937936515007)

FWIW, it doesn't seem to be specific to the user, just the video (65570c975a2e0060b4179967fbad43d3eb7c8d0d in this case)

So any shim we wrote would need to pass the cookie along, and we would of course need to trust that its value remains video-specific.