Slashdot Mirror

Also remind him that it still didn't ship bug-free.

... when the policy enforced by the program is broken to begin with?

From TFA:

The university's grading system, eGrades, is an in-house program that professors can access via the Internet to submit and alter students' grades. eGrades uses UCSB NetID, a campuswide authentication system, to check a user's identity. If a user forgets their password, they can reset it by entering their Social Security number and date of birth, Schmidt said.

This is evil. SSNs and DoBs are far too easy to find. The suspect worked for an insurance agency, but it would not be difficult to find this information through other means.

For more examples of such problems in systems, check out Risks Digest.

Well, on the back of that, in the latest Risk Digest (Here), Walter Dnes points out:

"perl used to be a "Practical Extraction and Reporting Language". Now it's
ballooned into something huge, requiring support libraries of its own.
Don't get me wrong, perl is an OK operating system, but it lacks a
lightweight scripting language."

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

As mentioned in a reply to a AC further up -

If you design anything destined for public use, please, please read through the Risks Digest. This mailing list is 20 years old and is described as a "Forum On Risks To The Public In Computers And Related Systems". It's good to browse through - often simple things end up getting someone killed, like the woman who drowned in an elevator that returned to the flooded ground floor of a building when a fire alarm went off.

A few snippets :

French motorist obeys GPS navigation, makes U-turn into traffic
Air Traffic Control blacked out by rodent
The risks of zero feedback
Shutting the train door before the commuter has bolted?

This is (and I do recall the specific details) a very suspect story for one reason :
Your car has an engine with (perhaps) 200HP
Your car has brakes with a stopping capacity of 2000HP for short periods of time. Think. It takes (say) 10 seconds to get to 60MPH, but only a few seconds to slam on the brakes and come to a halt.

Accelerating out of control to 200km/h? No problem. Stand on the brakes. Real hard. You will stop.

For those of you interested in the way computers interact with the world in unforseen ways, check out the Risks Guide. This mailing list has been going strong for 20 or so years with all the joys of that design and unintended consequences can bring. I believe anyone building something available to the public should at least browse through the list.

I know the software folks here on /. always want to make excuses about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated. complex systems are designed and built every day in the aerospace field, systems that many lives depend on.

Which is precisely why there has never been a software glitch in a plane system. You know, like the TCAS system which saw ghost planes and told pilots to avoid them (noted in IEEE Spectrum), or any of the cases cited here or here. Nope, aerospace engineers never screw up.

We do deploy equipment into life critical situations, so, for our work, 'shit happens' and 'i forgot' just dont exist in the vocabulary.

Funny you should mention life critical because one well known software glitch was the THERAC-25 which killed 6 people due to 2 software bugs.

We use checklists to ensure that all testing covers all forseeable abnormal conditions, up to and including partial failure of various hardware.

Which means your software barfs in unforeseeable situations and in cases of full hardware failure. Thus, your software is not fail-safe at all. Welcome to the real world - shit happens whether you like it or not. The unforeseeable will eventuate and no matter how much redundancy you have it is still possible for all the systems to fail at once. Denying that that possibility exists is unprofessional and dangerous.

Maybe, but sometimes shit just happens, regardless of design.

I find this Risk site to be very interesting reading, especially when it talks about some failure issues and scenarios.

My favourite was about Squirrel that took down the Nasdaq. (I've also heard squirrels/mice/rats etc called "self propelled short circuits", but that's another story)

Now, I've been involved in systems architecture design, planning, and management for years, and I think that a lot of people drastically underestimate just how fscking complex and dificult proper planning, execution, testing, maintenance, and administration of these systems can be... especially when faced with budgetary restrictions.

The cost of a system rises almost exponentially as you approach 100% uptime... even 99.999 is freaking expensive to implement and manage. Never mind the complexity and administrative requirements.

Who knows... maybe dealing with the PR issues of this outtage is still orders of magnitude cheaper in the long run than putting in the systems required to achieve the uptime.

At the end of the day, what are the business impacts of this outtage? For that matter, they seem to have received more exposure than if they were operating normally.

A lot of people are aware of the fact that sometimes things break, and we're not landing planes in the fog here. The fact that shit broke and they're bringing it back in an informed and somewhat timely manner may HELP them, in that some people may get a stronger sense of "these guys can deal with problems that hit them".

Maybe, but sometimes shit just happens, regardless of design.

I find this Risk site to be very interesting reading, especially when it talks about some failure issues and scenarios.

My favourite was about Squirrel that took down the Nasdaq. (I've also heard squirrels/mice/rats etc called "self propelled short circuits", but that's another story)

Now, I've been involved in systems architecture design, planning, and management for years, and I think that a lot of people drastically underestimate just how fscking complex and dificult proper planning, execution, testing, maintenance, and administration of these systems can be... especially when faced with budgetary restrictions.

The cost of a system rises almost exponentially as you approach 100% uptime... even 99.999 is freaking expensive to implement and manage. Never mind the complexity and administrative requirements.

Who knows... maybe dealing with the PR issues of this outtage is still orders of magnitude cheaper in the long run than putting in the systems required to achieve the uptime.

At the end of the day, what are the business impacts of this outtage? For that matter, they seem to have received more exposure than if they were operating normally.

A lot of people are aware of the fact that sometimes things break, and we're not landing planes in the fog here. The fact that shit broke and they're bringing it back in an informed and somewhat timely manner may HELP them, in that some people may get a stronger sense of "these guys can deal with problems that hit them".

There were a number of non-critical systems that failed. As always, the RISKS digest is a good source. See the bottom of this page, from volume 20 issue 72 onward.

I'm not sure whether you intended to suggest that OpenBSD led the way on marked pages, but even if you did not someone else might read it that way. This kind of feature is much older. One of the comp.risks posts sums it up:

Buffer overflows and Multics?

Tom Van Vleck

Mon, 23 Feb 2004 16:23:45 -0500

To make a big deal out of providing the 40-year-old feature of marking a region of memory non executable is kind of sad. Multicians look at each other and make the rubbing-sticks-together gesture.

It seems to me that the marketing guys and the popular press writers don't understand the feature, the need for the feature, or what the feature will and won't accomplish.

It's not magic. It fixes some common problems, leaving other problems untouched. It's not a substitute for defensive coding and proper management of storage; all it means is that if there is a mistake, it is more work for an attacker to exploit it.

As Paul Karger points out, when attackers are frustrated by one measure, they don't abandon their attacks. They keep looking for other holes. A fix like this, applied by itself, will lead to a new equilibrium between attackers and defenders, maybe favoring one or the other, but the game will remain the same.

Closing one open barn door is good, but it needs to be complemented by a systematic approach to enumeration of openings, and a method of closing the openings by architectural design that applies to all openings. So I was taught by my leaders on the Multics project, including Corby, Bob Morris, Jerry Saltzer, Ted Glaser, PGN, and many more.

cubicledrone wrote:

The written word is the basis for the entirety of civilization. Without the written word we would still be wandering around looking for food for a living.

This is, most likely, untrue: Written language is only known to date back about 5,500 years while agriculture is thought to date back 10,000 years or more. The written word can hardly be the basis of agriculture if it post dates it.

From comp.risks. Peter Neumann is a respected analyzer of risks.

Some 2004 voting anomalies
>
Mon, 8 Nov 2004 16:01:13 PST

For those of you interested in following a collection of reported problems
more carefully, here are just a few reported anomalies, collected from a
variety of sources:

* Palm Beach County logged 88,000 more votes than people who had voted in
the presidential race. (Teresa LePore of 2000 Butterfly Ballot fame is
the County supervisor of elections there.)

* A Franklin County Ohio machine error gave Bush 3,893 extra votes in a
precinct in Gahanna. The correct totals were 365 for Bush, 260 for Kerry.

* In Broward County FL, in balloting for Amendment 4, ES&S software for
tabulating absentee ballots began counting BACKWARDS once a total of
32,767 [2^15 - 1, in a signed 16-bit field] votes had been reached in a
precinct. When this was discovered, the corrected totals for the precinct
went from 166,000 to 240,000, and actually caused the statewide results to
be reversed on this amendment. Apparently the same flaw was detected two
years ago in the same software, and remained uncorrected.
Nick Simicich wondered in a long message to RISKS:
Do you suppose that they "fixed" this by making the 16 bit field
unsigned? Or do you suppose that they counted the numbers separately
using, say, floating point so that they could check the results for
large discrepancies? Or maybe that they checked the before and after to
see that the numbers increased when they added to them...or anything
else that they could do to make this self auditing? Nah...frankly, I'm
scared by the stupidity of this error. This is a problem that needs an
open source solution.

* The failure of the ES&S ranked-choice vote-counting software in the San
Francisco Supervisors' election that I noted in RISKS-23.58 turns out to
have been a hard-coded constant maximum number of voters that was set too
low. The fix was utterly trivial, but wisely required recertification by
the State. [Perhaps the same programmer wrote the Broward software?]

* Bev Harris reported that ``Jeff Fisher, the Democratic candidate for the
U.S. House from Florida's 16th District said he was waiting for the FBI to
show up. Fisher has evidence, he says, not only that the Florida election
was hacked, but of who hacked it and how... In Baker County, for example,
with 12,887 registered voters, 69.3% of them Democrats and 24.3% of them
Republicans, the vote was only 2,180 for Kerry and 7,738 for Bush.... Dick
Morris [famous consultant to both parties, now with Fox News] wrote "So,
according to ABC-TVs exit polls, for example, Kerry was slated to carry
Florida, Ohio, New Mexico, Colorado, Nevada, and Iowa.... Exit polls
cannot be as wrong across the board as they were on election night. I
suspect foul play." '' [See http://www.blackboxvoting.org , *NOT* .com]

* Incidentally, Ralph Barone noted an article on the internal database
structures of the Diebold voting machines, plus how to hack an election
and cover your trail afterwards.
http://www.blackboxvoting.com/scoop/S00065.htm

* There were numerous reports of screens "jumping" votes in ES&S and Hart
InterCivic machines, where casting a straight-party subsequently changes
the vote for the President before exiting.

* Also reported were many cases of long lines and long waits only in certain
politically skewed precincts, many legitimate voters who claim they were
disenfranchised, voters who were given special optical scan pens that were
not capable of being tallied, and so on.

Many Web sources provided running lists of reported anomalies, such as
http://www.votersunite.org
http://fairvote.

I have heard that you can make biodiesel, and it burns cleaner than diesel. I'm sure that rather than burning coal, we could use biodiesel instead. Of course this would mean plant conversions. Not sure what else. Coal is a limited thing and once it is gone its gone. Biodiesel well from dictionary.com http://cancerweb.ncl.ac.uk/cgi-bin/omd?query=biodi esel&action=Search+OMD I don't see why it couldn't be used instead. Give some farmers something to grow.

If you're suggesting that any of the examples you cite above have reason to be connected to the Internet go read the comp.risks archive, starting from the beginning. /bot indeed.

The German language article says he came to a stop about 20km before a toll booth...

On the same theme: Saturn made a interesting assumption about their cars a few years ago. At high speed they reduced gas to the engine to control the speed to a maximum of 105mph. According to this entry in Risks digest (source of endless scary stories about computing and automation risks) the author was left going down hill at over 105mph, coasting, with a stalled engine, no power brakes and no power steering.

... not fun at all...

Audi had a problem years ago that was supposedly due to a programming error. At low RPM the computer would increase power but fail to sense it under some circumstances. Net result: your car would suddenly go foot to the floor while you were stopped at a red light.

Oh... I get it now...
Guess I'm just too young to remember such classic jokes...

So, umm, you were saying?

I'm not sure, but I think you are referring to what I mentioned in an earlier post of mine. Funny you should bring it up; it was quite long ago... :)

A recent post by Dan Wallach to the RISKS digest describes how Dan managed to fly from Houston to Chicago, visit Fermilab, and fly back to Houston without having to show a photo id.

Read what the RISKS Digest has to say about SPF:

http://catless.ncl.ac.uk/Risks/23.21.html#subj7.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj9.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj9.1

Read what the RISKS Digest has to say about SPF:

http://catless.ncl.ac.uk/Risks/23.21.html#subj7.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj9.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj9.1

Read what the RISKS Digest has to say about SPF:

http://catless.ncl.ac.uk/Risks/23.21.html#subj7.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj9.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj9.1

Read what the RISKS Digest has to say about SPF:

http://catless.ncl.ac.uk/Risks/23.21.html#subj7.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj9.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj9.1

Read what the RISKS Digest has to say about SPF:

http://catless.ncl.ac.uk/Risks/23.21.html#subj7.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.21.html#subj9.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj8.1

http://catless.ncl.ac.uk/Risks/23.23.html#subj9.1

...the ballot in question was NOT designed by "partisan amateurs, one from each party" but by partisan amateurs from ONE party. The counties in question were all Democratic strongholds and the officials that designed & approved the ballot were all Democrats. There was no "outsmarting" by Republicans, aside from perhaps doing a more competent job in those counties where they were the ones in charge.

Since what you have written here runs directly counter to the homework I did at the time, I am going to paraphrase it, to make sure I understand what you meant.

Are you saying that whatever party has been elected to hold the offices that control the County aparatus, appoints all the ballot design commissioners?

Weren't Republican Party officials saying "The Democrats signed off on the ballot design too!"

Every independent recount using every method of dealing with pregnant/hanging chad have almost always come back with victories for Bush.

Really? And what methods were those?

How many of those recounts were done bearing in mind Dr Jones work? IMO, All recounts that were done without considering Dr Jones examination of the mechanical design flaws of the voting machines were a waste of time.

If I were an American I would be really embarrassed by the dubious election practices that were exposed to World scrutiny during your last Presidential election. Putin's last election was questionable. It could be argued that your mess had undermined your moral authority to point a finger over his fraud.

These obsolete punch card ballots were a disaster, but at least they provide some kind of audit trail. One the long running RISKS digest one of the topics discussed is the implementation of new technology for voting. There is universal agreement there that voting machines provide an audit trail. The old mechanically interlocked lever voting machines dont' provide an audit trail. Neither do the new systems, like the Diebold.

And yet various American jurisdictions have recently adopted the unsafe, unverifiable electronic systems.

"Under a $1,000,000" is a mere bagatelle, the failure to check for arithmetic overflow cost the European Space Agency two Communications Satellites at well over 600,000,000 Euros. For more such fun see Forum On Risks To The Public In Computers And Related SystemsForum On Risks To The Public In Computers And Related Systems

We believe in it.

The signal to noise ratio can get pretty bad at times, but there are always intersting discussions.

The Risks Digest is also pretty interesting.

Are you counting the votes of overseas military/civvies?

I dunno. Does the USA have 16 million overseas voters? Lol.

Also, the dems brought out the 'hanging chad' and 'voters are too fucking stupid to read candidates' names' ploys. I found it totally freaking hilarious that it was only Al Gore supporters who claimed to have been 'confused' by the voting slips.

Are you familiar with what detailed examination of the voting machines revealed? Dr Jones disassembled one each of the two different machines in question. Here is a picture showing the structural bar that caused the problem. Here is a picture showing how the chads can be jammed behind the bar. Here is a picture of Pregnant chad resulting from punching into a firmly packed chad jam.

The ballot design put the location to punch for Gore right over top of the structural bar. Duh!

Down in the USA you follow the foolish practice of letting every county design its own ballots. Amateurs design them. Partisan amateurs, one from each Party. Here in Canada there is a standard, simple, ballot design.

If you were paying attention during the followup to the election you might have noticed that the Republicans were not defending the ballot design. Instead they merely pointed out that the Democrats signed off on it too.

Ballot designs that resulted in disproportionate numbers of chads for one candidate had been observed in previous Florida elections. It appears to me that the Republicans ballot designers were better informed than the Democrat ballot designers, and outsmarted them.

I think it's downright rude to fake your reply-to address in public forums, requiring your recipients to try to guess what your real address might be and I never answer to people who require me to remove this or that, do a ROT13 on their .sig and hop on one leg barking like a dog before replying.

The only time I use "fake" address is when I sign-up to things which seem to require e-mail address for no good reason; I have a /dev/null mailbox address set up for those sites.

My domain gets tons of spam, but my filters take away 99% of it, occasionally new innovative spam gets through before SpamAssassin/Razor/other RBL's catch up with it, but personally I don't really see it as a very big problem (don't get me wrong, spammers should die, I just don't want to add to the resource waste by faking my address).

If you're going to use a fake address, then use example.com (which is meant for this type of thing) or at least make sure your address is invalid so that SMTP servers reject it immediately instead of trying to deliver to existing domains.

This isn't exactly new thing, have a look at this Risks Digest post from 1997 (!): http://catless.ncl.ac.uk/Risks/19.04.html#subj9.2

Would be nice if at least we /.-ers who are trying to be on the bleeding edge of technology would try to solve these problems instead of being part and escalating them.

I think it is safe to assume that such tags are as temporary as the current Paper ones that they attach to luggage or boxes.

I do, too - but we're hoping for the best. Other posts wrongly ASSume that all RFID tags within consumer goods will be as easily removed...

The potential for abuse is obviously greater than barcodes, which are (duh) visible. Many, many fears about this technology would be alleviated if the presence of RFID tags was not surrepitious. Instead of treating all customers like dolts, let's see our corporate overloads bend over backwards to inform us and dispel the misinformation... or (sigh) perhaps they should be forced to disclose this - at least in the case of soft goods such as deodorant and sweaters! - as display some prudence and respect for their prey.

when the Government mandates that all luggage travelling on planes require special 'government-approved' Travel tags

The way airlines are bending over for the Government in matters of data "sharing" - which perhaps they must, or should - and then proceed to lie about it in some cases, the transition from corporate overlord tag to Government tag may get blurrier before we know it...

As another poster sagely said, "The more you rely on a system like this, the more it can hurt when a wrinkle comes along." There have been some pretty disheartening cases this year where Gov'mint officials refused to doubt the accuracy of their databases.

It's disappointing to see geeks ridicule other geeks for even attempting to acknowledge the Law of Intended Consequences. The faith of some in the benevolence of corporations and bureaucracies - future ones as well, building on the things we tolerate today - is vast and, well, stupefying.

<grrr>

I think it is safe to assume that such tags are as temporary as the current Paper ones that they attach to luggage or boxes.

I do, too - but we're hoping for the best. Other posts wrongly ASSume that all RFID tags within consumer goods will be as easily removed...

The potential for abuse is obviously greater than barcodes, which are (duh) visible. Many, many fears about this technology would be alleviated if the presence of RFID tags was not surrepitious. Instead of treating all customers like dolts, let's see our corporate overloads bend over backwards to inform us and dispel the misinformation... or (sigh) perhaps they should be forced to disclose this - at least in the case of soft goods such as deodorant and sweaters! - as display some prudence and respect for their prey.

when the Government mandates that all luggage travelling on planes require special 'government-approved' Travel tags

The way airlines are bending over for the Government in matters of data "sharing" - which perhaps they must, or should - and then proceed to lie about it in some cases, the transition from corporate overlord tag to Government tag may get blurrier before we know it...

As another poster sagely said, "The more you rely on a system like this, the more it can hurt when a wrinkle comes along." There have been some pretty disheartening cases this year where Gov'mint officials refused to doubt the accuracy of their databases.

It's disappointing to see geeks ridicule other geeks for even attempting to acknowledge the Law of Intended Consequences. The faith of some in the benevolence of corporations and bureaucracies - future ones as well, building on the things we tolerate today - is vast and, well, stupefying.

<grrr>

Yup, they may not be saving the photos (uh, yet), their motives may be unimpeachable and the higher-ups in the police department don't care at all about the photos of non-criminals.
Again, it's the unintended "audiences" not initially anticipated that concern me more. Digital data, once captured, is so much more easily stored and indexed... more easily copied, merged...
Manipulated.

Are these photos in the public record? (Surely they're not all considered to be "work products of an investigation" ?!?)
Will they ever become publicly available? Who can say?
What industries might find them useful...?

We have no choice but to "trust" that a photo database has not been previously seeded with "false positives" to cast doubt upon it, and that the facial mapping algorithms or whatever are robust enough to make actual false positives rare (though what level of false accusation is acceptable, really, as a result of "B-but the computer says you're an escaped felon" ?) and that the people who just want to do their job and catch bad guys are not putting so much reliance on technology that they're "not seeing the forest for the trees".
This guy was jailed for two weeks, even though the authorities previously had a quick and easy way to confirm the fingerprint mismatch in his case - and this poor guy spent two months in custody, supposedly because a judge maintained that "fingerprints don't lie" !
Such things happened before a fingerprint database (just as inexcusable - this is not a matter of "accidents will happen", it's hubris) but the more an automated pattern-matching is end-to-end, the less chance human expertise and empathy and nonlinear thinking can prevent awful things like this. Given our Bill of Rights (even post-PATRIOT Act) the risk of false imprisonment should be even more miniscule than it is - decreasing as technology increases, if we're careful...!

Rear-view mirrors don't lie, but that doesn't mean they can be trusted to reveal everything that's actually there.

Now, videotaped traffic stops are a pretty good comeback. People's images are captured without probable cause - even if the officer is helping with a flat tire. But I don't know of a place (yet!) that requires people in the promixity of that constantly-rolling camera to hold still (submit) so a good, clear image can be captured. If suspects are being forced to do that now ("stand right in front of the bumper and hold still - you're on tape"), then I guess those municipalities won't be getting any of my discretionary spending.

If the data exists, there's no way to prevent it from being stored.
But if it never exists . . .
(A weak analogy would be a file of credit-card numbers. Without a sufficiently powerful reason for keeping them in one "convenient" place, the risk of that information being stolen, exposed or altered will always exist, especially if they're on a net-attached server.)

A case can be made (and invariably will be made ??) that's it's a doggone "waste" to collect information with taxpayer dollars, such as these photos, and then just throw it away, duplicate some of the effort on subsequent contacts with the same citizen, etc. etc.

Wal-Mart, et al. - certainly there are many more photos being snapped daily (even of "us xenophobes") than we would care to know about. But no corporation (yet) has the profound, unique and immediate power over my freedom that peace officers do.
A retailer which abuses their customers' trust will eventually be exposed, and hopefully will take a hit on the balance sheet as a result. A police department which is "bitten" by bad info (false positives) and/or negative publicity will either wise up or become known for their antics. I guess those who are sufficiently concerned about such things can move, or do more online shopping.
And if this level of "cooperation"

Yup, they may not be saving the photos (uh, yet), their motives may be unimpeachable and the higher-ups in the police department don't care at all about the photos of non-criminals.
Again, it's the unintended "audiences" not initially anticipated that concern me more. Digital data, once captured, is so much more easily stored and indexed... more easily copied, merged...
Manipulated.

Are these photos in the public record? (Surely they're not all considered to be "work products of an investigation" ?!?)
Will they ever become publicly available? Who can say?
What industries might find them useful...?

We have no choice but to "trust" that a photo database has not been previously seeded with "false positives" to cast doubt upon it, and that the facial mapping algorithms or whatever are robust enough to make actual false positives rare (though what level of false accusation is acceptable, really, as a result of "B-but the computer says you're an escaped felon" ?) and that the people who just want to do their job and catch bad guys are not putting so much reliance on technology that they're "not seeing the forest for the trees".
This guy was jailed for two weeks, even though the authorities previously had a quick and easy way to confirm the fingerprint mismatch in his case - and this poor guy spent two months in custody, supposedly because a judge maintained that "fingerprints don't lie" !
Such things happened before a fingerprint database (just as inexcusable - this is not a matter of "accidents will happen", it's hubris) but the more an automated pattern-matching is end-to-end, the less chance human expertise and empathy and nonlinear thinking can prevent awful things like this. Given our Bill of Rights (even post-PATRIOT Act) the risk of false imprisonment should be even more miniscule than it is - decreasing as technology increases, if we're careful...!

Rear-view mirrors don't lie, but that doesn't mean they can be trusted to reveal everything that's actually there.

Now, videotaped traffic stops are a pretty good comeback. People's images are captured without probable cause - even if the officer is helping with a flat tire. But I don't know of a place (yet!) that requires people in the promixity of that constantly-rolling camera to hold still (submit) so a good, clear image can be captured. If suspects are being forced to do that now ("stand right in front of the bumper and hold still - you're on tape"), then I guess those municipalities won't be getting any of my discretionary spending.

If the data exists, there's no way to prevent it from being stored.
But if it never exists . . .
(A weak analogy would be a file of credit-card numbers. Without a sufficiently powerful reason for keeping them in one "convenient" place, the risk of that information being stolen, exposed or altered will always exist, especially if they're on a net-attached server.)

A case can be made (and invariably will be made ??) that's it's a doggone "waste" to collect information with taxpayer dollars, such as these photos, and then just throw it away, duplicate some of the effort on subsequent contacts with the same citizen, etc. etc.

Wal-Mart, et al. - certainly there are many more photos being snapped daily (even of "us xenophobes") than we would care to know about. But no corporation (yet) has the profound, unique and immediate power over my freedom that peace officers do.
A retailer which abuses their customers' trust will eventually be exposed, and hopefully will take a hit on the balance sheet as a result. A police department which is "bitten" by bad info (false positives) and/or negative publicity will either wise up or become known for their antics. I guess those who are sufficiently concerned about such things can move, or do more online shopping.
And if this level of "cooperation"

To quote Linus Torvalds:

People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.

Unlike early post BSDi development of the "free" BSD's, almost all of the Linux kernel development took place in the open and over the internet.

In comparison Microsoft has "lost" the source to MSDOS and "deleted" CEOs email from it's servers. There is NO real public provenance to the source code to most of Microsoft's products. If this is, like the threat from patents is an issue then Linux is in a better postion than its competitors in the market.

Actually SCO systems were used in some tanks. There were stories going around about patches etc being downloaded in the field in the early 90's.

That's probably this one. Way back in REM-time, with BBS's still going strong.

The control system for the cabin of the Boeing 777 also used to run on UnixWare.

Not anymore; but I never really understood what a browser has to do with an operating system.

The FBI cannot make any person provide testimony which would be self-incriminating. If person A has been trading kiddie porn on Kazaa, they cannot make person B turn over the encryption key to the ZIP file that contains all of the kiddie porn he downloaded from person A.

Can you cite any relevant laws or cases?

The cryptonomicon FAQ states that this issue is still undecided. (see 10.3.4) Although I believe that page is quite old.

There seem to be a lot of issues here. My current understanding is that you should not expect to keep you encryption key secret.
This is mainly because a judge might hold you in contemp of court indefinately, until you gave them your key.

There seems to be a discussion of this very subject in Risks digest as well.

So far the only info I've ever heard on the subject is mere speculation.

Here's another discussion of the topic on the Rubberhose website (an encryotion scheme which offers deniable encryption).
It's by far the best discussion of the subject I've seen, but even this (with its 159 footnotes) refuses to make a conclusive judgement on the topic. It states what the courts "should" do, but wouldn't do me much good in a jail cell. It's seems like the privacy of your crypto key is quite debatable.

IANAL, but I am quite interested in this topic, and AFAIK the issue is still up in the air.

But then we (homo sap. sap.)are good at this: we can accumulate lead in our bones from drinking water or contaminated air, and I believe that mercury too can get collected by the body (gets resorbed in the lower intestine, I think.)

I don't really see why people haven't mentioned it earlier, but large scale systems development is hard.

We're not even talking about building something new here. It's re-implementing a 40-year-old legacy system, maintaining legacy data, and adding new features to bring it into the 21st century. The software engineering task is mind-bogglingly huge.

The IRS' problem, and others like it (FAA - Air Traffic Control System) have been going on for a long time. For a little history, check out Risks Forum Digest.

Regarding the IRS doing the development in-house -- While on the surface it may seem like a good idea, in practice it isn't. The IRS does have the domain expertise. But they don't have the experience with large-scale systems development. This is a situation where outsourcing to one of the large consultancies or gov't contractors really is a good idea. The challenge is have effective communication between the experts at the IRS and the developers, not just during requirements gathering, but throughout the software development process.

I don't really see why people haven't mentioned it earlier, but large scale systems development is hard.

We're not even talking about building something new here. It's re-implementing a 40-year-old legacy system, maintaining legacy data, and adding new features to bring it into the 21st century. The software engineering task is mind-bogglingly huge.

The IRS' problem, and others like it (FAA - Air Traffic Control System) have been going on for a long time. For a little history, check out Risks Forum Digest.

Regarding the IRS doing the development in-house -- While on the surface it may seem like a good idea, in practice it isn't. The IRS does have the domain expertise. But they don't have the experience with large-scale systems development. This is a situation where outsourcing to one of the large consultancies or gov't contractors really is a good idea. The challenge is have effective communication between the experts at the IRS and the developers, not just during requirements gathering, but throughout the software development process.

I don't really see why people haven't mentioned it earlier, but large scale systems development is hard.

We're not even talking about building something new here. It's re-implementing a 40-year-old legacy system, maintaining legacy data, and adding new features to bring it into the 21st century. The software engineering task is mind-bogglingly huge.

The IRS' problem, and others like it (FAA - Air Traffic Control System) have been going on for a long time. For a little history, check out Risks Forum Digest.

Regarding the IRS doing the development in-house -- While on the surface it may seem like a good idea, in practice it isn't. The IRS does have the domain expertise. But they don't have the experience with large-scale systems development. This is a situation where outsourcing to one of the large consultancies or gov't contractors really is a good idea. The challenge is have effective communication between the experts at the IRS and the developers, not just during requirements gathering, but throughout the software development process.

I don't really see why people haven't mentioned it earlier, but large scale systems development is hard.

We're not even talking about building something new here. It's re-implementing a 40-year-old legacy system, maintaining legacy data, and adding new features to bring it into the 21st century. The software engineering task is mind-bogglingly huge.

The IRS' problem, and others like it (FAA - Air Traffic Control System) have been going on for a long time. For a little history, check out Risks Forum Digest.

Regarding the IRS doing the development in-house -- While on the surface it may seem like a good idea, in practice it isn't. The IRS does have the domain expertise. But they don't have the experience with large-scale systems development. This is a situation where outsourcing to one of the large consultancies or gov't contractors really is a good idea. The challenge is have effective communication between the experts at the IRS and the developers, not just during requirements gathering, but throughout the software development process.

Also, I hope these servers are protected against EMP (Electro Magnetic Pulse) bomb

With everything being "off the shelf" hardware, how much emp it can take is a good question. There are test facilities.

I can understand mil-rad hardened transistors surviving, but all that stuff clearly has to use low voltage CMOS that can be blown if there is a nearby lightning strike.

I think most worrisome is a computer glitch (not to mention a bullet) hitting the right server at the right place to cause the ship to be dead in the water because engine/navigation controls don't work.

If it could bring down an Osprey helicopter, one has to wonder about ships also.

Being the military, they probably (or should) have taken such things into account when deploying the systems.

You also have to wonder how much time they spend patching all the software.

Who knows, but I can't get a Hotmail account using my real name

Reminds me of the case a while ago of AOL and the customer from Scunthorpe ...

(and that was 8 years ago, so the problem is not a new one)

Slashdot had a discussion about Programming Gone Wrong in the past.

It mentioned, among others, the Ariane 5 Failure, the infamous Therac-25 accidents, loss of Mars Orbiter, Hi-tech toilet swallowing woman, AT&T Switch failure, a bunch of things literally crashing, etc. And here is yet another article on miserable Patriot failure.

For professional assessment of risks, there is a Usenet group for RISKS Digest (Google groups) that describes all kinds of situations where technology has gone wrong.

Slashdot had a discussion about Programming Gone Wrong in the past.

It mentioned, among others, the Ariane 5 Failure, the infamous Therac-25 accidents, loss of Mars Orbiter, Hi-tech toilet swallowing woman, AT&T Switch failure, a bunch of things literally crashing, etc. And here is yet another article on miserable Patriot failure.

For professional assessment of risks, there is a Usenet group for RISKS Digest (Google groups) that describes all kinds of situations where technology has gone wrong.

I always had high regard for comp.risks, but I'm wondering if I should reconsider, seeing that they've stooped to quoting slashdot!