Selecting "Copy image" from menu leaks the source URL to the clipboard. This data is often dereferenced by other applications.
Right-clicking an image and selecting "Copy image" from the context-menu leaks the source URL to the clipboard. In many applications, pasting the image leads to the URL being dereferenced, and a clearnet web request can result, instead of the bitmap simply being pasted. This is dangerous and unexpected behaviour that stems from Firefox.
11 formats are placed on the clipboard during an image copy. 3 of these contain the URL, 2 of which contain further tag metadata:
49318 'HTML Format' - this contains the entire source HTML of the <img> element, inside a comment, wrapped in a minimal HTML document, and a header containing the offsets
49419 'text/html' - this also contains the source HTML of the <img> element
49426 'application/x-moz-file-promise-url' - this contains the plain source URL.While some might argue that this is appropriate in Firefox, it's an unexpected information leak in the Tor Browser.
My suggestion would be to change the menu items to:
- Copy image
- Copy image location
- Copy image as HTML
Copy image would copy only raw image pixels as an uncompressed bitmap. This ensures there is no metadata in the image, and also ensures that increasingly common things like WebP don't break everything. It also fixes unexpected behaviour with respect to dynamically generated or uncached images, ensuring that what the user sees is exactly what ends up in the clipboard, without any extra web requests in the target application.
Copy image location would copy, in plaintext, the source URL of the image.
Copy image as HTML would copy or create a sanitised version of the 
tag (i.e. onclick handlers etc would be stripped, leaving only alt text, width and height and perhaps eventually a filtered version of any embedded CSS).
I believe each of those menu options would behave as everyone would expect, without any unexpected information leakage issues.
(I have set severity as major and priority high, since this has the potential to deanonymise a user before they realise what's happened, but is probably a relatively easy fix. Presumably this would be regarded as the most important kind of bug, but I don't know the convention here.)
Trac:
Username: peskydan