Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVGs are disabled with Tor Browser high security; replace with PNGs #1574

Closed
heartsucker opened this issue Feb 10, 2017 · 11 comments
Closed

Comments

@heartsucker
Copy link
Contributor

@micahflee reported that SVGs are disabled by the high security setting in Tor Browser here #1480 (comment).

Possible solutions would be to either a) have a fall back to PNG or b) ditch the SVGs entirely and only use PNGs (or some other format).

@b-meson
Copy link
Contributor

b-meson commented Feb 10, 2017

are there a lot of SVGs? This should be low-hanging fruit unless I messed up my basic linux commands...

:securedrop b_meson$ find . -name '*.svg' 
./docs/diagrams/SecureDrop.svg

@redshiftzero
Copy link
Contributor

FYI this is done in #1567 targeted for the next release

@heartsucker
Copy link
Contributor Author

As of commit b83f219:

./docs/diagrams/SecureDrop.svg
./securedrop/static/i/svg/hand_with_fingerprint.svg
./securedrop/static/i/svg/success_checkmark.svg
./securedrop/static/i/font-awesome/white/comments.svg
./securedrop/static/i/font-awesome/white/times.svg
./securedrop/static/i/font-awesome/white/refresh.svg
./securedrop/static/i/font-awesome/white/cloud-upload.svg
./securedrop/static/i/font-awesome/white/arrow-circle-o-right.svg
./securedrop/static/i/font-awesome/black/info-circle.svg
./securedrop/static/i/font-awesome/black/times.svg
./securedrop/static/i/font-awesome/black/lock.svg
./securedrop/static/i/font-awesome/black/info.svg
./securedrop/static/i/font-awesome/black/trash.svg
./securedrop/static/i/font-awesome/black/cloud-upload.svg
./securedrop/static/i/font-awesome/black/exclamation-triangle.svg
./securedrop/static/i/relieved_face.svg
./securedrop/static/fonts/fontawesome-webfont.svg
./securedrop/source_templates/svg/server_upload.svg

@heartsucker
Copy link
Contributor Author

@redshiftzero Your PR doesn't include the new ones for the 0.4 release.

./securedrop/static/i/svg/hand_with_fingerprint.svg
./securedrop/static/i/svg/success_checkmark.svg
./securedrop/static/i/relieved_face.svg
./securedrop/source_templates/svg/server_upload.svg

@ninavizz
Copy link
Member

Gang: I've created SVG code files that relieve our dependence on font-awesome everything. @micahflee is TOR unable to still read/parse images directly in the code—wholly independent of font-awesome?

@conorsch
Copy link
Contributor

Your PR doesn't include the new ones for the 0.4 release.

That's true, and intended, since #1567 is targeting the 0.3.11 release. We're simply trying to update the Source Interface to display instructions clearly, given new versions of Tor Browser, and also to ensure that the icons render correctly.

Leaving this issue open as a reminder to close the gap on the remaining SVG -> PNG elements.

@ninavizz
Copy link
Member

ninavizz commented Feb 10, 2017

@conorsch I've spec'd SVG code (like, hard-coding the SVG into the html, no font-awesome anything) for 0.4. Can these also work in 0.3.11... or must they all REALLY be .png files? I'd truly just prefer to ditch the button icons all together, since they add between little to no value (which I realize is harsh, but it's honest!) /cc @micahflee

Below is an example of the "drive" icon for the upload page (i'll create the other icons once my viability question is clarified):
Color: #626161
Sizing: Match proportionally to other elements as shown in wireframe? :)
<svg xmlns="http://www.w3.org/2000/svg" width="73" height="62" viewBox="0 0 73 61.8"><style>.a{fill:#6F7173;}</style><path d="M47.6 8.6c0 3.7-9.4 6.7-21 6.7 -11.6 0-21-3-21-6.7 0-3.7 9.4-6.7 21-6.7C38.2 2 47.6 4.9 47.6 8.6" class="a"/><path d="M47.8 18.1c0 3.7-9.5 6.7-21.1 6.7 -11.7 0-21.1-3-21.1-6.7l0.1-5.6c2.5 2.8 11 4.9 21 4.9 10.1 0 18.6-2.1 21.1-5L47.8 18.1z" class="a"/><path d="M30.7 34.4c-1.2 0.1-2.5 0.1-3.8 0.1 -11.7 0-21.1-3-21.1-6.7l0.1-5.6c2.5 2.8 11 4.9 21 4.9 3.5 0 6.8-0.2 9.7-0.7C34 28.5 31.9 31.3 30.7 34.4z" class="a"/><path d="M29.3 43.9c-0.8 0-1.6 0-2.5 0 -11.7 0-21.1-3-21.1-6.7l0.1-5.6c2.5 2.8 11 4.9 21 4.9 1.1 0 2.1 0 3.1-0.1 -0.5 1.8-0.8 3.6-0.8 5.5C29.2 42.6 29.3 43.2 29.3 43.9z" class="a"/><path d="M49.2 23.9c-9.9 0-17.9 8-17.9 17.9s8 17.9 17.9 17.9c9.9 0 17.9-8 17.9-17.9S59.1 23.9 49.2 23.9zM49.2 30.4c0.7-0.7 1.4 0.1 1.4 0.1s8.1 8.2 9.2 9.3c1.6 1.5-0.2 1.9-0.2 1.9h-6v10.5h-7.5v-10.6h-5.9c-1.3 0-0.4-1.7-0.4-1.7L49.2 30.4" class="a"/></svg>

@garrettr
Copy link
Contributor

@ninavizz When the Tor Browser Security Slider is set to High, the SVG parser is disabled entirely. SVGs will not work at all. See https://trac.torproject.org/projects/tor/ticket/12827. This was done to mitigate concerns about security vulnerabilities in the SVG parser, including one that was used in the wild to deanonymize Tor users: https://blog.mozilla.org/security/2016/11/30/fixing-an-svg-animation-vulnerability/.

@ninavizz
Copy link
Member

Ugh. That SUCKS!!! Thank you much @garrettr, for the clarification & background on that. :)

I'll get cracking on some PNG files, then. :/

@psivesely
Copy link
Contributor

This has been fixed for the SI, but not the JI. We might not fix it for the JI and instead resolve the issue via the RR client.

@eloquence
Copy link
Member

The Journalist Interface does not use SVGs anymore either. It does use FontAwesome glyphs, which are also disabled in "Safest". We should track this separately given the long and confusing history of this issue.

There are currently some SVGs in the repo which are not used anywhere. They do come in handy for re-generating PNGs if/when needed, so we may want to keep them around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants