If you think Word is only dealing with "saving text" you need to spend some time learning what it can do. The format specs are big because their users needs are big.
Re:They should make a concerted effort to drop leg
on
Fresh Air For Windows?
·
· Score: 1
You aren't, it's been done before, as Apple did with Classic. And in fact Microsoft tried it before as well.... when developing Windows 95.
The 16->32 bit transition was rather complicated, and basically meant rewriting large parts of Windows. The whole programming model changed. It seemed like the easiest approach to compatibility would be to run Win3.1 inside a VM, with a "screen in a window" design. This would certainly have been convenient for the engineers.
One small problem. People hated it. Really hated it. They would have to run a mix of old/new apps and they couldn't copy/paste between the apps. They got confused by the window-in-a-window. They couldn't drag and drop. File associations didn't work well. More and more holes had to be poked into the VM to give users the experience they expected, that pretty quickly the VMs became so tightly interlinked that they weren't really a "virtual machine" anymore. But the upgrade experience was great!
You can read more about it here. Anyway, I don't want Windows to run old apps in a VM. You're practically guaranteed to be running an old app at some point, and then you double your overheads. Many good apps aren't being rewritten to new APIs anytime soon - look at the pain Adobe goes through trying to keep up with Apple. Often they are the last by a long way, because it's so painful. Now multiply that by 1000x and you have the situation on Windows.
Reading the documentation, writing unit tests. The docs are sometimes incomplete or wrong but are mostly pretty good. The missing bits are stuff that most API docs miss - what exactly is done under all the error conditions, for instance.
OK so here's the trick. Your PIN number is not stored in the card, nor on the banks servers. In fact it's not stored anywhere at all. The story summary is confused, but it's not surprising because they way this works is not really intuitive.
Your PIN number is in fact a function of your card number. It's fixed for the lifetime of the card. When you "change" your PIN, all you do is store an offset (in the clear) from the real pin number on the card. Whatever you type in has that offset subtracted and then checked against the real PIN.
The function is basically an encryption of the card number, followed by a truncation. If you know the encryption key (which is in every ATM, inside a secure/tamper-proof chip), you can calculate the PIN number of any account number.
It sounds like what happened here is the most serious breach a card system can have - a gang managed to steal both account numbers and the the key used to protect them. That's why the bank had to issue new cards. The old ones were compromised for life.
I see your overloaded DB server and raise you a "web app development on the lecturers laptop".
A class of 60 people in teams attempting to run the web apps they had to write on a Mac laptop. Hilarity ensued.
Nobody was told where the Tomcat logfiles were either, so once I found them I had to deal with other students code dumping 500 line backtraces into it every few seconds (didn't work? why not hit reload and try again!).
This led to an interesting bug. Well, it would have been interesting if we didn't have to fix it under time pressure. Part of the web app involved charts. I decided to use a free Java charting library, it was actually pretty good but what I didn't know is that it used AWT to do some aspects of text handling. AWT of course is based on native graphics APIs and on MacOS X there are some restrictions on which UNIX users can access the font rendering system. My lecturer ran tomcat, and then logged out but in such a way that Tomcat was still running. This caused the text API inside JFreeChart to throw an "access denied" exception, which was caught and thrown away but silently corrupted some internal state and broke our app.
Best thing - he logged out during a 10-minute gap between two workgroup sessions that were held in different rooms. Imagine how delighted we were to find that our app, which worked perfectly, had managed to stop working in the time it took for us to walk across the campus!
Bingo. One of my profs at the UK uni I went to (who in fact ran the whole department) said to my face that he doesn't read students code. In fact he seemed outraged at the very idea.
I discovered this because we got set a programming assignment. We had to solve some problem (I forget what) using three different approaches. The requirements were pretty low, for instance, random search was one allowed algorithm. We also had to explain what our approaches were. This was a 4 week assignment.
I handed in three working algorithms with the explanations in (very long) comments in the classes for each algorithm. Another guy I knew handed in 1 implementation that compiled but didn't work and 1 implementation that didn't compile. He got 80% and I got 10% (a fail), because he "explained" his method in a Word document that he printed out and handed in to the prof, whereas I was foolish enough to assume said prof would read the code I submitted.
Canadian tar sands production is too small to be of consequence, as it's bottlenecked by drawing rights on the Alberta river. They're predicting they'll get to 2 megabarrels/day by 2015, which is still only a small portion of the worlds 75+ megabarrel/day demand. That ain't gonna save us.
the native Windows internal API hooks that help Explorer work faster than any independent browser could possible aspire to?
Can we get over this urban legend please? There aren't any such "native Windows internal API hooks" - unless you can give references? FWIW I used to distribute a hacked up Wine that could install and run IE6 just fine (this was several years ago). It started faster and browsed just as fast as native Mozilla did, but that was because it was tightly written, not because of cheating.
Lots of ISPs run transparent caching proxy servers so wikipedia could be cached if they wanted. They set their headers to prevent that though, presumably so changes show up immediately.
No, probably not. The repositories system used on Linux has huge, massive problems and offers basically no scalable protection.
Here's the problem with using some central authority to bless software (which is what repositories are). Firstly, it has to be exclusive. If there's a user-friendly way to install software outside of the repository, you don't have any useful protection. You can't even train people to prefer software from the repository, because inevitably, somebody who can't be bothered with certification will just stick their program on their website, and they'll be completely trustworthy. So telling users "don't trust people outside the repo" will conflict with their actual experience and be confusing.
If you make it exclusive you now have even bigger problems. Just imagine if Microsoft tried this. It's easy to see what could go wrong. For starters, the moment Microsoft flipped the "kill bit" for a program they'd get sued.
Imagine that some shady outfit writes an MP3 player. It becomes moderately popular. Then it's discovered that the install whacks some adware on the system. Microsoft removes the download and revokes the program certificate (or whatever). The company sues, claiming that the adware was licensed and they didn't know the software would change its behavior over time depending on what it downloaded from the net.
Let's say Microsoft caution them, the adware is removed, and the MP3 player is back. Let's also say that this MP3 player will download and play a little jingle from the makers website when it starts. Well now we have another problem - guess what, the MP3 player has a buffer overflow in it, and the companies website gets "hacked" (cough). 500,000 machines just got owned. The adware is back. Microsoft smack the MP3 player company again and pull the download for good. The next day, a buffer overflow is discovered in Safari.
What do they do? Either they can flip the kill bit on Safari and pull the download, instantly reducing its market share on Windows to zero. Hello anti-trust lawsuits! Or they can have an inconsistent policy, opening themselves up to yet another anti-competition lawsuit from the MP3 player manufacturers.
The moment you make some random group of people judge, jury and executioner over the rest of the software industry, you're gonna run into a sticky pile of problems. The Linux guys just haven't figured that out yet.
Microsoft has never attempted to require code signing for drivers. Users have always been able to override that.
They tried to require it for easy, warning free install but unfortunately a lot of manufacturers attempted to game the system (ie, hide the warnings in some way or instructed the user to ignore them) - unsurprisingly, these very same vendors were the ones writing buggy crash-prone crap.
Given that most users are their own administrators at home, I don't know who exactly you think should be signing the drivers. Ultimately, somebody has to act as an arbiter of quality and authenticity - it might as well be the OS manufacturer.
The point of driver signing isn't to act as a copy protection mechanism. You can boot Vista64 in a mode that'll allow you to load any drivers. The point is to stop programs loading crap into the kernel without the users knowledge. If you have to put the OS into some kind of very obvious "unsafe mode" then the problem becomes much less serious. Can you imagine malware popping up a dialog explaining some complicated boot sequence to the user?
It's not that easy:-( Believe me, some of us have been studying the problem for a looooong time.
The trick is to strike a balance between legacy technologies (also known as "stuff proven to work") and new ideas. It's very hard. For instance, you say "let's write everything in Java, as well as the kernel".... that's describing an epic journey in a sentence! Microsoft has already got an R&D program that does exactly what you suggest, Singularity, but nobody is suggesting it'll be on end-user desktops anytime soon. It's too radical a departure.
You also say "don't allow programs to write other programs". How are you going to enforce that exactly? For instance, how would you run a compiler on such a system? Clearly, some programs have to be able to write other programs. What about a web browser? Web browsers routinely download and run programs... it's only a small step to imagine them somehow compiling JavaScript into native code just like the JVM does with applets. Is the web browser writing another program?
Of course the real problem is not programs writing programs. The real problem is programs modifying other programs. This describes most malware as well as your debugger. How can you ensure that the debugger is allowed to do these dangerous things (ie, poke/modify state of other programs arbitrarily) but malware isn't? Having a trusted chain of execution is one, ie, the debugger can debug programs it launches itself, but not any other programs.
Strategies like Singularity, BitFrost, AppArmor, CoreForce etc all have something to contribute but their implementability varies wildly.
The indie XBox developer stuff is pretty good though. They'll accept nearly anything as long as it doesn't crash. Also, they are peer reviewed (ie not by Microsoft). The process is really very lightweight. Yes in theory a game might still get pulled by a console owner for political reasons, but the risk of that is very small and meanwhile, consoles are still a whole lot more convenient than PCs are (for the end users).
Not just games, any commercial software. I used to work for CodeWeavers and we had exactly the same problem - people would file support tickets but had not actually paid for the software. And this is a company that is a huge open source LGPL-code contributor!
We had internal statistics (that it's not my place to share) on how much the average support ticket cost, and how many customers filed tickets. To be blunt, the support load was nearly killing the company when I was there. Of course people warezing the binaries and then asking for help was one of the most offensive things they could do.
Sadly, using Linux does not convert one into a paragon of virtue. Piracy exists on every platform, it just varies as to the extent of the problem.
What? No one ever bought a game because they couldn't pirate it.
What? That isn't correct. The entire value proposition of anti-copy systems is that a sizable fraction of pirates will buy the game if a crack is not readily available. The big publishers and CP vendors like Macrovision have quite detailed statistics on this, along with functions relating time-to-crack with increase in sales.
Ugh, are you serious? [a] That'd be really annoying and stupid, just like those irrelevant ads on TV are. [b] As you point out, people would just remove them anyway. [c] What makes you think advertisers are gonna pay $40-$50 per impression, which is what you'd need to replace selling copies retail? Normally advertisers pay cents for impressions.
ActiveX hasn't been default-on for years now, it's really not a hole any longer and hasn't been for a while. FWIW the experience of Firefox has been that people started to target it when it reached ~12% market share, so Apple has a while to go yet. For Safari just google "safari remote code execution". QuickTime also has had some nasty exploits.
If you're interested in that sort of thing, try "History: Fiction or Science?" by Anatoly Fumenko.
It's a very interesting analysis of historical dating methods and how reliable (or not) they might be. Of course you have to take the book with a large pinch of salt - his theory is nothing less than all of history before about 1500 has been wrongly dated, with the result that events we consider "ancient" today actually happened in what we think of as medieval times.
He spends a lot of time taking apart eclipse dating. In particular he points out that eclipses have recurring solutions - most historical events "proven" to occur in a specific year could actually have also occurred in mediaeval times but this solution is always discarded as being obviously wrong (as it defies the conventional wisdom as to dating). Then he shows how most other historical dating methods like radiocarbon dating, tree-ring dating etc are all calibrated against each other and ultimately, against the common consensus of when things happened.
The language is a bit overly fancy but if you're interested in ancient history (or is it?) and like a good, well argued conspiracy theory, you could do worse than read this book.
The point is, it's much easier to change software than peoples perceptions. Blaming people rather than the OS is a cheap and useless shot. It doesn't achieve anything. Research into secure desktops is at an early stage but it does exist. We know we can do significantly better than the MacOS/Windows security models. We just aren't doing it in mainstream operating systems because it's hard.
Consider the guys test. He sent people a mail that said "please open this app". The mail looked like it came from him. The Apple ads have convinced people that Macs are inhernetly secure (dumb dumb dumb!). The guy is in a position of authority over them in IT regards... so they open the attachment. They don't know that mail can be forged, or that ARD lets you priv escalate your way to a rootkit. How can they know these things? IT administrators have been telling people not to click attachments in mail for years now, but I discovered a couple of months ago that most of my friends had no clue I could send mail that looked like it came from them (or their boss).
Slashdot Mirror
Which Ubuntu? If you didn't get FF3 from the repositories there are probably weird binary incompatibilities.
If you think Word is only dealing with "saving text" you need to spend some time learning what it can do. The format specs are big because their users needs are big.
You aren't, it's been done before, as Apple did with Classic. And in fact Microsoft tried it before as well .... when developing Windows 95.
The 16->32 bit transition was rather complicated, and basically meant rewriting large parts of Windows. The whole programming model changed. It seemed like the easiest approach to compatibility would be to run Win3.1 inside a VM, with a "screen in a window" design. This would certainly have been convenient for the engineers.
One small problem. People hated it. Really hated it. They would have to run a mix of old/new apps and they couldn't copy/paste between the apps. They got confused by the window-in-a-window. They couldn't drag and drop. File associations didn't work well. More and more holes had to be poked into the VM to give users the experience they expected, that pretty quickly the VMs became so tightly interlinked that they weren't really a "virtual machine" anymore. But the upgrade experience was great!
You can read more about it here. Anyway, I don't want Windows to run old apps in a VM. You're practically guaranteed to be running an old app at some point, and then you double your overheads. Many good apps aren't being rewritten to new APIs anytime soon - look at the pain Adobe goes through trying to keep up with Apple. Often they are the last by a long way, because it's so painful. Now multiply that by 1000x and you have the situation on Windows.
Reading the documentation, writing unit tests. The docs are sometimes incomplete or wrong but are mostly pretty good. The missing bits are stuff that most API docs miss - what exactly is done under all the error conditions, for instance.
I don't think he was ever in industry to be honest. He used to lecture Maths at Oxford (what a surprise).
A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.
OK so here's the trick. Your PIN number is not stored in the card, nor on the banks servers. In fact it's not stored anywhere at all. The story summary is confused, but it's not surprising because they way this works is not really intuitive.
Your PIN number is in fact a function of your card number. It's fixed for the lifetime of the card. When you "change" your PIN, all you do is store an offset (in the clear) from the real pin number on the card. Whatever you type in has that offset subtracted and then checked against the real PIN.
The function is basically an encryption of the card number, followed by a truncation. If you know the encryption key (which is in every ATM, inside a secure/tamper-proof chip), you can calculate the PIN number of any account number.
It sounds like what happened here is the most serious breach a card system can have - a gang managed to steal both account numbers and the the key used to protect them. That's why the bank had to issue new cards. The old ones were compromised for life.
I see your overloaded DB server and raise you a "web app development on the lecturers laptop".
A class of 60 people in teams attempting to run the web apps they had to write on a Mac laptop. Hilarity ensued.
Nobody was told where the Tomcat logfiles were either, so once I found them I had to deal with other students code dumping 500 line backtraces into it every few seconds (didn't work? why not hit reload and try again!).
This led to an interesting bug. Well, it would have been interesting if we didn't have to fix it under time pressure. Part of the web app involved charts. I decided to use a free Java charting library, it was actually pretty good but what I didn't know is that it used AWT to do some aspects of text handling. AWT of course is based on native graphics APIs and on MacOS X there are some restrictions on which UNIX users can access the font rendering system. My lecturer ran tomcat, and then logged out but in such a way that Tomcat was still running. This caused the text API inside JFreeChart to throw an "access denied" exception, which was caught and thrown away but silently corrupted some internal state and broke our app.
Best thing - he logged out during a 10-minute gap between two workgroup sessions that were held in different rooms. Imagine how delighted we were to find that our app, which worked perfectly, had managed to stop working in the time it took for us to walk across the campus!
Bingo. One of my profs at the UK uni I went to (who in fact ran the whole department) said to my face that he doesn't read students code. In fact he seemed outraged at the very idea.
I discovered this because we got set a programming assignment. We had to solve some problem (I forget what) using three different approaches. The requirements were pretty low, for instance, random search was one allowed algorithm. We also had to explain what our approaches were. This was a 4 week assignment.
I handed in three working algorithms with the explanations in (very long) comments in the classes for each algorithm. Another guy I knew handed in 1 implementation that compiled but didn't work and 1 implementation that didn't compile. He got 80% and I got 10% (a fail), because he "explained" his method in a Word document that he printed out and handed in to the prof, whereas I was foolish enough to assume said prof would read the code I submitted.
Canadian tar sands production is too small to be of consequence, as it's bottlenecked by drawing rights on the Alberta river. They're predicting they'll get to 2 megabarrels/day by 2015, which is still only a small portion of the worlds 75+ megabarrel/day demand. That ain't gonna save us.
Can we get over this urban legend please? There aren't any such "native Windows internal API hooks" - unless you can give references? FWIW I used to distribute a hacked up Wine that could install and run IE6 just fine (this was several years ago). It started faster and browsed just as fast as native Mozilla did, but that was because it was tightly written, not because of cheating.
Lots of ISPs run transparent caching proxy servers so wikipedia could be cached if they wanted. They set their headers to prevent that though, presumably so changes show up immediately.
No, probably not. The repositories system used on Linux has huge, massive problems and offers basically no scalable protection.
Here's the problem with using some central authority to bless software (which is what repositories are). Firstly, it has to be exclusive. If there's a user-friendly way to install software outside of the repository, you don't have any useful protection. You can't even train people to prefer software from the repository, because inevitably, somebody who can't be bothered with certification will just stick their program on their website, and they'll be completely trustworthy. So telling users "don't trust people outside the repo" will conflict with their actual experience and be confusing.
If you make it exclusive you now have even bigger problems. Just imagine if Microsoft tried this. It's easy to see what could go wrong. For starters, the moment Microsoft flipped the "kill bit" for a program they'd get sued.
Imagine that some shady outfit writes an MP3 player. It becomes moderately popular. Then it's discovered that the install whacks some adware on the system. Microsoft removes the download and revokes the program certificate (or whatever). The company sues, claiming that the adware was licensed and they didn't know the software would change its behavior over time depending on what it downloaded from the net.
Let's say Microsoft caution them, the adware is removed, and the MP3 player is back. Let's also say that this MP3 player will download and play a little jingle from the makers website when it starts. Well now we have another problem - guess what, the MP3 player has a buffer overflow in it, and the companies website gets "hacked" (cough). 500,000 machines just got owned. The adware is back. Microsoft smack the MP3 player company again and pull the download for good. The next day, a buffer overflow is discovered in Safari.
What do they do? Either they can flip the kill bit on Safari and pull the download, instantly reducing its market share on Windows to zero. Hello anti-trust lawsuits! Or they can have an inconsistent policy, opening themselves up to yet another anti-competition lawsuit from the MP3 player manufacturers.
The moment you make some random group of people judge, jury and executioner over the rest of the software industry, you're gonna run into a sticky pile of problems. The Linux guys just haven't figured that out yet.
FWIW Firefox started getting attacked (for real, not by researchers) when it reached about 12% market share. Maybe that's the magic number.
Microsoft has never attempted to require code signing for drivers. Users have always been able to override that.
They tried to require it for easy, warning free install but unfortunately a lot of manufacturers attempted to game the system (ie, hide the warnings in some way or instructed the user to ignore them) - unsurprisingly, these very same vendors were the ones writing buggy crash-prone crap.
Given that most users are their own administrators at home, I don't know who exactly you think should be signing the drivers. Ultimately, somebody has to act as an arbiter of quality and authenticity - it might as well be the OS manufacturer.
The point of driver signing isn't to act as a copy protection mechanism. You can boot Vista64 in a mode that'll allow you to load any drivers. The point is to stop programs loading crap into the kernel without the users knowledge. If you have to put the OS into some kind of very obvious "unsafe mode" then the problem becomes much less serious. Can you imagine malware popping up a dialog explaining some complicated boot sequence to the user?
It's not that easy :-( Believe me, some of us have been studying the problem for a looooong time.
The trick is to strike a balance between legacy technologies (also known as "stuff proven to work") and new ideas. It's very hard. For instance, you say "let's write everything in Java, as well as the kernel" .... that's describing an epic journey in a sentence! Microsoft has already got an R&D program that does exactly what you suggest, Singularity, but nobody is suggesting it'll be on end-user desktops anytime soon. It's too radical a departure.
You also say "don't allow programs to write other programs". How are you going to enforce that exactly? For instance, how would you run a compiler on such a system? Clearly, some programs have to be able to write other programs. What about a web browser? Web browsers routinely download and run programs ... it's only a small step to imagine them somehow compiling JavaScript into native code just like the JVM does with applets. Is the web browser writing another program?
Of course the real problem is not programs writing programs. The real problem is programs modifying other programs. This describes most malware as well as your debugger. How can you ensure that the debugger is allowed to do these dangerous things (ie, poke/modify state of other programs arbitrarily) but malware isn't? Having a trusted chain of execution is one, ie, the debugger can debug programs it launches itself, but not any other programs.
Strategies like Singularity, BitFrost, AppArmor, CoreForce etc all have something to contribute but their implementability varies wildly.
The indie XBox developer stuff is pretty good though. They'll accept nearly anything as long as it doesn't crash. Also, they are peer reviewed (ie not by Microsoft). The process is really very lightweight. Yes in theory a game might still get pulled by a console owner for political reasons, but the risk of that is very small and meanwhile, consoles are still a whole lot more convenient than PCs are (for the end users).
Not just games, any commercial software. I used to work for CodeWeavers and we had exactly the same problem - people would file support tickets but had not actually paid for the software. And this is a company that is a huge open source LGPL-code contributor!
We had internal statistics (that it's not my place to share) on how much the average support ticket cost, and how many customers filed tickets. To be blunt, the support load was nearly killing the company when I was there. Of course people warezing the binaries and then asking for help was one of the most offensive things they could do.
Sadly, using Linux does not convert one into a paragon of virtue. Piracy exists on every platform, it just varies as to the extent of the problem.
Actually, I think both are correct. The proportions are up to the implementors of the scheme.
What? That isn't correct. The entire value proposition of anti-copy systems is that a sizable fraction of pirates will buy the game if a crack is not readily available. The big publishers and CP vendors like Macrovision have quite detailed statistics on this, along with functions relating time-to-crack with increase in sales.
Ugh, are you serious? [a] That'd be really annoying and stupid, just like those irrelevant ads on TV are. [b] As you point out, people would just remove them anyway. [c] What makes you think advertisers are gonna pay $40-$50 per impression, which is what you'd need to replace selling copies retail? Normally advertisers pay cents for impressions.
ActiveX hasn't been default-on for years now, it's really not a hole any longer and hasn't been for a while. FWIW the experience of Firefox has been that people started to target it when it reached ~12% market share, so Apple has a while to go yet. For Safari just google "safari remote code execution". QuickTime also has had some nasty exploits.
If you're interested in that sort of thing, try "History: Fiction or Science?" by Anatoly Fumenko.
It's a very interesting analysis of historical dating methods and how reliable (or not) they might be. Of course you have to take the book with a large pinch of salt - his theory is nothing less than all of history before about 1500 has been wrongly dated, with the result that events we consider "ancient" today actually happened in what we think of as medieval times.
He spends a lot of time taking apart eclipse dating. In particular he points out that eclipses have recurring solutions - most historical events "proven" to occur in a specific year could actually have also occurred in mediaeval times but this solution is always discarded as being obviously wrong (as it defies the conventional wisdom as to dating). Then he shows how most other historical dating methods like radiocarbon dating, tree-ring dating etc are all calibrated against each other and ultimately, against the common consensus of when things happened.
The language is a bit overly fancy but if you're interested in ancient history (or is it?) and like a good, well argued conspiracy theory, you could do worse than read this book.
The point is, it's much easier to change software than peoples perceptions. Blaming people rather than the OS is a cheap and useless shot. It doesn't achieve anything. Research into secure desktops is at an early stage but it does exist. We know we can do significantly better than the MacOS/Windows security models. We just aren't doing it in mainstream operating systems because it's hard.
Consider the guys test. He sent people a mail that said "please open this app". The mail looked like it came from him. The Apple ads have convinced people that Macs are inhernetly secure (dumb dumb dumb!). The guy is in a position of authority over them in IT regards ... so they open the attachment. They don't know that mail can be forged, or that ARD lets you priv escalate your way to a rootkit. How can they know these things? IT administrators have been telling people not to click attachments in mail for years now, but I discovered a couple of months ago that most of my friends had no clue I could send mail that looked like it came from them (or their boss).