Hanging Chads... You way back in the year 2000... The cause of the E-Voting Craze...
Hanging chads were not the problem. The problem was the "instant results" mania. There's absolutely no reason it should matter if an election held in November for a President to take office the following year isn't certified by the end of November or even December... let alone the same night.
Preventing people from forging ballots is hardly rocket science... scanners to verify a bar or dot code are cheap enough that people have even given them away free (that's how I got my scanner): just print each ballot with a verifiable quasi-random hash and even small scale forgery will come out... without compromising privacy since there should be no connection between the preprinted ballot and the voter who picks it up.
Apple kind of got away with marketing a gizmo as a phone with the iPhone, but it's being used more as a photo album than a phone, from what I can tell.
Doesn't matter whether you call them PDAs, handheld computers, smartphones, gizmos, or wakalixes, they're bloody useful. I haven't gone more than a day or two without using some capability of my gizmo since I bought my first gizmo in early 2000.
The iPhone is ludicrously successful and it's not even much of a smartphone. I personally want more of a gizmo than the iPhone gives me, and I'm not sure I want my gizmo and phone in one package so long as my phone's tied down to a contract with a carrier so I have to change gizmos (which is a daunting exercise) if I change carriers, but that just means that if even as expensive and limited a gizmo as the iPhone can take off like it has there's a hell of a lot of untapped demand.
What else does Dvorak bring up? The klunky Sidekick hardware! Google isn't designing the hardware, so what does that matter? Let's go on...
I've actually used various phones with Web capability. They never work right.
Much as I hate to praise Microsoft, Pocket Internet Explorer in 2000 was a killer application. Enough of IE to be useful, and enough of the net was still display-independent (or beginning to provide PDA-firendly displays... though Slashdot's had occasional regressions there, hem hem), that it was completely reasonable to use for casual searches, and a couple of years later I got a chance to try it out on a phone. It was brilliant when I had access, alas T-Mobile's service in Houston at the time sucked so it wasn't even very useful as a phone... and the rest of the software really wasn't up to the quality of Pocket IE.
Now if Dvorak's talking about one of those Java based browsers on semi-dumb phones rather than a real browser on a phone running a real OS, well, I can see where he could get that impression. But then his experience has little to do with Google's Linux-based plans.
Finally...
When all is said and done, Google is actually not a charismatic company
I can't come up with a coherent response to this one. He's clearly in some other universe. Hopefully they don't have a gizmo to teleport him back.
I don't think anyone here gives a damn whether NY gives the money back to the Feds. If the DoJ is demanding that they give the money back or implement a specific solution that does not satisfy their needs, then they should give it back... not comply with the law. If the DoJ is not giving them that option then what is the DoJ's agenda here?
In addition:
New York delayed writing a HAVA compliant state law longer than any other state.
Is this a problem with New York or a problem with HAVA's deadlines? Did they delay because they were trying to avoid compliance, or because they were trying to find a solution that was both compliant and secure?
Hey NY, if you don't want to play by the Feds rules, don't take their (our) money.
You haven't established that they don't want to, merely that they haven't been able to. Given what other states have done to comply, I'd say that failure is a better outcome than success.
I understand your logic, but I don't see how it applies or what benefit it has if it does apply. I'm saying that (a) the system as described doesn't appear to fit that description (if that was the case it would be able to operate in standby mode indefinitely using the included photoelectric cells to maintain the charge on the capacitor), and (b) even if that logic applied there doesn't seem to be much point to this "standby mode" to begin with. If it's not required to maintain components in the system in a "ready state" to provide an instant-on capability, why would you not be better off using a hard power switch?
I think you're combining two unrelated issues here, and neither of them involve any kind of technical copy protection or DRM scheme.
First, unless your build process is really broken, building two versions of a program for distribution out of the same source tree is trivial.
Second, registration and copy protection are really separate issues. Copy protection involves some kind of obfuscation of a shared secret, typically in hardware or in the OS (though sometimes, as in my case, simply in an unobvious place that requires some effort to find), that locks an instance of an application to a particular system or other asset that can't readily be copied. Registration doesn't require the additional speedbump of copy protection... a registration key can be a simple cryptographic token that can be stored in unobfuscated form in a configuration file and saved and restored by the user. That way the user isn't subject to the risk of his purchase vanishing if he reformats his hard disk or damages the distribution CD, and you as good a speedbump as if you used some kind of copy protection technique: the fact that you can tie it back to the original purchaser is more than enough of an incentive to discourage trading.
Then he should have asked about the attack, not the vulnerability. From the message I replied to: "only if the vulnerability can be exploited remotely with NO interaction on my part do I care". That's not a question about the whole process, it's a question about this particular hole.
This is not a remote execution hole. Whatever code it was found in may have contained exploits for other vulnerabilities, or this may have been part of a rootkit dropped by an otherwise unrelated exploit. But this vulnerability itself is not exploitable remotely. Most likely this was part of the payload of an already reported exploit or a variant thereof.
do you gotta be doing something stupid sitting there in front of it to get this or not?
That depends entirely on the other vulnerabilities exploited by the attack Elia Florio was investigating. There are so many active attacks that which particular one this was buried in is not really relevant. There's one out that attacks the recent patch to Word (so patch your copy), there's been a bundle of attacks targeting instant messaging systems and browser plug-ins, there's the recent flood of URI quoting holes targeting Windows' ShellExec call, and even one that attacks "Clippy" (yay, another already-installed ActiveX hole... Microsoft's ten years of denial about the way their HTML control uses ActiveX continues apace: their security fix is another bandaid. Personally, I trashed agentdpv.dll instead: it's not like I'm ever going to want that horrid thing).
The bottom line is that this is not a new remote execution vulnerability. Don't do anything different as a result of this, unless you're doing something hazardous like browsing the web with IE.:)
I can't take responsibility for the box art or backstory, the publisher tossed our concept and redid the whole thing from scratch. Which was probably to the good, since the original backstory we came up with was sufficiently unmemorable that I actually can't remember it.:)
Unless, like me, the only means of distribution is over the 'net. In which case, copy protection is the only viable means to differentiate your product from free software.
Are you saying that copy protection makes your product better? More competitive? What do you mean by "differentiate" here?
I downloaded Pixel to evaluate it. I created a block of text. I went back to edit it... and I can't see how to select a block of text that's already created to modify it. Clicking on the text, selecting the layer, right-clicking and selecting all, using various key and click combinations, it doesn't matter what I do, nothing selects the existing text. Not only that, but I ended up with a bunch of empty text layers I had to individually delete.
This isn't a matter of it not behaving like Photoshop. This is a matter of not being able to figure out how to do a fundamentally basic operation.
The main reason I use Photoshop instead of one of the decent open source apps is because photoshop is the only one that really does a good job of deferring rasterization. A vector layer in photoshop (like a text layer) stays that way no matter what you do to it unless you explicitly rasterize it by simplifying the layer or merging layers.
I wouldn't mind them using actionscript to customize the UI, myself, if they'd just stick to that... having little XML files with embedded actionscript fragments instead of little XML files with embedded javascript fragments (like Firefox or Konfabulator) shouldn't be too bad. If they actually go all the way and require you to buy an extra $700 program on top of the $200 upgrade (or $650 new copy) to customize it, you can include me out.
The power required to keep the components live in 'standby' mode still has to come from somewhere. They claim they're using photoelectric cells to maintain power during standby, but it seems to me that you would need more power than can be supplied by any reasonably sized photoelectric collector, and the comment "Solar panels provide enough power to maintain zero consumption mode for up to five days, after which you have to press a regular power button to bring the machine out of standby" doesn't make much sense: if the standby power is actually provided by the photocells then why is there a time limit?
That five day limit implies pretty strongly that they're using power stored in an accumulator to maintain standby mode, and that accumulator has to be recharged from the mains when you plug it in again. The total power requirements over the whole cycle would be higher than actually running it in standby from the mains.
Every time this is discussed on Slashdot there are comments from Slashdotters who legitimately purchase games and then download cracked versions because the crippled, boxed versions are too much hassle.
I did that around 1981 when I went to the local "unlicensed software distributors" at the University to get a cracked copy of Wizardry written out on top of my gold-labeled store-bought floppy because the copy protection had made the original unplayable... which meant I may have had the only "legal" cracked copy in existence. I ran into the author of the game online many years later, and he thought that was pretty amusing.
Several years later a friend and I released a game for the Amiga and since the publisher required copy protection we came up with a copy protection scheme for it that didn't require modifying the OS or bypassing the driver, and allowed the protected disks to be created using a regular script. Since we knew that copy protection was a speedbump, we came up with some speedbump-quality protection that would still do a better job at blocking the most common cracking tools than the "professional" and more intrusive protection schemes.
What we did was take advantage of the way the Amiga identified disks by using a unique ID in the disk header. All copy protection cracking tools we knew of generated a new ID by default, so that the user wouldn't get an error from the OS if they left the original and the copy both in the drives after they exited the program. We stored an obfuscated copy of the ID in file comments, and ran in "demo mode" if they didn't match. It didn't pop up any warning screens, it just wouldn't let you get past the 'attract mode' display. This meant that most people just using a "raw" copier would get an apparently "damaged" copy that still kind of worked... we figured this was unintrusive and at least as good a speedbump as you got from a scheme that had defeat code preprogrammed into the copying tools, for the week or so before it got figured out and our scheme got added to the rest.
We provided our publisher with detailed instructions, explanations, and a set of disks to use to create the copies if they didn't use an image duplicator. They fobbed production off on another company who blithely used one of the cracking tools we were targeting to do the production run. If they'd used a normal image duplicator or our scripts everything would have been fine, but instead all the shipped copies came up in demo mode. Of course the game had to be recalled, and we missed the Christmas launch.
Copy protection (whether you call it copy protection or DRM) increases the costs and risks of production and just plain doesn't do anything more than flashing a "don't pirate this game" splash screen would.
During the weekend I found an interesting sample exploiting a possibly new and undocumented vulnerability for Windows XP and 2003. The exploit is a local privilege escalation that allows users with a restricted account to gain a SYSTEM shell with higher privileges. In my tests the exploit seems to work successfully against a fully patched Windows XP-SP2 and also Windows 2003-SP1. At this time, Vista does not seem to be affected by the problem. -- Elia Florio
The only purpose of secdrv.sys is to run games that depend on "SafeDisc" copy protection. If you don't play games on your computer (or you shouldn't... corporate users take note) you don't need it, and if you do you only need it to play games using this particular scheme.
This is a local privilege escalation exploit. An attacker will have to use some other exploit to get onto your computer before using this one to get system privileges. This is another reason for corporate administrators to eliminate the driver, since it can be used by employees to bypass local policies.
Let's hope the EFF is prepared to go after one of the "good guys". They've got a relationship with Leahy, and they've lionized him in the past, but now it's time to call in their markers.
Not only do they have outrageous penalties written into civil law, but now they want to get the taxpayer to pay for their larcenous lawsuits? I think we need to recognise that the closest thing to real piracy in this situation is what the RIAA is doing. Not only have they been granted letters of marque by the US government to exact punishment in civil suits, but now they're getting the government to pay for it. All that remains would be for George II to start handing out knighthoods (after all, it worked for Francis Drake).
First: She's always like, "I'm sorry, I don't know who you are." her policy is to never buzz anyone in. She angered the chairman once over it, who was talked out of firing her precisely because he's in the office like 3 times a year. She won't buzz people in and she's unrepentently steadfast about it. She's dumb as dirt.
She's not dumb, she's smart.
Second: Simple systems are more likely to be secure than more complex systems in general as they are less prone to component failure.
The Java sandbox is an extremely complex system, with trusted and untrusted code running in the same address space calling the same libraries, with the security managed by code that's also using the same libraries and running in the same address space. I am honestly amazed that it's worked as well as it has.
The multiuser protection in UNIX is an extremely simple system, with untrusted code running in separate address spaces and, traditionally, with the ability to run security applications using no shared libraries at all. It's also proven extremely effective, and it has the advantage that even if flawed code is run those flaws do not automatically provide an escape route from the whole sandbox the way flaws in libraries called from Java do.
This is not to say that the Java sandbox isn't a useful tool, but rather to say that when analyzing the security of the system as a whole the fact that an application is written in Java should not be given the kind of importance that it seems to be getting here.
Slashdot Mirror
It's a cookbook!
Hanging Chads... You way back in the year 2000... The cause of the E-Voting Craze...
Hanging chads were not the problem. The problem was the "instant results" mania. There's absolutely no reason it should matter if an election held in November for a President to take office the following year isn't certified by the end of November or even December... let alone the same night.
Preventing people from forging ballots is hardly rocket science... scanners to verify a bar or dot code are cheap enough that people have even given them away free (that's how I got my scanner): just print each ballot with a verifiable quasi-random hash and even small scale forgery will come out... without compromising privacy since there should be no connection between the preprinted ballot and the voter who picks it up.
Doesn't matter whether you call them PDAs, handheld computers, smartphones, gizmos, or wakalixes, they're bloody useful. I haven't gone more than a day or two without using some capability of my gizmo since I bought my first gizmo in early 2000.
The iPhone is ludicrously successful and it's not even much of a smartphone. I personally want more of a gizmo than the iPhone gives me, and I'm not sure I want my gizmo and phone in one package so long as my phone's tied down to a contract with a carrier so I have to change gizmos (which is a daunting exercise) if I change carriers, but that just means that if even as expensive and limited a gizmo as the iPhone can take off like it has there's a hell of a lot of untapped demand.
What else does Dvorak bring up? The klunky Sidekick hardware! Google isn't designing the hardware, so what does that matter? Let's go on...
I've actually used various phones with Web capability. They never work right.
Much as I hate to praise Microsoft, Pocket Internet Explorer in 2000 was a killer application. Enough of IE to be useful, and enough of the net was still display-independent (or beginning to provide PDA-firendly displays... though Slashdot's had occasional regressions there, hem hem), that it was completely reasonable to use for casual searches, and a couple of years later I got a chance to try it out on a phone. It was brilliant when I had access, alas T-Mobile's service in Houston at the time sucked so it wasn't even very useful as a phone... and the rest of the software really wasn't up to the quality of Pocket IE.
Now if Dvorak's talking about one of those Java based browsers on semi-dumb phones rather than a real browser on a phone running a real OS, well, I can see where he could get that impression. But then his experience has little to do with Google's Linux-based plans.
Finally...
When all is said and done, Google is actually not a charismatic company
I can't come up with a coherent response to this one. He's clearly in some other universe. Hopefully they don't have a gizmo to teleport him back.
I don't think anyone here gives a damn whether NY gives the money back to the Feds. If the DoJ is demanding that they give the money back or implement a specific solution that does not satisfy their needs, then they should give it back... not comply with the law. If the DoJ is not giving them that option then what is the DoJ's agenda here?
In addition:
New York delayed writing a HAVA compliant state law longer than any other state.
Is this a problem with New York or a problem with HAVA's deadlines? Did they delay because they were trying to avoid compliance, or because they were trying to find a solution that was both compliant and secure?
Hey NY, if you don't want to play by the Feds rules, don't take their (our) money.
You haven't established that they don't want to, merely that they haven't been able to. Given what other states have done to comply, I'd say that failure is a better outcome than success.
I understand your logic, but I don't see how it applies or what benefit it has if it does apply. I'm saying that (a) the system as described doesn't appear to fit that description (if that was the case it would be able to operate in standby mode indefinitely using the included photoelectric cells to maintain the charge on the capacitor), and (b) even if that logic applied there doesn't seem to be much point to this "standby mode" to begin with. If it's not required to maintain components in the system in a "ready state" to provide an instant-on capability, why would you not be better off using a hard power switch?
I think you're combining two unrelated issues here, and neither of them involve any kind of technical copy protection or DRM scheme.
First, unless your build process is really broken, building two versions of a program for distribution out of the same source tree is trivial.
Second, registration and copy protection are really separate issues. Copy protection involves some kind of obfuscation of a shared secret, typically in hardware or in the OS (though sometimes, as in my case, simply in an unobvious place that requires some effort to find), that locks an instance of an application to a particular system or other asset that can't readily be copied. Registration doesn't require the additional speedbump of copy protection... a registration key can be a simple cryptographic token that can be stored in unobfuscated form in a configuration file and saved and restored by the user. That way the user isn't subject to the risk of his purchase vanishing if he reformats his hard disk or damages the distribution CD, and you as good a speedbump as if you used some kind of copy protection technique: the fact that you can tie it back to the original purchaser is more than enough of an incentive to discourage trading.
Then he should have asked about the attack, not the vulnerability. From the message I replied to: "only if the vulnerability can be exploited remotely with NO interaction on my part do I care". That's not a question about the whole process, it's a question about this particular hole.
:)
This is not a remote execution hole. Whatever code it was found in may have contained exploits for other vulnerabilities, or this may have been part of a rootkit dropped by an otherwise unrelated exploit. But this vulnerability itself is not exploitable remotely. Most likely this was part of the payload of an already reported exploit or a variant thereof.
do you gotta be doing something stupid sitting there in front of it to get this or not?
That depends entirely on the other vulnerabilities exploited by the attack Elia Florio was investigating. There are so many active attacks that which particular one this was buried in is not really relevant. There's one out that attacks the recent patch to Word (so patch your copy), there's been a bundle of attacks targeting instant messaging systems and browser plug-ins, there's the recent flood of URI quoting holes targeting Windows' ShellExec call, and even one that attacks "Clippy" (yay, another already-installed ActiveX hole... Microsoft's ten years of denial about the way their HTML control uses ActiveX continues apace: their security fix is another bandaid. Personally, I trashed agentdpv.dll instead: it's not like I'm ever going to want that horrid thing).
The bottom line is that this is not a new remote execution vulnerability. Don't do anything different as a result of this, unless you're doing something hazardous like browsing the web with IE.
Tracers. Dead simple graphics, most of our effort was spent on playability and being a "well behaved" program.
:)
http://amigareviews.classicgaming.gamespy.com/tracers.htm
I can't take responsibility for the box art or backstory, the publisher tossed our concept and redid the whole thing from scratch. Which was probably to the good, since the original backstory we came up with was sufficiently unmemorable that I actually can't remember it.
I'm not sure what you're getting at here:
Unless, like me, the only means of distribution is over the 'net. In which case, copy protection is the only viable means to differentiate your product from free software.
Are you saying that copy protection makes your product better? More competitive? What do you mean by "differentiate" here?
OK, so you can only remove this file on 99% of the desktops in a typical company, instead of 100%. :)
I downloaded Pixel to evaluate it. I created a block of text. I went back to edit it... and I can't see how to select a block of text that's already created to modify it. Clicking on the text, selecting the layer, right-clicking and selecting all, using various key and click combinations, it doesn't matter what I do, nothing selects the existing text. Not only that, but I ended up with a bunch of empty text layers I had to individually delete.
This isn't a matter of it not behaving like Photoshop. This is a matter of not being able to figure out how to do a fundamentally basic operation.
Well, apart from the fact that it's Windows-only, does it have adjustment layers and deferred rasterization built in?
The main reason I use Photoshop instead of one of the decent open source apps is because photoshop is the only one that really does a good job of deferring rasterization. A vector layer in photoshop (like a text layer) stays that way no matter what you do to it unless you explicitly rasterize it by simplifying the layer or merging layers.
I wouldn't mind them using actionscript to customize the UI, myself, if they'd just stick to that... having little XML files with embedded actionscript fragments instead of little XML files with embedded javascript fragments (like Firefox or Konfabulator) shouldn't be too bad. If they actually go all the way and require you to buy an extra $700 program on top of the $200 upgrade (or $650 new copy) to customize it, you can include me out.
The power required to keep the components live in 'standby' mode still has to come from somewhere. They claim they're using photoelectric cells to maintain power during standby, but it seems to me that you would need more power than can be supplied by any reasonably sized photoelectric collector, and the comment "Solar panels provide enough power to maintain zero consumption mode for up to five days, after which you have to press a regular power button to bring the machine out of standby" doesn't make much sense: if the standby power is actually provided by the photocells then why is there a time limit?
That five day limit implies pretty strongly that they're using power stored in an accumulator to maintain standby mode, and that accumulator has to be recharged from the mains when you plug it in again. The total power requirements over the whole cycle would be higher than actually running it in standby from the mains.
What kind of crazy company uses hardware-based copy protection for anything but games?
Got a list of guilty parties so we know who to stay the hell away from?
Every time this is discussed on Slashdot there are comments from Slashdotters who legitimately purchase games and then download cracked versions because the crippled, boxed versions are too much hassle.
I did that around 1981 when I went to the local "unlicensed software distributors" at the University to get a cracked copy of Wizardry written out on top of my gold-labeled store-bought floppy because the copy protection had made the original unplayable... which meant I may have had the only "legal" cracked copy in existence. I ran into the author of the game online many years later, and he thought that was pretty amusing.
Several years later a friend and I released a game for the Amiga and since the publisher required copy protection we came up with a copy protection scheme for it that didn't require modifying the OS or bypassing the driver, and allowed the protected disks to be created using a regular script. Since we knew that copy protection was a speedbump, we came up with some speedbump-quality protection that would still do a better job at blocking the most common cracking tools than the "professional" and more intrusive protection schemes.
What we did was take advantage of the way the Amiga identified disks by using a unique ID in the disk header. All copy protection cracking tools we knew of generated a new ID by default, so that the user wouldn't get an error from the OS if they left the original and the copy both in the drives after they exited the program. We stored an obfuscated copy of the ID in file comments, and ran in "demo mode" if they didn't match. It didn't pop up any warning screens, it just wouldn't let you get past the 'attract mode' display. This meant that most people just using a "raw" copier would get an apparently "damaged" copy that still kind of worked... we figured this was unintrusive and at least as good a speedbump as you got from a scheme that had defeat code preprogrammed into the copying tools, for the week or so before it got figured out and our scheme got added to the rest.
We provided our publisher with detailed instructions, explanations, and a set of disks to use to create the copies if they didn't use an image duplicator. They fobbed production off on another company who blithely used one of the cracking tools we were targeting to do the production run. If they'd used a normal image duplicator or our scripts everything would have been fine, but instead all the shipped copies came up in demo mode. Of course the game had to be recalled, and we missed the Christmas launch.
Copy protection (whether you call it copy protection or DRM) increases the costs and risks of production and just plain doesn't do anything more than flashing a "don't pirate this game" splash screen would.
Local privilege escalation.
The only purpose of secdrv.sys is to run games that depend on "SafeDisc" copy protection. If you don't play games on your computer (or you shouldn't... corporate users take note) you don't need it, and if you do you only need it to play games using this particular scheme.
This is a local privilege escalation exploit. An attacker will have to use some other exploit to get onto your computer before using this one to get system privileges. This is another reason for corporate administrators to eliminate the driver, since it can be used by employees to bypass local policies.
Makes me doubly glad I've stuck with Windows 2000 all these years.
Let's hope the EFF is prepared to go after one of the "good guys". They've got a relationship with Leahy, and they've lionized him in the past, but now it's time to call in their markers.
Making a joke of the legislative process, that is. :(
Not only do they have outrageous penalties written into civil law, but now they want to get the taxpayer to pay for their larcenous lawsuits? I think we need to recognise that the closest thing to real piracy in this situation is what the RIAA is doing. Not only have they been granted letters of marque by the US government to exact punishment in civil suits, but now they're getting the government to pay for it. All that remains would be for George II to start handing out knighthoods (after all, it worked for Francis Drake).
Getting fired for following appropriate policy is probably NOT a career limiting move.
First: She's always like, "I'm sorry, I don't know who you are." her policy is to never buzz anyone in. She angered the chairman once over it, who was talked out of firing her precisely because he's in the office like 3 times a year. She won't buzz people in and she's unrepentently steadfast about it. She's dumb as dirt.
She's not dumb, she's smart.
Second: Simple systems are more likely to be secure than more complex systems in general as they are less prone to component failure.
The Java sandbox is an extremely complex system, with trusted and untrusted code running in the same address space calling the same libraries, with the security managed by code that's also using the same libraries and running in the same address space. I am honestly amazed that it's worked as well as it has.
The multiuser protection in UNIX is an extremely simple system, with untrusted code running in separate address spaces and, traditionally, with the ability to run security applications using no shared libraries at all. It's also proven extremely effective, and it has the advantage that even if flawed code is run those flaws do not automatically provide an escape route from the whole sandbox the way flaws in libraries called from Java do.
This is not to say that the Java sandbox isn't a useful tool, but rather to say that when analyzing the security of the system as a whole the fact that an application is written in Java should not be given the kind of importance that it seems to be getting here.