So, your answer would be to get rid of all browser plugins, period?
Now why would I point to Internet Explorer specifically if I were proposing getting rid of all browser plugins?
Think it through, do a bit of research, and try and figure out what it is about ActiveX that makes it so much more dangerous than Java, Flash, Quicktime, or other plugins that don't include a malware-empowerment API as an integral part of the design. Hint: fixing a buffer overflow doesn't break working APIs.
load the browser into a jailed process which sandboxes the entire browser
That would keep malware from trashing the p0rn collection on your hard disk, but it wouldn't do anything to keep the malware from taking part in a zombie network or forwarding your credit card info, bank account and paypal passwords, and other personal information through the zombie network to the attacker.
Once the browser's compromised, the attacker has won half the prizes on the table. Keeping them from making a clean sweep of it is a good thing, but it's no replacement for getting rid of inherently infixable and insecure APIs.
"I think patents, trademarks and copyrights are simply fantastic and a primary, necessary driver of the world economy."
Yep, they sure are. Don't forget contracts, licenses, and trade secrets. They're all useful tools... open source developers use them too, you know.
The problem comes when you start using the wrong tools for the job. For example, the fact that software can be copyrighted doesn't mean that software should be patentable. The fact that music can be copyrighted doesn't mean it should be licensed in copy-protected form.
You start a software project by writing software. Oh, maybe not at once, or maybe you write a prototype first, but until there's software... it's pointless to talk about how it's going to be licensed.
An old fellow is talking to his grand-daughter as he works in the garden, and he keeps talking about he manure he's spreading on the flowerbeds. The bothers the girl's mother and she asks her husband "I hope your father washes his hands before he comes in... and why can't he call it 'fertilizer' like polite folks"? He replies, "honey, it took us 30 years to get him to call it 'manure'".
Look, folks, you got people to quit calling it "Copy Protection" because people got tired of the smell. Now it seems like it smells just as bad when you call it "Digital Rights Management". Calling it empowered this or enabled that isn't going to make it smell any better.
UAC is completely unrelated to sudo. It's an extension of the proxy privileged service scheme they've been using all along. It's not a bad model... it's much like what SafeTcl slave interpreters use... but it shouldn't be confused with "su", "setuid", or "sudo" in UNIX.
2. What they did wrong
Security is like sex, once you're penetrated you're ****ed. UAC, reduced privilege mode to run IE in, all the extra dialogs and warnings and security centers of the last ten years, they're all attempts to reduce the damage or pass the blame for the penetration on to the user. The solution is not to add more layers of annoying mitigation after IE, Outlook, and other applications that use the HTML control are inevitably penetrated. The solution is to redesign the HTML control so that it doesn't provide a security penetration API (the way ActiveX works in IE, that's what it comes down to) in the first place.
Instead, they present Silverlight, based on.NET, complete with its own security penetration API.:p
"Don't you mean I?" "No, No, there willl be 9 episodes. I just started in the middle."
Episode V - The Empire Strikes Back Episode VI - The Revenge of the Jedi
"No, no, no - Jedi care not for revenge"
Episode VI - The Return of the Jedi
(insert above dialog from Bloom County here)
"Bother, this is getting like work. I'm done."
(many years of "No, no, say it ain't so, George!" from T3H FAANS)
Not An Episode Honest - A Star Wars Christmas
(1998 passes)
Episode I - The Phantom Menace
"Hey, check out the cool special effects."
(T3H FAANS boggle)
"George! You said you had 9 episodes written. What is this shit? You gotta be making this up as you go along."
"No, Really, this is T3H GUUD STUFFS! I gots M4D SKR1PT SK1LLZ!"
Episode II - Attack of the Clones
"What the hell?"
"Hey, check it out, here's that revenge thing."
Episode III - The Revenge of the Sith
"NOOOOOOOOOOOOOOOOOOO...."
"OK, crybabies. It's over, I'm not going to put up with your whining. No more Star Wars movies."
(T3H FAANS breathe a sigh of relief)
"Well, two more. Made for TV."
(You are here)
Where do we go from here. One possibility:
Episode VII - A Star Wars Christmas?
(Aha! Maybe thats the missing episode! He'll re-issue it with ne special effects and it into the continuity!)
Episode VIII - A Jedi Nightmare?
(Before Christmas, that is. The Sith attack Pumpkin Town!)
Episode IX - The Great Gungan?
(Jar Jar Binks must solve the mystery of the missing halloween candy, guest appearance by C'Harli B'Rwn and LUSI-522, music by a computer reconstruction of Vince Guaraldi)
Big test floor, where several large (multi-million dollar) computer systems are being configured and tested before shipment to the customer.
Tall skinny hyperactive developer (no, not me, I was just an observor) leaning against the wall of the test floor, actually *fiddling with* the Big Red Button.
Someone suggests that he ought not do that. He promises to be careful.
Act Two
Five minutes later. All the power has just gone out. It's amazing how quiet it is all of a sudden. Everyone is looking over at the tall skinny developer with his hand on the Big Red Button.
No words are spoken.
Act Three
Half an hour later. Electrician is leading the tall skinny developer around as he turns on each part of the power system in the right order. CEO and various unmollified developers watching. Back by the door, guy from facilities is bolting a flap over the Big Red Button.
I don't see anything in the reiew draft or FAQ about voter-confirmable human-readable records (paper ballots, tapes, or other human-readable media). If there is a printed human-countable ballot that the voter can visually confirm was correct and saved then the possibility of electronic fraud is minimized.
My old Nokia "brick" phone did "just make phone calls" at least as well as anything and better than most of the phones I've used since. I can't imagine what the iPhone could possibly do that would "just make phone calls" significantly better than that.
For $600, it better have psychic dialling. Thet can lose the screen completely... I should be able to yank it out, say "get me paul", and have it know (a) whether I want my brother in law, my son's best friend, or any of three or four other "paul"s in my address book, (b) know what phone number that's most likely to get them right then, (c) handle wrong numbers and their holiday schedule automatically, and (d) do all this without me or any of the "paul"s involved having to mess around with some kind of website, services, or other geek interfaces.
You know, like on Star Trek.
I can't think of ANYTHING it could do with anything less than Federation technology that's going to improve "just make phone calls" enough to justify the price.
There's lots of things that could be implemented that woudl save more resources than having everyone with a regular car replcing it with a hybrid... even if the cost of making the hybrid was the same. Improved public transport that's posh enough to attract yuppies. Telecommuting and other distributed workplace models. Cooperative commuting schemes like carpools. Building better cities and suburbs to reduce the need for commuting. And you know what... you can do all of these things *and* use higher efficiency engines!
In any case, you can always use a guaranteed unused code and use a lookup table on input and output.
Until you run out of such codes, anyway.
You have planes 15 and 16 available. If you have a *single* object that is using more than 131072 unique combinations of composing characters I'll be impressed, and you might even have to start using the as-yet-unused 12 bits of UCS-4.
Converting between precomposed and decomposed characters requires large equivalence tables which are going to change depending on what version of unicode you're targeting.
If Unicode is so broken, then...
I'm not sure, but as soon as you decide that you're only going to support some unicode because parts of it are too hard, you suddenly put yourself in a position to be incompatible with some incoming text, and presumably the reason you're using unicode in the first place is to avoid all of that.
It would seem inevitable that you're going to be incompatible with some incoming text no matter what.
I see this as not supporting some Unicode because parts of it are too stupid.
My objection is that he's saying "use UCS-2, it solves the problem" when UCS-2 doesn't solve the problem and it creates new ones.
What he should have said is "use a wide character library that supports Unicode-2, no matter what it uses internally, and make sure your code still works if they change the encoding behind your back".
I don't know why you're going on about "I have a tough time accepting the premise that the British Commonwealth was well served by ASCII". I didn't say that anyone was well served by ASCII.
First, you need to be religious about it. But if you are, then the choice of internal encoding is really a performance issue only, and the choice of external encoding is a matter of following the principle of least astonishment. Your code shouldn't know nor care what encoding the string APIs use internally. The program should work the same whether wchar_t is (unsigned char), (unsigned short), (unsigned long), or even (double).
Second, there's a lot of overhead in canned string code. Depending on the problem space that may be OK. For short strings or simple operations, or where there's significant per-token overhead otherwise, the overhead of dipping into the API for each character isn't significant. When performance matters, though, even inlined code can slow the critical path in the program down orders of magnitude. Getting decent performance requires a parser be character-set aware.
So the advice should be:
1. "Use a canned string handling library that's unicode-aware". That means using at least the ISO C wide character libraries and NOT depending on implementation details like whether they're UCS-2 or UTF-16 or UCS-4 or UTF-8 or for god's sake UTF-1 internally. 2. "Only export data in UTF-8". 3. "When performance matters, figure out what's most efficient for your problem space, and use that." And if you're not sure, performance probably doesn't matter as much as you think it does. And don't forget that cache matters and branches cost dozens of instructions.
Why can't you maintain characters in composed form internally? You would only need to convert when importing an external format, and you should be using UTF-8 for that since UCS-2 and UCS-4 have byte-order dependencies.
Will you have me believe [that] if the RIAA hadn't gone on a massive lawsuit campaign, no one would want free music?
Maybe, maybe not, but it certainly promoted the mp3 explosion and turned a grubby fringe business (yes, business: Napster, Kazaa, pretty much all the early P2P music apps I can think of were closed-source commercial packages) into an edgy and exciting Robin-Hood open-source movement.
I was just about to point out that the GPL is not isomorphic to open source software but I decided to check first.
It seems that OpenAFS support might have to be pulled from Linux because of a change to a header.
The GPL keeps people from using FOSS.
See, the big problem is that the GPL is an attempt to use copyright law against itself, in a kind of legal ju-jitsu. That's its primary goal, and supporting the spread of liberally copyrighted software (to avoid the free/open debate) is secondary. So you can support copyright and oppose open source, support copyright and support open source, oppose copyright and support open source, and even oppose copyright and oppose open source.
Say what? You can oppose copyright and oppose open source?
Sure. Microsoft's done that for years, and their open source efforts have been kind of passive-aggressive...
Microsoft and many other people who are yelling the strongest about copyright violations are the folks who want to replace copyright law with contract law. They only use copyright to force people into operating on a contract basis, and pushed through the DMCA with its explicit clauses to make copyrights subservient to contracts. Copyright law grants rights to the user as well as the creator, and so anyone who licenses software under an "end user license agreement" that restricts those rights is just as opposed to copyrights as the most rabid GPL worshipper.
UCS-2 only covers plane zero (the Basic Multilingual Plane, or BMP). It doesn't cover code points outside that. Unicode actually supports the entire UCS, all 1.1 million (and growing) code points.
In other words, Joel has made the same mistake as the people who wrote software that only works in 7-bit ASCII or 8-bit UTF-8 or the IBM or Apple or Adobe 8-bit extended ASCII sets or the 9-bit extended ASCII set that ITS used, or...
And it's already too late to try and cram everything into 2 bytes. After the Han Unification mess (the attempt to force Chinese and Japanese and everything else that used some variant of Chinese ideograms (Kanji, etc...) into a common subset of similar characters that fit in the 65535 available codes in the BMP) the People Republic of China decided to require their computers to support their national encoding anyway. As of 2000.
So you have to support the full UCS encoding anyway.
There's three storage formats that it's practical to use: UCS-4 (4 bytes per character, with the same byte-ordering problems as UCS-2), UTF-16 (2-4 bytes per character, same as UCS-2 for the BMP) or UTF-8 (1-4 bytes per character). Internally: you can use UCS-4 as your wide character type, and translate on the fly; use UTF-8 and use care to avoid breaking strings in the middle of glyphs or use UTF-16 and translate on the fly and use care to avoid breaking strings in the middle of glyphs.
If Joel is lucky the libraries he's using are actually operating on UTF-16 strings instead of UCS-2 strings. If he's *really* lucky they're designed to avoid breaking up codes outside the BMP. If he's *super* lucky he's managed to avoid creating any code that just operates on strings as a stream of wchar_t anywhere.
Personally, I think that UTF-16 gets you the worst of both worlds: your data is almost certainly less compact than if you use UTF-8; you still have to deal with multi-wchar_t strings so your code is no easier to write than if you used UTF-8... you're just less likely to find bugs in testing; and you get byte order issues in files just like you would with UCS-4. Unless you think UCS-2 is "good enough" and you just ignore everything outside the BMP and discover that people in China are suddenly getting hash when they use your program.
I would say "always" but nobody's *always* anything... but often enough I can't pull up a specific example of a Joel On Software article that's not off the top of my head.:)
Slashdot Mirror
So, your answer would be to get rid of all browser plugins, period?
Now why would I point to Internet Explorer specifically if I were proposing getting rid of all browser plugins?
Think it through, do a bit of research, and try and figure out what it is about ActiveX that makes it so much more dangerous than Java, Flash, Quicktime, or other plugins that don't include a malware-empowerment API as an integral part of the design. Hint: fixing a buffer overflow doesn't break working APIs.
load the browser into a jailed process which sandboxes the entire browser
That would keep malware from trashing the p0rn collection on your hard disk, but it wouldn't do anything to keep the malware from taking part in a zombie network or forwarding your credit card info, bank account and paypal passwords, and other personal information through the zombie network to the attacker.
Once the browser's compromised, the attacker has won half the prizes on the table. Keeping them from making a clean sweep of it is a good thing, but it's no replacement for getting rid of inherently infixable and insecure APIs.
All those straw men are a definite fire hazard!
"I think patents, trademarks and copyrights are simply fantastic and a primary, necessary driver of the world economy."
Yep, they sure are. Don't forget contracts, licenses, and trade secrets. They're all useful tools... open source developers use them too, you know.
The problem comes when you start using the wrong tools for the job. For example, the fact that software can be copyrighted doesn't mean that software should be patentable. The fact that music can be copyrighted doesn't mean it should be licensed in copy-protected form.
You start a software project by writing software. Oh, maybe not at once, or maybe you write a prototype first, but until there's software... it's pointless to talk about how it's going to be licensed.
An old fellow is talking to his grand-daughter as he works in the garden, and he keeps talking about he manure he's spreading on the flowerbeds. The bothers the girl's mother and she asks her husband "I hope your father washes his hands before he comes in... and why can't he call it 'fertilizer' like polite folks"? He replies, "honey, it took us 30 years to get him to call it 'manure'".
Look, folks, you got people to quit calling it "Copy Protection" because people got tired of the smell. Now it seems like it smells just as bad when you call it "Digital Rights Management". Calling it empowered this or enabled that isn't going to make it smell any better.
1. UAC is not SUDO
.NET, complete with its own security penetration API. :p
UAC is completely unrelated to sudo. It's an extension of the proxy privileged service scheme they've been using all along. It's not a bad model... it's much like what SafeTcl slave interpreters use... but it shouldn't be confused with "su", "setuid", or "sudo" in UNIX.
2. What they did wrong
Security is like sex, once you're penetrated you're ****ed. UAC, reduced privilege mode to run IE in, all the extra dialogs and warnings and security centers of the last ten years, they're all attempts to reduce the damage or pass the blame for the penetration on to the user. The solution is not to add more layers of annoying mitigation after IE, Outlook, and other applications that use the HTML control are inevitably penetrated. The solution is to redesign the HTML control so that it doesn't provide a security penetration API (the way ActiveX works in IE, that's what it comes down to) in the first place.
Instead, they present Silverlight, based on
Where do we go from here. One possibility:
Episode VII - A Star Wars Christmas?
(Aha! Maybe thats the missing episode! He'll re-issue it with ne special effects and it into the continuity!)
Episode VIII - A Jedi Nightmare?
(Before Christmas, that is. The Sith attack Pumpkin Town!)
Episode IX - The Great Gungan?
(Jar Jar Binks must solve the mystery of the missing halloween candy, guest appearance by C'Harli B'Rwn and LUSI-522, music by a computer reconstruction of Vince Guaraldi)
Act One
Big test floor, where several large (multi-million dollar) computer systems are being configured and tested before shipment to the customer.
Tall skinny hyperactive developer (no, not me, I was just an observor) leaning against the wall of the test floor, actually *fiddling with* the Big Red Button.
Someone suggests that he ought not do that. He promises to be careful.
Act Two
Five minutes later. All the power has just gone out. It's amazing how quiet it is all of a sudden. Everyone is looking over at the tall skinny developer with his hand on the Big Red Button.
No words are spoken.
Act Three
Half an hour later. Electrician is leading the tall skinny developer around as he turns on each part of the power system in the right order. CEO and various unmollified developers watching. Back by the door, guy from facilities is bolting a flap over the Big Red Button.
Optimist.
I don't see anything in the reiew draft or FAQ about voter-confirmable human-readable records (paper ballots, tapes, or other human-readable media). If there is a printed human-countable ballot that the voter can visually confirm was correct and saved then the possibility of electronic fraud is minimized.
My old Nokia "brick" phone did "just make phone calls" at least as well as anything and better than most of the phones I've used since. I can't imagine what the iPhone could possibly do that would "just make phone calls" significantly better than that.
For $600, it better have psychic dialling. Thet can lose the screen completely... I should be able to yank it out, say "get me paul", and have it know (a) whether I want my brother in law, my son's best friend, or any of three or four other "paul"s in my address book, (b) know what phone number that's most likely to get them right then, (c) handle wrong numbers and their holiday schedule automatically, and (d) do all this without me or any of the "paul"s involved having to mess around with some kind of website, services, or other geek interfaces.
You know, like on Star Trek.
I can't think of ANYTHING it could do with anything less than Federation technology that's going to improve "just make phone calls" enough to justify the price.
So what happens if we just remove the ceiling?
Your computer gets stolen and your paperwork gets wet.
There's lots of things that could be implemented that woudl save more resources than having everyone with a regular car replcing it with a hybrid... even if the cost of making the hybrid was the same. Improved public transport that's posh enough to attract yuppies. Telecommuting and other distributed workplace models. Cooperative commuting schemes like carpools. Building better cities and suburbs to reduce the need for commuting. And you know what... you can do all of these things *and* use higher efficiency engines!
Who came up with this cockamamie headline?
How do you jusdge the value of advertising anywhere? You look at how it effects sales.
In any case, you can always use a guaranteed unused code and use a lookup table on input and output.
Until you run out of such codes, anyway.
You have planes 15 and 16 available. If you have a *single* object that is using more than 131072 unique combinations of composing characters I'll be impressed, and you might even have to start using the as-yet-unused 12 bits of UCS-4.
Converting between precomposed and decomposed characters requires large equivalence tables which are going to change depending on what version of unicode you're targeting.
If Unicode is so broken, then...
I'm not sure, but as soon as you decide that you're only going to support some unicode because parts of it are too hard, you suddenly put yourself in a position to be incompatible with some incoming text, and presumably the reason you're using unicode in the first place is to avoid all of that.
It would seem inevitable that you're going to be incompatible with some incoming text no matter what.
I see this as not supporting some Unicode because parts of it are too stupid.
Not to mention that if you did this, you suddenly need a whole bunch of code to take all incoming text and fix it up so that everything is precomposed
That's no different from "you need a bunch of code to take the incoming text and convert it to UCS-2 (or UTF-8, or UTF-16, or UCS-4)".
it's possible to create legal combinations which have no single unichar replacement.
Are they meaningful as well as legal, or ar they like the "n with an umlaut" in "Spinal Tap"?
I'm of the opinion that there should be *no* precomposed characters, or they should *all* be precomposed.
In any case, you can always use a guaranteed unused code and use a lookup table on input and output.
My objection is that he's saying "use UCS-2, it solves the problem" when UCS-2 doesn't solve the problem and it creates new ones.
What he should have said is "use a wide character library that supports Unicode-2, no matter what it uses internally, and make sure your code still works if they change the encoding behind your back".
I don't know why you're going on about "I have a tough time accepting the premise that the British Commonwealth was well served by ASCII". I didn't say that anyone was well served by ASCII.
I was with you right up to "then return the CD for ~1/2 of what I payed".
If you're going to break the law anyway, why not save $.50 to $1.00 and borrow the CD or download it from P2pServiceOfYourChoiceSter?
Assuming he's ONLY using Windows string APIs.
First, you need to be religious about it. But if you are, then the choice of internal encoding is really a performance issue only, and the choice of external encoding is a matter of following the principle of least astonishment. Your code shouldn't know nor care what encoding the string APIs use internally. The program should work the same whether wchar_t is (unsigned char), (unsigned short), (unsigned long), or even (double).
Second, there's a lot of overhead in canned string code. Depending on the problem space that may be OK. For short strings or simple operations, or where there's significant per-token overhead otherwise, the overhead of dipping into the API for each character isn't significant. When performance matters, though, even inlined code can slow the critical path in the program down orders of magnitude. Getting decent performance requires a parser be character-set aware.
So the advice should be:
1. "Use a canned string handling library that's unicode-aware". That means using at least the ISO C wide character libraries and NOT depending on implementation details like whether they're UCS-2 or UTF-16 or UCS-4 or UTF-8 or for god's sake UTF-1 internally.
2. "Only export data in UTF-8".
3. "When performance matters, figure out what's most efficient for your problem space, and use that." And if you're not sure, performance probably doesn't matter as much as you think it does. And don't forget that cache matters and branches cost dozens of instructions.
Why can't you maintain characters in composed form internally? You would only need to convert when importing an external format, and you should be using UTF-8 for that since UCS-2 and UCS-4 have byte-order dependencies.
Will you have me believe [that] if the RIAA hadn't gone on a massive lawsuit campaign, no one would want free music?
Maybe, maybe not, but it certainly promoted the mp3 explosion and turned a grubby fringe business (yes, business: Napster, Kazaa, pretty much all the early P2P music apps I can think of were closed-source commercial packages) into an edgy and exciting Robin-Hood open-source movement.
I was just about to point out that the GPL is not isomorphic to open source software but I decided to check first.
It seems that OpenAFS support might have to be pulled from Linux because of a change to a header.
The GPL keeps people from using FOSS.
See, the big problem is that the GPL is an attempt to use copyright law against itself, in a kind of legal ju-jitsu. That's its primary goal, and supporting the spread of liberally copyrighted software (to avoid the free/open debate) is secondary. So you can support copyright and oppose open source, support copyright and support open source, oppose copyright and support open source, and even oppose copyright and oppose open source.
Say what? You can oppose copyright and oppose open source?
Sure. Microsoft's done that for years, and their open source efforts have been kind of passive-aggressive...
Microsoft and many other people who are yelling the strongest about copyright violations are the folks who want to replace copyright law with contract law. They only use copyright to force people into operating on a contract basis, and pushed through the DMCA with its explicit clauses to make copyrights subservient to contracts. Copyright law grants rights to the user as well as the creator, and so anyone who licenses software under an "end user license agreement" that restricts those rights is just as opposed to copyrights as the most rabid GPL worshipper.
UCS-2 only covers plane zero (the Basic Multilingual Plane, or BMP). It doesn't cover code points outside that. Unicode actually supports the entire UCS, all 1.1 million (and growing) code points.
In other words, Joel has made the same mistake as the people who wrote software that only works in 7-bit ASCII or 8-bit UTF-8 or the IBM or Apple or Adobe 8-bit extended ASCII sets or the 9-bit extended ASCII set that ITS used, or...
And it's already too late to try and cram everything into 2 bytes. After the Han Unification mess (the attempt to force Chinese and Japanese and everything else that used some variant of Chinese ideograms (Kanji, etc...) into a common subset of similar characters that fit in the 65535 available codes in the BMP) the People Republic of China decided to require their computers to support their national encoding anyway. As of 2000.
So you have to support the full UCS encoding anyway.
There's three storage formats that it's practical to use: UCS-4 (4 bytes per character, with the same byte-ordering problems as UCS-2), UTF-16 (2-4 bytes per character, same as UCS-2 for the BMP) or UTF-8 (1-4 bytes per character). Internally: you can use UCS-4 as your wide character type, and translate on the fly; use UTF-8 and use care to avoid breaking strings in the middle of glyphs or use UTF-16 and translate on the fly and use care to avoid breaking strings in the middle of glyphs.
If Joel is lucky the libraries he's using are actually operating on UTF-16 strings instead of UCS-2 strings. If he's *really* lucky they're designed to avoid breaking up codes outside the BMP. If he's *super* lucky he's managed to avoid creating any code that just operates on strings as a stream of wchar_t anywhere.
Personally, I think that UTF-16 gets you the worst of both worlds: your data is almost certainly less compact than if you use UTF-8; you still have to deal with multi-wchar_t strings so your code is no easier to write than if you used UTF-8... you're just less likely to find bugs in testing; and you get byte order issues in files just like you would with UCS-4. Unless you think UCS-2 is "good enough" and you just ignore everything outside the BMP and discover that people in China are suddenly getting hash when they use your program.
I would say "always" but nobody's *always* anything... but often enough I can't pull up a specific example of a Joel On Software article that's not off the top of my head. :)
I was going to ask whether this couldn't have been tried in Australia. Thanks for the details.