Bugzilla

I'm copying over two comments from dupe bug 1638585, which include a possible way forward & a motivating use-case (i.e. why users might be affected by this):

(Quoting nyanpasu64 from bug 1638585 comment #5)
> One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Quoting Vincent Lefevre from bug 1638585 comment #6)
> There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:
> - Material Icons
> - Google Material Icons
> - Material Symbols Outlined
> - Material Symbols Rounded
> - Material Symbols Sharp

Vincent also mentioned that "Matching exact names would probably not be sufficient", and suggested a substring-matching approach -- but I think that's probably the best approach for now, since the number of affected fonts is relatively small, and the complexity (and potential for false positives) would be quite higher if we took a substring-matching-based (or regex-based) approach.  Exact string matching has the benefit of being predictable and allowing for users (possibly with the assistance of add-ons) to understand and hand-edit their own allow-list, if needed.

Also: gaming things out, it's worth entertaining a small adversarial concern along the lines of: "Uh oh, now font/site developers might be incentivized to co-opt these font names for completely-unrelated-fonts, to increase the likelihood that the browser will use the site's chosen font despite user preferences."  But I suspect in reality there's no strong motivation for sites to get up to this sort of mischief, since the share of users with this configuration (who they'd be focusing on with this sneakiness) is probably quite small.

I'm copying over two comments from dupe bug 1638585, which include a possible way forward & a motivating use-case (i.e. why users might be affected by this):

(Quoting nyanpasu64 from bug 1638585 comment #5)
> One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Quoting Vincent Lefevre from bug 1638585 comment #6)
> There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:
> - Material Icons
> - Google Material Icons
> - Material Symbols Outlined
> - Material Symbols Rounded
> - Material Symbols Sharp

Vincent also mentioned that "Matching exact names would probably not be sufficient", and suggested a substring-matching approach -- but I think that exact-matching is probably the best approach to start with, since the number of affected fonts is relatively small, and the complexity (and potential for false positives) would be quite higher if we took a substring-matching-based (or regex-based) approach.  Exact string matching has the benefit of being predictable and allowing for users (possibly with the assistance of add-ons) to understand and hand-edit their own allow-list, if needed.

Also: gaming things out, it's worth entertaining a small adversarial concern along the lines of: "Uh oh, now font/site developers might be incentivized to co-opt these font names for completely-unrelated-fonts, to increase the likelihood that the browser will use the site's chosen font despite user preferences."  But I suspect in reality there's no strong motivation for sites to get up to this sort of mischief, since the share of users with this configuration (who they'd be focusing on with this sneakiness) is probably quite small.

I'm copying over two comments from dupe bug 1638585, which include a possible way forward & a motivating use-case (i.e. why users might be affected by this):

(Quoting nyanpasu64 from bug 1638585 comment #5)
> One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Quoting Vincent Lefevre from bug 1638585 comment #6)
> There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:
> - Material Icons
> - Google Material Icons
> - Material Symbols Outlined
> - Material Symbols Rounded
> - Material Symbols Sharp

Vincent also mentioned that "Matching exact names would probably not be sufficient", and suggested a substring-matching approach -- but I think that exact-matching is probably the best approach to start with, since the number of affected fonts is relatively small, and the complexity (and potential for false positives) would be quite higher if we took a substring-matching-based (or regex-based) approach.  Exact string matching has the benefit of being predictable and allowing for users (possibly with the assistance of add-ons) to understand and trivially hand-edit their own allow-list (without needing to understand regex/substring-matching syntax), if needed.

Also: gaming things out, it's worth entertaining a small adversarial concern along the lines of: "Uh oh, now font/site developers might be incentivized to co-opt these font names for completely-unrelated-fonts, to increase the likelihood that the browser will use the site's chosen font despite user preferences."  But I suspect in reality there's no strong motivation for sites to get up to this sort of mischief, since the share of users with this configuration (who they'd be focusing on with this sneakiness) is probably quite small.

I'm copying over two comments from dupe bug 1638585, which include a possible way forward & a motivating use-case (i.e. why users might be affected by this):

(Quoting nyanpasu64 from bug 1638585 comment #5)
> One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Quoting Vincent Lefevre from bug 1638585 comment #6)
> There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:
> - Material Icons
> - Google Material Icons
> - Material Symbols Outlined
> - Material Symbols Rounded
> - Material Symbols Sharp

Vincent also mentioned that "Matching exact names would probably not be sufficient", and suggested a substring-matching approach -- but I think that exact-matching is probably the best approach to start with, since the number of affected fonts is relatively small, and the complexity (and potential for false positives) would be quite higher if we took a substring-matching-based (or regex-based) approach.  Exact string matching has the benefit of being predictable and allowing for users (possibly with the assistance of add-ons) to understand and trivially hand-edit their own allow-list (without needing to understand regex/substring-matching syntax), if needed.

Also: gaming things out, it's worth entertaining a small adversarial concern along the lines of: "Uh oh, now font/site developers might be incentivized to co-opt these icon/symbol font names for completely-unrelated web-fonts, simply to increase the likelihood that the browser will use the site's chosen font despite user preferences."  But I suspect in reality there's no strong motivation for sites to get up to this sort of mischief, since the share of users with this configuration (who they'd be focusing on with this sneakiness) is probably quite small.