5 ms·

A bunch of interesting comments, to be sure. All I know is, the fonts (in ROM) in the original IBM-PC, or the Apple ][, or the C-64, or the Atari 800, or any o

A bunch of interesting comments, to be sure. All I know is, the fonts (in ROM) in the original IBM-PC, or the Apple ][, or the C-64, or the Atari 800, or any other of the 64K computers of the 1980's -- never had a security issue with their (ROM bitmap) fonts. That, and: I challenge all of the naysayers to come up with a better solution than the one I have proposed... Not all font-renderer/language experts, here, are we? Neither am I. That's the whole point. A graphical shrink routine I can easily audit for security holes. A font description language (an entire language mind you!) with lots of nuances -- how is any normal human being (much less rockstar programmer) supposed to audit one of those, with all of its possibilities, for security holes, in a single human lifetime? We've seen some very subtle manipulation of these (evinced by this article), whether intentional or not... A simple graphical shrink routine -- is orders of magnitudes more transparent and auditable than font description languages, or their interpreters... You want a better solution? Come up with one and tell me what it is! I'm listening...

peter_d_sherman 7y ago
Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet... Now the security for the font server becomes the problem of the server its running on, not your local PC... and while the font server runs the risk of compromise, you, by only using pre-rendered bitmaps, should ideally not... Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts?
- core-questions 7y ago
  > Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet... This sounds like: - a latency nightmare - a performance nightmare - a privacy nightmare > Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts? I'm calling Poe's Law on you, friend
  - peter_d_sherman 7y ago
    A latency and performance nightmare... yes, quite possibly. A privacy nightmare? I don't see how (unless you had to register on the font-serving machine and it tracked fonts downloaded -- but is that really privacy invading?) Yes, there would be trade-offs (didn't I say that a couple of times?), but such is the price potentially paid for font renderer security... That is -- get rid of the font renderer software component... Hey, one other idea, while I'm at it... run the font renderer in a virtual machine... that could possibly work too... although given that virtual machines have the same issues with complexity and security bugs, I'm sort of 50/50 about that... Another idea: You could have a completely sandboxed language VM -- (e.g., JVM), and if that language VM is provably secure -- run the font renderer code on it... But again, we've seen JVM security bugs so... I'm going to have to go with either "shrink a big bitmap" or "put the font renderer on an entirely different server and serve exact-sized bitmaps" ideas... Or... use a 64K computer from the 1980's where the glyphs are in ROM... <g>
    - GauntletWizard 7y ago
      Yes, font downloading is privacy invading - You can make a "totally unique" font like "timesoldroman-adfssdg" and then track everyone who's downloaded it, for each webpage you want to track. It's just like any other tracking cookie, except a font.
      - peter_d_sherman 7y ago
        Didn't think about that, but yes, that makes sense...
- rurban 7y ago
  Even better idea: Make the font server a new local CPU with write access to the graphics buffer. But no read access at all. Very expensive idea though.
virgilp 7y ago
> All I know is, the fonts (in ROM) in the original IBM-PC, or the Apple ][, or the C-64, or the Atari 800, or any other of the 64K computers of the 1980's -- never had a security issue with their (ROM bitmap) fonts. Seriously? Do you know of ANY security issue with Arial? The problems come with external fonts, not those built into the system - regardless of their representation. > I'm listening... You do realize that you're proposing "let's strip (useful) functionality". Remove all external media other than punched cards, and you stopped the spread of malware - computer viruses were never a problem back then. But a cure that's worse than the disease is not a solution. > Not all font-renderer/language experts, here, are we? Neither am I. That's the point. A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.)
- peter_d_sherman 7y ago
  > Seriously? Do you know of ANY security issue with Arial? > The problems come with external fonts, not those built > into the system - regardless of their representation. Arial can be described via a font description language. While I may not know of any security problems with some (a tiny subset of a theoretically infinite set) of those font description language definitions of Arial (aka, mini-programs that tell the font renderer how to render Arial), I know that I do not have the ability to security audit the font rendering program that produces that Arial font. I would not have this ability unless I programmed my own font renderer, and even so I might miss things like potential buffer overflows, stack overflows, anomalous behavior, and the like. In short, I could not test for every possibility that a would-be hacker could potentially dream up. It would be similarly difficult for someone else, even a very good programmer, to properly audit for security the code I had written (or anyone else had written for that matter), even if I/they had written it to the best of my ability for it to be secure. >You do realize that you're proposing "let's strip (useful) functionality". Not necessarily... Remember that a font, after all of the font code is processed, must come out of the font renderer as a bitmap. If that bitmap could be produced in some other non-programmatic way, that is, some way without the use of the font renderer, then all security issues having to do with the font renderer would be rendered (pardon my pun!) -- obsolete. In other words, no font renderer, no font renderer security issues. >Remove all external media other than punched cards, and >you stopped the spread of malware - computer viruses were >never a problem back then. But a cure that's worse than >the disease is not a solution. You have to make your own choices. Am I advocating this for everyone? Not at all. You have freedom; you (and everyone else) make your own choices based on that freedom. But for me, if in the future I'm running a server that is mission critical, that has to stay up 24/7, and has to be resistant against hacker (and other party!) attacks, then you can sure as hell bet I'm not going to be running a font renderer on it! Hey, as I said... it's your choice! You can run font renderers, and any number of things you randomly download from the Internet ("Bonzi Buddy" comes to mind) on servers that are mission critical, but would I? I would not... but that's just for me and my future servers... you may have different concerns, and your mileage "may vary" as the old expression goes... >> Not all font-renderer/language experts, here, are we? >> Neither am I. That's the point. > A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.) I meant no disrespect (to you, or any of the font renderer and language experts out there), but you know, sometimes a person may need to challenge groups of experts -- to get them to think even harder. I am sorry, but that is true... If I have offended you or anyone else, then you have my most humble apologies -- but my challenge is not rescinded, because until and unless the security community can prove (I mean prove rigorously, like a mathematical proof) that font renderers are secure, and that problems like the one this HN article is about can and will never happen in the future, until that point in time, my challenge is not rescinded because it is necessary. Humility or not... Also, I'll concede that I like your point: >fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; This is a good start! I agree, this might be the way to go... (this is why I issued my challenge, for points like these...)
DagAgren 7y ago
The challenge here is for YOU to come up with a solution that is better than what is already used, which you have not. You have thrown away all the parts that are hard, and suggest only implementing the part that is easy, in a bad way. That is not a viable replacement. Those hard parts are necessary. You can't just ignore them.
- peter_d_sherman 7y ago
  Your argument is based in functionality. You are willing to trade security for functionality. My argument is based in security. I am willing to trade functionality for security. You are correct, what I have suggested is not a viable replacement, if functionality is desired. But I am also correct, what I have suggested is a viable replacement, if security is desired. Also, I would suggest that the challenge is on YOU - to live with all of the future security and privacy ramifications of the position you take, because by choosing functionality over security, you equal-and-oppositely UNCHOOSE security... You cannot have both, and if you believe you can, if you want to persuade me, then the burden of proof is upon you to rigorously and mathematically prove it. Until then, I remain unconvinced...
  - DagAgren 7y ago
    Nobody is willing to trade this functionality. You are going to just have to take this as a given. People aren't going to stop wanting to use computers in their own language just because you are upset about font rendering. It is just not happening, and there is no point in discussing it.

peter_d_sherman 7y ago

Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet... Now the security for the font server becomes the problem of the server its running on, not your local PC... and while the font server runs the risk of compromise, you, by only using pre-rendered bitmaps, should ideally not... Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts?

core-questions 7y ago
> Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet... This sounds like: - a latency nightmare - a performance nightmare - a privacy nightmare > Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts? I'm calling Poe's Law on you, friend
- peter_d_sherman 7y ago
  A latency and performance nightmare... yes, quite possibly. A privacy nightmare? I don't see how (unless you had to register on the font-serving machine and it tracked fonts downloaded -- but is that really privacy invading?) Yes, there would be trade-offs (didn't I say that a couple of times?), but such is the price potentially paid for font renderer security... That is -- get rid of the font renderer software component... Hey, one other idea, while I'm at it... run the font renderer in a virtual machine... that could possibly work too... although given that virtual machines have the same issues with complexity and security bugs, I'm sort of 50/50 about that... Another idea: You could have a completely sandboxed language VM -- (e.g., JVM), and if that language VM is provably secure -- run the font renderer code on it... But again, we've seen JVM security bugs so... I'm going to have to go with either "shrink a big bitmap" or "put the font renderer on an entirely different server and serve exact-sized bitmaps" ideas... Or... use a 64K computer from the 1980's where the glyphs are in ROM... <g>
  - GauntletWizard 7y ago
    Yes, font downloading is privacy invading - You can make a "totally unique" font like "timesoldroman-adfssdg" and then track everyone who's downloaded it, for each webpage you want to track. It's just like any other tracking cookie, except a font.
    - peter_d_sherman 7y ago
      Didn't think about that, but yes, that makes sense...
rurban 7y ago
Even better idea: Make the font server a new local CPU with write access to the graphics buffer. But no read access at all. Very expensive idea though.

virgilp 7y ago

> All I know is, the fonts (in ROM) in the original IBM-PC, or the Apple ][, or the C-64, or the Atari 800, or any other of the 64K computers of the 1980's -- never had a security issue with their (ROM bitmap) fonts. Seriously? Do you know of ANY security issue with Arial? The problems come with external fonts, not those built into the system - regardless of their representation. > I'm listening... You do realize that you're proposing "let's strip (useful) functionality". Remove all external media other than punched cards, and you stopped the spread of malware - computer viruses were never a problem back then. But a cure that's worse than the disease is not a solution. > Not all font-renderer/language experts, here, are we? Neither am I. That's the point. A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.)

peter_d_sherman 7y ago
> Seriously? Do you know of ANY security issue with Arial? > The problems come with external fonts, not those built > into the system - regardless of their representation. Arial can be described via a font description language. While I may not know of any security problems with some (a tiny subset of a theoretically infinite set) of those font description language definitions of Arial (aka, mini-programs that tell the font renderer how to render Arial), I know that I do not have the ability to security audit the font rendering program that produces that Arial font. I would not have this ability unless I programmed my own font renderer, and even so I might miss things like potential buffer overflows, stack overflows, anomalous behavior, and the like. In short, I could not test for every possibility that a would-be hacker could potentially dream up. It would be similarly difficult for someone else, even a very good programmer, to properly audit for security the code I had written (or anyone else had written for that matter), even if I/they had written it to the best of my ability for it to be secure. >You do realize that you're proposing "let's strip (useful) functionality". Not necessarily... Remember that a font, after all of the font code is processed, must come out of the font renderer as a bitmap. If that bitmap could be produced in some other non-programmatic way, that is, some way without the use of the font renderer, then all security issues having to do with the font renderer would be rendered (pardon my pun!) -- obsolete. In other words, no font renderer, no font renderer security issues. >Remove all external media other than punched cards, and >you stopped the spread of malware - computer viruses were >never a problem back then. But a cure that's worse than >the disease is not a solution. You have to make your own choices. Am I advocating this for everyone? Not at all. You have freedom; you (and everyone else) make your own choices based on that freedom. But for me, if in the future I'm running a server that is mission critical, that has to stay up 24/7, and has to be resistant against hacker (and other party!) attacks, then you can sure as hell bet I'm not going to be running a font renderer on it! Hey, as I said... it's your choice! You can run font renderers, and any number of things you randomly download from the Internet ("Bonzi Buddy" comes to mind) on servers that are mission critical, but would I? I would not... but that's just for me and my future servers... you may have different concerns, and your mileage "may vary" as the old expression goes... >> Not all font-renderer/language experts, here, are we? >> Neither am I. That's the point. > A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.) I meant no disrespect (to you, or any of the font renderer and language experts out there), but you know, sometimes a person may need to challenge groups of experts -- to get them to think even harder. I am sorry, but that is true... If I have offended you or anyone else, then you have my most humble apologies -- but my challenge is not rescinded, because until and unless the security community can prove (I mean prove rigorously, like a mathematical proof) that font renderers are secure, and that problems like the one this HN article is about can and will never happen in the future, until that point in time, my challenge is not rescinded because it is necessary. Humility or not... Also, I'll concede that I like your point: >fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; This is a good start! I agree, this might be the way to go... (this is why I issued my challenge, for points like these...)

DagAgren 7y ago

The challenge here is for YOU to come up with a solution that is better than what is already used, which you have not. You have thrown away all the parts that are hard, and suggest only implementing the part that is easy, in a bad way. That is not a viable replacement. Those hard parts are necessary. You can't just ignore them.

peter_d_sherman 7y ago
Your argument is based in functionality. You are willing to trade security for functionality. My argument is based in security. I am willing to trade functionality for security. You are correct, what I have suggested is not a viable replacement, if functionality is desired. But I am also correct, what I have suggested is a viable replacement, if security is desired. Also, I would suggest that the challenge is on YOU - to live with all of the future security and privacy ramifications of the position you take, because by choosing functionality over security, you equal-and-oppositely UNCHOOSE security... You cannot have both, and if you believe you can, if you want to persuade me, then the burden of proof is upon you to rigorously and mathematically prove it. Until then, I remain unconvinced...
- DagAgren 7y ago
  Nobody is willing to trade this functionality. You are going to just have to take this as a given. People aren't going to stop wanting to use computers in their own language just because you are upset about font rendering. It is just not happening, and there is no point in discussing it.