> 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.)
> 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...)
> This is a good start! I agree, this might be the way to go
But they already are! That's the point that you are missing, for basic stuff, you can use a font that is described with only basic features/ that can have no possible security issues.
> Remember that a font, after all of the font code is processed, must come out of the font renderer as a bitmap.
But go into complex arabic fonts and you start to realize that your .svg (or worse, bitmap) can't be a representation of a "character" but that of a "paragraph". Pre-render that, as a font!
> 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?
That's very, very different. You don't run arbitrary binaries on mission critical servers - nobody does, right? But that doesn't mean that "we should remove the capability of OSes to run arbitrary binaries".
Yes, custom fonts are slightly more safe "client code". All precautions that need to be taken when running client code, need to be taken when rendering custom fonts. Which means that first and foremost, you need to ask yourself "do I need to run custom client code in this mission critical server?". Sometimes you do - but often you don't; and when you don't, by all means, disallow it - it's the safest option.
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.)