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

Edit, Review, and Fork icons not rendering in Tor Browser. #97

Open
herbsmn opened this issue Jan 18, 2017 · 13 comments
Open

Edit, Review, and Fork icons not rendering in Tor Browser. #97

herbsmn opened this issue Jan 18, 2017 · 13 comments

Comments

@herbsmn
Copy link

herbsmn commented Jan 18, 2017

The edit, review, and fork icons don't seem to be rendering properly in the current version of the Tor Browser. Here's a screenshot of the bottom of http://fed.wiki.org/view/welcome-visitors

aa

I tried using the "Inspect Element" to get you more logs, but I don't know JS that well and didn't see what the issue was. I got a 404 error on http://fed.wiki.org/images/crosses.png but I'm assuming that's a different picture.

I did see a javascript error that said:
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead
It was in relation to http://fed.wiki.org/js/jquery-migrate-1.1.1.min.js and http://fed.wiki.org/js/jquery-1.9.1.min.js

Also, here's some CSS errors that I saw in the logs:

ff

Please let me know if you'd like me to do any further testing. I don't see anything else worth reporting in the logs, but if you'd like me to screenshot anything specific please let me know.

@herbsmn
Copy link
Author

herbsmn commented Jan 18, 2017

here's two screencaps of when I looked specifically at one of the icons that wasn't working

uu
oo

@herbsmn
Copy link
Author

herbsmn commented Jan 18, 2017

Oh, I should also say that I went to fed.wiki.org using a couple different security settings in Tor Browser. Most everything works in all settings except the super high setting. Not sure if this changed the results of the logs I posted, but this was the security setting i was at when i did the logs:
ll

The issue about not rendering the icons happened at the lowest setting too when I tried it.

@paul90
Copy link
Member

paul90 commented Jan 18, 2017

I suspect this is related with the NoScript plugin that is built into the Tor browser. Problems with displaying some Unicode characters appears to be a fairly old know problem, see https://support.mozilla.org/en-US/questions/1008052

The css look alright, looks as if the Tor Browser, or a plug-in it includes, is configured to be a pedant and raise errors for rules that it should simply be ignored, as it doesn't understand them, and they are there for other browsers.

@herbsmn
Copy link
Author

herbsmn commented Jan 18, 2017

NoScript is installed, but I have it set to allow everything globally, so I'm not exactly sure if NoScript is the issue, unless it does things even when disabled.

How can we work together to solve this problem?

@herbsmn
Copy link
Author

herbsmn commented Jan 18, 2017

Tor Browser really is an up and coming browser. I personally would greatly appreciate it if federated wiki supported it as best as it can.

@paul90
Copy link
Member

paul90 commented Jan 18, 2017

It is probably best to debug this against a more recent version of the software, fed.wiki.org is using the older ruby server and a client version that is about 18 months old.

If you can install the latest version of wiki, and test against that it would be good.

It would also be good to check if those characters are missing from the font the browser is using on your system. I remember that was the case with some ancient versions of windows. It might also be that the browser is ignoring the font suggestion in the stylesheet.

@paul90
Copy link
Member

paul90 commented Jan 18, 2017

Just looked at the Tor Browser, a fresh install on a Windows 10 VM does not present this problem.
screen shot 2017-01-18 at 16 27 45 Tor Browser (6.0.8)
screen shot 2017-01-18 at 16 36 34 Firefox (50.1.0)
You will notice that the font looks quite different, this would indicate that the Tor Browser is selecting a different font to use. Using inspect element on these character shows that Firefox is using Segoe UI Symbol, while the Tor Browser is using MS PGothic. This would suggest that something within the Tor Browser is choosing to handle the symbol font selection differently that the standard version of Firefox. I don't think this is explained by the Tor Browser using an older version of Firefox.

This with the default (low) security level.

@herbsmn
Copy link
Author

herbsmn commented Jan 19, 2017

MS PGothic is copyrighted by Micro$oft, and I believe that this means it can't be used in Linux. https://www.microsoft.com/typography/fonts/font.aspx?FMID=2147

If so, that explains why Tor Browser, when I run it in Linux, is not rendering MS PGothic like it is when you run TB in Windows.

The reason why Tor Browser is acting differently than Mozilla seems to be explained in these recent articles. https://www.deepdotweb.com/2017/01/13/firefox-52-adds-tor-like-font-whitelist-prevent-fingerprinting-os-fonts/ http://www.ghacks.net/2016/12/28/firefox-52-better-font-fingerprinting-protection/

A demo of how font fingerprinting can be used to create a specific fingerprint for your current browser can be found here: https://browserleaks.com/fonts

In order to try to eventually make every Tor Browser user's font fingerprint look the same, the Tor Project seems to have settled on a font whitelisting strategy in 2015: https://bugzilla.mozilla.org/show_bug.cgi?id=1121643

This seems to explain why the fonts rendered differently when you used Firefox 50.1.0 compared to Tor Browser.

It sounds like the Tor Browser devs are still try to determine what fonts to whitelist and what not to due to the fact that emojis and icons aren't rendering properly for some people. They seem to be very picky when choosing what to use, since using certain fonts might give away the operating system someone is using: https://trac.torproject.org/projects/tor/ticket/18172

I used https://arthuredelstein.github.io/tordemos/enumerate-fonts.html to figure out what fonts are currently found when I use Tor Browser + Gnu+Linux. Here's the list:

Arimo
Cousine
Noto Naskh Arabic
Noto Sans Armenian
Noto Sans Bengali
Noto Sans Buginese
Noto Sans Canadian Aboriginal
Noto Sans Cherokee
Noto Sans Devanagari
Noto Sans Ethiopic
Noto Sans Georgian
Noto Sans Gujarati
Noto Sans Gurmukhi
Noto Sans Hebrew
Noto Sans Kannada
Noto Sans Khmer
Noto Sans Lao
Noto Sans Malayalam
Noto Sans Mongolian
Noto Sans Myanmar
Noto Sans Oriya
Noto Sans Sinhala
Noto Sans Tamil
Noto Sans Telugu
Noto Sans Thaana
Noto Sans Thai
Noto Sans Tibetan
Noto Sans Yi
Noto Serif Armenian
Noto Serif Khmer
Noto Serif Lao
Noto Serif Thai
STIX Math
Tinos

I'm assuming that if you go to that page with your Tor Browser, you might find something like this: https://trac.torproject.org/projects/tor/ticket/17785#comment:6

@herbsmn
Copy link
Author

herbsmn commented Jan 19, 2017

When Mozilla Firefox 52 is released in early March, it will half way impliment Tor Browser's font.system.whitelist code. https://bugzilla.mozilla.org/show_bug.cgi?id=1121643

It will include an optional parameter that you can configure to restrict font access.

Instead of returning all fonts installed on the OS, Firefox will only return the fonts that you have whitelisted.

So, it won't have any predefined list of fonts, let alone an exact copy of Tor Browser's whitelisted fonts. Nonetheless, I see this as a first step by Mozilla towards a collaboration with Tor Browser to impliment a unified font.system.whitelist list in the not too distant future. Even if that is not the case, I would assume that a number of Mozilla users that have security backgrounds might start using this new feature with Tor Browser's specific list in order to attempt to reduce the impact of font fingerprinting.

This Mozilla feature can be currently tested by getting the pre-alpha firefox 52 and following these steps:

  1. Type about:config in the browser's address bar and hit the Enter-key afterwards.
    
  2. Confirm that you will be careful if the warning prompt is displayed.
    
  3. Right-click in the main pane listing all preferences, and select New > String from the context menu.
    
  4. Name the new parameter font.system.whitelist.
    
  5. Now add fonts to the whitelist separated by comma: Helvetica, Courier, Verdana is a valid value for instance.
    

The change takes effect immediately. You may notice that fonts change in the browser UI or on websites as a response.

@herbsmn
Copy link
Author

herbsmn commented Jan 19, 2017

Ok, sorry for all the posts, but after everything I've read, I'm concluding that this is a bug that hasn't been reported to the Tor Browser yet and isn't a Fed Wiki problem, so this ticket can be closed. I posted in the nearly year old "Emoji support is broken in Tor Browser 5.5" issue asking if any progress has been made and whether I should create a seperate ticket for Unicode Characters being broken in TB. https://trac.torproject.org/projects/tor/ticket/18172#comment:25

@herbsmn herbsmn closed this as completed Jan 19, 2017
@herbsmn
Copy link
Author

herbsmn commented Jan 19, 2017

For anyone interested in this closed ticket, the rest of my problem shooting about it will likely be over here: https://trac.torproject.org/projects/tor/ticket/20842#no5

This has been a lot of work so far trying to figure out how to get a black flag, an X, and pencil. Haha.

@herbsmn herbsmn reopened this Jul 18, 2022
@herbsmn
Copy link
Author

herbsmn commented Jul 18, 2022

This issue has never been fixed. The issue still exists for the GNU+Linux version of Tor Browser, so I decided to reopen this ticket in case fedwiki is interested in changing how it shows these icons so that it will work with this browser.

@paul90
Copy link
Member

paul90 commented Jul 23, 2022

Very probably related to Tor Browser in Gnu+Linux doesn't support Dingbats properly.

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

No branches or pull requests

2 participants