Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#18169 closed defect (fixed)

Tor Browser 5.5 misses whitelisted zh-CN UI font

Reported by: gk Owned by: arthuredelstein
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Critical Keywords: tbb-fingerprinting-fonts tbb-usability, TorBrowserTeam201601R tbb-5.5-regression
Cc: arthuredelstein Actual Points:
Parent ID: #18097 Points:
Reviewer: Sponsor:

Description

It seems we missed a default UI font for Chinese users. See https://blog.torproject.org/blog/tor-browser-55-released#comment-153757

Child Tickets

Change History (18)

comment:1 Changed 3 years ago by gk

Keywords: tbb-fingerprinting-fonts tbb-usability added

comment:2 Changed 3 years ago by gk

Keywords: TorBrowserTeam201601 added
Owner: changed from tbb-team to arthuredelstein
Status: newassigned

Arthur: Could you please look at this one?

comment:3 Changed 3 years ago by arthuredelstein

I'm working on this now. Does anyone know the localized (Simplified Chinese) font name for "Microsoft YaHei UI"? We are already including the localized font name for "Microsoft YaHei" (which is "微软雅黑").

comment:4 Changed 3 years ago by arthuredelstein

Keywords: TorBrowserTeam201601R added; TorBrowserTeam201601 removed
Status: assignedneeds_review

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.)

It's possible there may be a localized font name for "Microsoft YaHei UI", in which case we could add this as well.

comment:5 in reply to:  4 ; Changed 3 years ago by 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.)

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?

comment:6 in reply to:  5 ; Changed 3 years ago by 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.)

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. 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.

comment:7 in reply to:  6 ; Changed 3 years ago by jason

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.)

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. 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.

comment:8 in reply to:  7 ; Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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).

comment:10 in reply to:  8 ; Changed 3 years ago by arthuredelstein

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.

comment:11 in reply to:  9 ; Changed 3 years ago by jason

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.

comment:12 in reply to:  10 ; Changed 3 years ago by 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?

comment:13 in reply to:  11 Changed 3 years ago by yawning

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.

comment:14 Changed 3 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

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 (tor-browser-38.6.0esr-5.5-1/tor-browser-38.6.0esr-6.0-1)

comment:15 in reply to:  12 Changed 3 years ago by arthuredelstein

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

comment:16 Changed 3 years ago by gk

Keywords: tbb-5.5-regression added

comment:17 Changed 3 years ago by gk

comment:18 in reply to:  17 Changed 3 years ago by bugzilla

Replying to gk:
why do win32's .mar have 54MB? And, please, rename .exe for win32 to tb-win32-.exe

Last edited 3 years ago by bugzilla (previous) (diff)
Note: See TracTickets for help on using tickets.