Digital Camera Image Verification
Polo writes "While reading dpreview, I noticed that among several new products, Canon has announced a Digital Image Verification Kit to prove that an image taken by a particular camera has not been modified. It's disturbing to think about the conditions that would allow digital images to be accepted in a courtroom. I guess one defense would be to figure out how to 'verify' a photo of shark attack..."
What has happened to me?
I know that captchas in use at Yahoo! such as The Gimp and Trotsky (cute names, heh) are effectively OCR proof (~20% success rate, IIRC) but what about the security codes which have been used on blogs? As a Movable Type user, I'm concerned about the recent spate of crapflooding caused with this script and even though the implementation of captchas as security codes has slowed the advances of crapflooders, are there any other forms of image verification in the pipeline which we can use?
FloodMT: crapflood Movab
Isn't it? How everyone is a fucking rocket scientist when it comes to warezzzzzzing the numbers on some picture of a sunset or some midwestern tourist landmark, but seven-letter words are beyond spelling correctly.
By the way, just to wander completely off-topic, Red Hat 9 is broken out of the box. The install program is enough to drain every last glimmer of light and goodness from a room, especially when it fails at 78% 11 times in a row, and then fucks itself into an infinite loop of "broken! try again? broken!"
Memorandum: An install program should always always ALWAYS have an option to continue CURRENT ERROR NOTWITHSTANDING unless that error involves a 50-foot wide chasm opening directly under the workstation.
By way of contrast, Red Hat 5.2 NEVER EVER, not even ONCE failed to install correctly.
</rant>
Yeah, yeah. -1 Off-topic, troll, flamebait. Whatever. I've got about 879 karma anyway.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
Much of the commentary on the SCO distributed denial of service scenario, including our own, has been based on the premise that SCO badly wants to keep their web site running. This may not be the case: unlike Microsoft, which has a real business to run and a real need to keep its web site operational, SCO Executives may not strongly care about the availability of www.sco.com. After all, Michael Doyle's half a billion dollar patent win against Microsoft scarcely hinged on the response times of the Eolas web site.
/. Effect when the bomb hits.
In fact, the author of the MyDoom virus has delegated control of directing the most enormous volume of http traffic that the Internet has yet seen to hostmaster@sco.com. On a whim, SCO can direct that Tsunami at an object of their choosing, simply by changing an A record in named.conf in time for the change to propagate by Sunday.
In this context, SCO Executives may have latitude to consider alternative defenses which do not involve having to parlay with low-down-no-good-Linux-loving-CDN-providers.
Solution 1: Move the SCO site to somewhere that has the clue and the clout to cope.
Consequences: SCO Executives buy a small business shared hosting account at Yahoo, noting that it runs on FreeBSD, not Linux, and point www.sco.com at the new account.
webhosting.yahoo.com stays up, and serves all the http requests from the infected machines at the same speed that the www.yahoo.com front page normally loads. Virus author kicks the cat in frustration. SCO's entire corporate cash resources exhausted by Yahoo's bandwidth surcharges in the first eight minutes. Yahoo pre-announces record quarter for hosting division.
Solution 2: Take www.sco.com out of the DNS.
Consequences: Everyone has a quiet weekend. SCO Execs drink Budweiser and watch the Superbowl. Global media considers that the virus author "has won". Anti-virus company Execs do not return journalists' calls on "What was all that fuss?"
Solution 3: Point www.sco.com at someone you don't like.
Consequences: SCO Executives take a poll on which web site annoys them the most. Slashdot wins. hostmaster@sco.com CNames www.sco.com to slashdot.org. SCO Execs cackle demonically at the prospect of slashdotting Slashdot.
Linux community notices DNS change propagating within five minutes. Eric Raymond calls for "restraint in the face of SCO's continual provocation". Undeterred, Linux community launches internet-wide round the clock hackathon, and finds six "trivially insecure" US military installations shortly after the US military go home on Friday afternoon. Spend Saturday soaking up the totally awesome graphics on the Stealth bomber flight simulators, and then obliterate most of Utah, sco.com name servers and all, on Sunday morning hours before the DDoS is due to hit Slashdot. SCO Execs still laughing themselves helpless about the
New, previously unknown Linux Thought Leader declares that "we have met the enemy, and they are gone". Traffic to Slashdot triples, Hemos weeps about the size of OSDN's unsold banner inventory. Follow up posts enthuse about the quality of the stealth bomber user interface, then propose that they should sort out "the problem in Redmond" before they give the US Military their network back in time for Monday morning. New Linux Thought Leader concurs, adding that there's a carding site in Moscow that really ticks him off, too. Armageddon.
Solution 4: Get to the Windows machines before they go off.
Consequences: SCO executives persuade Slashdot readers that Windows machines are their common enemy and that the enemy of my enemy is my friend. Someone in the Linux community notices Colin Percival's Depenguinator program, and considers that with some minor modifications, it can be distributed by the MyDoom virus, and as its payload, download and install Debian 3.0r2, KDE, Open Office and Evolution. Changes name of program to "De Penguinator".
Entire set of infected Windows machines is reached and either co