Opened 3 years ago

Last modified 11 months ago

#16607 needs_information defect

Allow SVG for extensions, even on "high" security level

Reported by: mbauer Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability
Cc: mabahas@…, mcs, brade, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When setting the security level to "high" (in the privacy and security settings), SVG images are blocked everywhere. Even for internal (or addon) pages, there is no possibility to show SVG images, which might prevent some addons from working.

Is it possible to introduce a whitelist of pages/protocols that can use svg?

Good candidates for a whitelist are: "about:*", "chrome://*" and "resource://*".
Actually, the NoScript addon already comes with such a whitelist, which allows javascript for addon pages.

 

For my case, I'm creating an addon (for Tor Browser 5.0+) that uses a library to create graphs on a resource://... page. The library uses an inline svg element ("<svg>...</svg>") to display it's graphics.
Currently, the "high" mode breaks my addon.

Best
Markus

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by mbauer

Cc: mabahas@… added

comment:2 Changed 3 years ago by gk

Cc: mcs brade gk added
Keywords: tbb-usability added; tbb-5.0a removed
Type: enhancementdefect

This should not happen as we only disallow SVG in content. mcs, brade any ideas? Sounds like our old problem to differentiate exactly between content and chrome code.

comment:3 in reply to:  2 Changed 3 years ago by mcs

Status: newneeds_information

Replying to gk:

This should not happen as we only disallow SVG in content. mcs, brade any ideas? Sounds like our old problem to differentiate exactly between content and chrome code.

Agreed. I think a resource:// page will be recognized as content by our SVG blocking code when it is rendered in a browser window. Whitelisting may be risky because web pages can load objects via resource:// URLs. I have not looked at what NoScript does for whitelisting though.

mbauer: Can you make your extension available to us for testing or provide a test case?

comment:4 Changed 3 years ago by mbauer

I created a sample addon, including two resource-pages using inline svg. Installing the addon opens a new tab, that links these pages. Source is attached. https://www.dropbox.com/s/ycj8vva7u3cg5c4/svg-testaddon.zip?dl=0

Actually, you should be aware of issue #16495. It describes a problem that crashes Tor Browser on pages that include svg elements, if the security level is set to high. The first page is small enough to not crash the browser, but the second page will (that's my current graphic). According to #16495, the crash is caused by the svg blocking code.

For the whitelisting idea: Maybe you should apply it to the page that wants to include svg. If a resource:// page includes svg, it's fine, if a http:// page includes svg from an addon resource, it would still be blocked.

comment:5 Changed 3 years ago by mcs

Thank you for the sample add-on. It really just creates content pages, and the SVG blocking code has no way to tell the difference between a page from your add-on and one created by a website.

I am still somewhat uncomfortable with the idea of a whitelist because I fear that it could be used somehow by a web site to cause SVG content to be loaded (which is what we want to avoid). I cannot say exactly how that would happen though.

mbauer: Do you know if there is a way to detect that a resource: page or other page which is loaded in the content area actually belongs to an add-on? I suspect there is no way to detect that, but if there was, using such an approach would be better than implementing a whitelist.

comment:6 Changed 3 years ago by mbauer

I'm sorry, I am not aware of a "clean" solution. Maybe you can check if an appropriate-named extension exists? An url like "resource://a-at-b-dot-com/..." belongs to an extension "a@…" or "a@…".

comment:7 Changed 3 years ago by mcs

As it turns out, this same issue affects about:preferences. See #16775.

comment:8 Changed 12 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:9 Changed 11 months ago by V@…

Is there a hidden setting somewhere that would allow SVG? (for those who willing risk it)

comment:10 Changed 11 months ago by V@…

Oh, yes, there is: svg.in-content.enabled

Note: See TracTickets for help on using tickets.