Tor Browser 5.5 misses whitelisted zh-CN UI font
It seems we missed a default UI font for Chinese users. See https://blog.torproject.org/blog/tor-browser-55-released#comment-153757
Activity
This branch's second-to-last commit has a fix:
https://github.com/arthuredelstein/tor-browser/commits/18169
(The branch also contains a fix for #18172 (moved).)
It's possible there may be a localized font name for "Microsoft YaHei UI", in which case we could add this as well.
Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201601 deleted, TorBrowserTeam201601R added
Replying to arthuredelstein:
This branch's second-to-last commit has a fix:
https://github.com/arthuredelstein/tor-browser/commits/18169
(The branch also contains a fix for #18172 (moved).)
It's possible there may be a localized font name for "Microsoft YaHei UI", in which case we could add this as well.
But having the not-localized one should be enough to solve the problem, right?
Replying to gk:
Replying to arthuredelstein:
This branch's second-to-last commit has a fix:
https://github.com/arthuredelstein/tor-browser/commits/18169
(The branch also contains a fix for #18172 (moved).)
It's possible there may be a localized font name for "Microsoft YaHei UI", in which case we could add this as well.
But having the not-localized one should be enough to solve the problem, right?
Not necessarily. As I recall, we needed the localized font name to fix #17550 (moved). It's possible that a Simplified Chinese edition of Windows may use the localized name as its primary font name. On the other hand, I couldn't find any evidence of a localized-name version of this font. So I'm hopeful this will be enough to work.
Replying to arthuredelstein:
Replying to gk:
Replying to arthuredelstein:
This branch's second-to-last commit has a fix:
https://github.com/arthuredelstein/tor-browser/commits/18169
(The branch also contains a fix for #18172 (moved).)
It's possible there may be a localized font name for "Microsoft YaHei UI", in which case we could add this as well.
But having the not-localized one should be enough to solve the problem, right?
Not necessarily. As I recall, we needed the localized font name to fix #17550 (moved). It's possible that a Simplified Chinese edition of Windows may use the localized name as its primary font name. On the other hand, I couldn't find any evidence of a localized-name version of this font. So I'm hopeful this will be enough to work.
Microsoft YaHei is 微软雅黑. In the same way, Microsoft YaHei UI should be 微软雅黑 UI, but I can't find the Chinese name in my system.The differences between the two is that (at least) numberic characters and punctuation marks are rendered in different styles.It won't break whole TB UI like yawning mentioned.
Some users say fonts in new version are ugly. If that's a reasonable request, I suggest 微软雅黑 Light and Microsoft YaHei UI Light should be whitelisted.
Trac:
Username: jasonReplying to jason:
Microsoft YaHei is 微软雅黑. In the same way, Microsoft YaHei UI should be 微软雅黑 UI, but I can't find the Chinese name in my system.The differences between the two is that (at least) numberic characters and punctuation marks are rendered in different styles.It won't break whole TB UI like yawning mentioned.
The breaking the whole UI thing is because Firefox queries the OS for what the default font is used to render the UI. If the exact font is not available, Firefox doesn't do the right thing, and the UI is rendered using god knows what, breaking everything.
Firefox does not know that "YaHei" is "YaHei UI", with minor changes, all Firefox knows is the OS says to use "YaHei UI", and "YaHei UI" isn't available.
Some users say fonts in new version are ugly. If that's a reasonable request, I suggest 微软雅黑 Light and Microsoft YaHei UI Light should be whitelisted.
Expanding the whitelist more than necessary increases fingerprinting risk. YaHei and JhengHei are Vista+ and thus are not available on all platforms.
As a side note, all this messing around with the whitelist still feels like a poor solution to something that is ideally addressed by decoupling the font fingerprint defenses from the UI rendering.
Replying to yawning:
Replying to jason:
Microsoft YaHei is 微软雅黑. In the same way, Microsoft YaHei UI should be 微软雅黑 UI, but I can't find the Chinese name in my system.The differences between the two is that (at least) numberic characters and punctuation marks are rendered in different styles.It won't break whole TB UI like yawning mentioned.
The breaking the whole UI thing is because Firefox queries the OS for what the default font is used to render the UI. If the exact font is not available, Firefox doesn't do the right thing, and the UI is rendered using god knows what, breaking everything.
Firefox does not know that "YaHei" is "YaHei UI", with minor changes, all Firefox knows is the OS says to use "YaHei UI", and "YaHei UI" isn't available.
Some users say fonts in new version are ugly. If that's a reasonable request, I suggest 微软雅黑 Light and Microsoft YaHei UI Light should be whitelisted.
Expanding the whitelist more than necessary increases fingerprinting risk. YaHei and JhengHei are Vista+ and thus are not available on all platforms.
As a side note, all this messing around with the whitelist still feels like a poor solution to something that is ideally addressed by decoupling the font fingerprint defenses from the UI rendering.
Agreed. I think the most feasible way to do this decoupling will be when electrolysis is activated, so that we can (hopefully) apply a whitelist only to content. Unfortunately I don't see an easy way to do this before then.
-
Replying to yawning:
As a side note, fixes for this issue are easily tested by users running the appropriate version of the browser on the localized OS by modifying the pref associated with the whitelist (It's how I tested/debugged the ja_JP issue).
Just tested it on zh-CN version of windows 8/10. On windows 10, it seems to me YaHei UI should also be whitelisted besides YaHei, otherwise it will break whole TB UI. But I could not reproduce it on windows 8.
Trac:
Username: jason -
Replying to arthuredelstein:
Replying to yawning:
As a side note, all this messing around with the whitelist still feels like a poor solution to something that is ideally addressed by decoupling the font fingerprint defenses from the UI rendering.
Agreed. I think the most feasible way to do this decoupling will be when electrolysis is activated, so that we can (hopefully) apply a whitelist only to content. Unfortunately I don't see an easy way to do this before then.
Why not in this case given that almost every feature has a way to query whether it is currently executed in a chrome/non-chrome context?
Replying to jason:
Just tested it on zh-CN version of windows 8/10. On windows 10, it seems to me YaHei UI should also be whitelisted besides YaHei, otherwise it will break whole TB UI. But I could not reproduce it on windows 8.
So MS changed the default UI font between Windows 8 and 10. Beyond the extra fingerprinting risks having more fonts in the whitelist doesn't actually hurt, so adding the appropriate UI font seems like a reasonable way to fix this issue for now (With the whitelist getting bloated due to UI fonts being a bit of an orthogonal issue).
I am ACKing arthuredelstein's branch.
-
This is commit d78f5c707b357bc3fe88c1c46a95aae03f27b491 and 0585610798a61273268b99daa490c7630ce09980 for this ticket (tor-browser-38.6.0esr-5.5-1/tor-browser-38.6.0esr-6.0-1) and commit db6d52d44439430de088dbca46ab9bf70bc5e4e4 and 10db8cb3c45ef7290811eac86b5d21deb1fa58c7 for the OS X and Windows fixes for #18172 (moved) (tor-browser-38.6.0esr-5.5-1/tor-browser-38.6.0esr-6.0-1)
Trac:
Resolution: N/A to fixed
Status: needs_review to closed Replying to gk:
Replying to arthuredelstein:
Replying to yawning:
As a side note, all this messing around with the whitelist still feels like a poor solution to something that is ideally addressed by decoupling the font fingerprint defenses from the UI rendering.
Agreed. I think the most feasible way to do this decoupling will be when electrolysis is activated, so that we can (hopefully) apply a whitelist only to content. Unfortunately I don't see an easy way to do this before then.
Why not in this case given that almost every feature has a way to query whether it is currently executed in a chrome/non-chrome context?
The font mechanism is pretty convoluted and messy, and different on each platform. I did find that it is possible to whitelist fonts for all platforms by removing any non-allowed fonts from the shared mFontFamilies object, but I'm not optimistic that there will be a cross-platform solution for allowing fonts in chrome but not in non-chrome. On the other hand, maybe I was too glib, and it may be worth the extra effort even if we need to make a lot of changes to the font code for each platform. I have opened a ticket here: #18205 (moved)
-
FWIW: 5.5.1 bundles are up for testing: https://lists.torproject.org/pipermail/tor-qa/2016-February/000773.html