Opened 23 months ago

Last modified 8 months ago

#22616 assigned defect

On higher security levels videos can't be downloaded anymore with "Save Video As..."

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-7.0-issues, tbb-regression
Cc: mcs, brade, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by gk)

Following https://blog.torproject.org/blog/tor-browser-701-released#comment-269143:

1. Go to: https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2016/miniconf_cambridge16/reproducible_builds_status_update.webm, NoScript will display the video as a blocked object.
2. Click on the object and allow the video to play.
3. Right click "Save Video As...", choose a location, and accept.
4. Open "about:downloads" to verify the video isn't downloading.
5. Now, right click anywhere and under the NoScript menu click "Revoke Temporary Permissions".
6. Repeat step 1, you will presented with the blocked object. Right click on that object and choose "Save Link As...", accept.
7. Open "about:downloads" and verity the video is now downloading.

Child Tickets

Change History (13)

comment:1 Changed 23 months ago by gk

It seems to me 7. is failing for me as well, thus, there might be more to it. (This is both on a Linux 64bit machine)

comment:2 in reply to:  1 ; Changed 23 months ago by gk

Replying to gk:

It seems to me 7. is failing for me as well, thus, there might be more to it. (This is both on a Linux 64bit machine)

That might be due to the external app helper dialog not appearing for me for some reason.

comment:3 Changed 22 months ago by cypherpunks

George, I should add I only tested this with security level set to high which enables click-to-play for video. From what I've seen videos _need_ to be blocked for the download to begin, if step 7 failed for you then perhaps you tested with security level set to low?

comment:4 in reply to:  2 Changed 22 months ago by cypherpunks

Replying to gk:

Replying to gk:

It seems to me 7. is failing for me as well, thus, there might be more to it. (This is both on a Linux 64bit machine)

That might be due to the external app helper dialog not appearing for me for some reason.

That's because you haven't reloaded the page after revoking permissions. ;)
And now we have to mention whether it was in e10s mode or not :(
WFM e10s on Win 10. (Stalling is non-e10s issue, according to previous tickets.)

Replying to cypherpunks:
He is Georg ;)

comment:5 Changed 22 months ago by gk

Description: modified (diff)

comment:6 in reply to:  3 Changed 22 months ago by gk

Status: newneeds_information

Replying to cypherpunks:

George, I should add I only tested this with security level set to high which enables click-to-play for video. From what I've seen videos _need_ to be blocked for the download to begin, if step 7 failed for you then perhaps you tested with security level set to low?

Okay, I've tested with a fresh Tor Browser 7.5a1 and I got our external-app-helper warning dialog and allowing the download of the file started it (verified on about:downloads). This worked on any slider setting. So, not sure what is going on in your case. Do you get the external-app-helper warning dialog as well and the download still fails to start? And could you check about:support if Multiprocess Windows are enabled?

comment:7 Changed 22 months ago by cypherpunks

I just tested it a bunch of times, with a fresh tor-browser, and could only get it to fail once, which is embarrassing. I haven't been able to replicate it since. When I made the comment on the blog I could get it to fail consistently.

When it did fail external-app-helper popped up and the file didn't make it into about:downloads, not even as failed download, nor did it appear on the filesystem.

Multiprocess windows are enabled, and for what it's worth, I'm running tor-browser within a vm with a single cpu. If it happens again I'll take a closer look in the browser and the web console... sorry.

comment:8 Changed 22 months ago by cypherpunks

I had few minutes to look at it again, I can get it to fail now. These are the steps I followed in a fresh tor-browser with multiprocess windows enabled:

  1. Set the security level to high.
  2. Open https://ftp.acc.umu.se/pub/debian-meetings/2016/debconf16/
  3. Find 'Long_Term_Support_LTS.webm' and open it in a new tab. Right click on the blocked object and select 'Save Link As...'. Accept the warning and choose where to save it. You can close the tab now.
  4. Open 'about:downloads' and verify that it's downloading.
  5. Find 'Surviving_the_Next_23_Years_of_Free_Software.webm' and open it as well. Right click and select 'Save Link As..', choose where to save it.
  6. If the first file was still downloading the second download shouldn't have commenced.
  7. Cancel the first download and try step 5 again, it should work now.

I then deleted the tor-browser_en-US folder and unpacked the tarball again for a fresh profile. That time I left the security level at low. When I repeated the steps, step 5 didn't display the save as dialog, I clicked a couple of times. I then tried to download it by right clicking on the link at ftp.acc.umu.se instead of right clicking on the blocked object, again nothing showed up. However, when I went to cancel the first download all the dialogs appeared. I can't remember if it was the external-app-helper or the save as dialogs.

Something to note is that I chose both of those files on purpose because they exist in the same server: https://saimei.acc.umu.se/pub/debian-meetings/2016/debconf16/{Long_Term_Support_LTS.webm,Surviving_the_Next_23_Years_of_Free_Software.webm}. When I tried other files that existed in different servers I could download them.

And finally, when a download failed I checked the browser console and I got 'unsafe CPOW usage forbidden' failures. That's as far as I got, good luck!

fix
I had misspelled the address and the failure message.

update
I downloaded 7.5a1 and found the bug there as well. I also went a little further, this time I downloaded the first file and cancelled it, leaving it in about:downloads, then started to download the second file, with that download in progress I tried to download the first file, by clicking the retry button, and it wouldn't work.

I just tested with some gifs located in the same subdomain and that failed. It also displayed the same error message in the browser console. I'm going on a limb and say that this affects any two or more downloads originating from the same subdomain, which could explain why the person that first reported the bug couldn't download some images.

OK, sorry for the spam.

Version 3, edited 22 months ago by cypherpunks (previous) (next) (diff)

comment:9 Changed 21 months ago by gk

Cc: mcs brade added
Status: needs_informationassigned

Just tested this again. And even on the slider level "low" I see the comment:8 behavior. The issue seems to be that the external helper app dialog is not showing up when one download is ongoing. After I cancel that one the dialog for the second shows up immediately. FWIW: I had the patches for #22618 applied.

comment:10 Changed 18 months ago by davidw

I can confirm this problem on Tor 7.0.6 (64bit) on Mac OS 10.11.6 however save as dialog box is working in my case but the second file does not download, or show up at all in about:download even if I cancel the active download. It simply does not download and I can't download any other files from the same server until the first one completes. By the way, the files downloaded are anything, not videos.

Multiprocess windows is enabled. NoScript is set to LOW security with one change. I have "allow scripts globally" set to off. I have not changed this at all since Tor version 5.5 I don't get any warnings about blocked files.

When the save as window pops up, and I hit "save" I get the following error in the browser console:

unsafe CPOW usage forbidden  				contentAreaUtils.js:466
	continueSave 		chrome://global/content/contentAreaUtils.js:466:1
	internalSave/< 		chrome://global/content/contentAreaUtils.js:446:7
	Handler.prototype.process resource://gre/modules/Promise-backend.js:932:23
	this.PromiseWalker.walkerLoop		resource://gre/modules/Promise-backend.js:813:7
	bound  							self-hosted:913:17
	bound bound  						self-hosted:913:17
	this.PromiseWalker.scheduleWalkerLoop/< resource://gre/modules/Promise-backend.js:747:11

The same exact settings were working in Tor 6.x

Last edited 18 months ago by davidw (previous) (diff)

comment:11 Changed 18 months ago by davidw

Cc: dwatson@… added

comment:12 Changed 18 months ago by davidw

Cc: dwatson@… removed

comment:13 Changed 8 months ago by dmr

Cc: dmr added
Note: See TracTickets for help on using tickets.