Thank you for your feedback. Yes, we believe the main problem resides in the mobile platform, where a password echo is sometimes desired by the user. In the case of Android this can be turned off in settings. But users might still want to use them when the screen is small. WeI think letting this password echoing set to off by default can help a lot, though not completely mitigate the problem. Another case is when apps use their built-in onscreen keyboards because they do not trust other keyboard apps. In this scenario, we agree that it would be easier for app developers to address the issue. (e.g. randomizing the font for each character)
We think the idea of loading multiple glyphs is interesting. However, according to our understanding of the graphic libraries, the glyph caching is often performed by other libraries, (e.g. SKIA on Android). It's unclear if we do this for Freetype, what would be the impact of other libraries that uses Freetype. On Tue, Feb 19, 2019 at 12:50 PM Werner LEMBERG <[email protected]> wrote: > > >> What I could imagine, however, is to add some random fuzz so that > >> the rendering time varies by an additional value N (with N to be > >> set by the library user). I can imagine that this would > >> sufficiently reduce the repeatability, making it much harder to > >> execute the attack as described in your paper. > > > > I don't think that belongs in FreeType. > > Maybe, yes. The suggestion to load the script's Unicode block as a > whole in advance sounds like a good suggestion – for passwords and the > like you only need a single font at a single size, so this should be > manageable. For CJK scripts and the like, the number of available > glyphs probably prevents easy password recognition anyway, I think. > > > Werner > -- Daimeng (Desmond) Wang Department of Computer Science & Engineering University of California, Riverside
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
