Favicons loaded via the Page Info dialog are going over the catch-all circuit

Load https://trac.torproject.org and observe that the favicon is getting loaded over the circuit used for all the other resources of trac.torproject.org. Now, open the Page Info dialog and the favicon that gets loaded again goes over the catch-all circuit. I think the expected behavior is to let the request go over the circuit for the URL bar domain of the page in question as well.

added TorBrowserTeam201602R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-linkability type::defect labels

Trac:
Description: Loading https://trac.torproject.org and observe that the favicons are loaded over the circuit used for the all the other resources of trac.torproject.org. Now, open Page Info dialog and the favicon that gets loaded again goes over the catch-all circuit. I think the expected behavior is to let the request go over the circuit for the URL bar domain of the page in question as well.

to

Load https://trac.torproject.org and observe that the favicon is getting loaded over the circuit used for all the other resources of trac.torproject.org. Now, open the Page Info dialog and the favicon that gets loaded again goes over the catch-all circuit. I think the expected behavior is to let the request go over the circuit for the URL bar domain of the page in question as well.

Here's a patch for review:

https://github.com/arthuredelstein/tor-browser/commit/18030

Trac:
Status: new to needs_review
Keywords: tbb-linkability deleted, tbb-linkability. TorBrowserTeam201601R added

Carrying over review tickets.

Trac:
Keywords: tbb-linkability. TorBrowserTeam201601R deleted, tbb-linkability., TorBrowserTeam201602R added

Trac:
Summary: Favicons loaded via the Page Info dialog are not going over the same circuit as the URL bar domain to Favicons loaded via the Page Info dialog are going over the catch-all circuit
Keywords: tbb-linkability. deleted, tbb-linkability added

Looks good to me. mcs/brade could you have a second look?

Trac:
Cc: arthuredelstein to arthuredelstein, mcs, brade

r=brade, r=mcs It would be good if we had some tests to know that this patch doesn't regress prior work. Also, tests would be useful as we move to ESR45. :-)

Replying to brade:

r=brade, r=mcs It would be good if we had some tests to know that this patch doesn't regress prior work. Also, tests would be useful as we move to ESR45. :-)

That's a good reminder. I'll work on that and post something for #16728 (moved).

Applied to tor-browser-38.6.1esr-6.0-1 (222689b3944533ebb97c809b8b6f508975dd45e3) and tor-browser-38.6.1esr-5.5-1 (b9e7d044aa52c8cda48c73616d70324f666fe1e7), thanks.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Did this patch fix it for all media or just images? Because, according to the logs, I see in Tor Browser 5.5.4 that images go through the first-party domain circuit, but other media such as HTML5 <video> and <audio> sources fall into the "catchall" circuit (the first-party domain seems to be "--unknown--").

Ah, I see that someone already reported this: #18703 (moved).

Trac:
Reviewer: N/A to N/A

closed

moved to tpo/applications/tor-browser#18030 (closed)