Slashdot Mirror

The idea has been out there a long time.

You'll be happy to know that the MIT media lab is hard at work on your idea. Here are some related technologies: an emotional communication device and a a medium for intimate conversation.

I actually remember a talk at CHI about a vibrating vest or something like that for sending and receiving hugs. I also remember discussing with someone how they must have been discretely funded by the pr0n industry.

The "moving pieces on the board" task is a good example that "sentient AIs" can not be build inside a computer as we know it alone. This sort of tasks require more than just computation: they require interaction. That interactive process cannot be modeled by Turing machines was known by Turing himself, according to the following paper:

You may want to look at Peter Wegner's argument about Why Interaction Is More Powerful Than Algorithms, Communications of the ACM., May 1997 . (also available in the ACM digital library.)

Of course this could be for historical purposes, but is that still done in schools? Some bad habits die hard, I guess, but I thought that flowcharting was dropped when Dijkstra declared "goto" harmful. Flowcharting has given way to pseudocode and for some UML (not that it shouldn't go the way of flowcharting, but every tool has its purpose). It's a very dangerous way of looking at coding, as it discourages abstraction, assumes a global data space (when scoping is essential to modern programming), and allows for arbitrary jumps from point to point (i.e. goto). Of course this could be all part of the lesson, but in case it isn't, I just want this student to know that there is so much more to visual software design. Of course, UML is popular these days, and for user interaction, there's the Visual Interaction Vocabulary by Jesse James Garrett. There are lessons to be learned from Flowcharting, but mostly about what to avoid.

You're talking about Ken Thompson's paper, "Reflections on Trusting Trust".

I don't believe this ever was a "famous hole in cc". Instead, Ken Thomspon merely pointed out that trust in the code you were compiling was not enough; you would have to trust the compiler as well, which inherently meant you had to trust the compiler compiling that compiler, and so on. Essentially the only compiler you could trust is one you wrote yourself in machine code, otherwise you can't be sure what its compiled, binary form contains.

Whether anyone ever acted on this potential exploit is up for further research, but for it to be effectively done in Open Source, it could only be executed on a per-machine basis. That is, they'd have to change the compiler on your machine, because if they put the exploit right in publically available source code, it wouldn't be too difficult to find it when the code was reviewed.

What I find interesting is that this is listed as a "Classic" article, and that page is dated 1995! This idea has been out for a while.

Even if you do have a compilable version of the sourcecode, you cannot be totally sure:

See Ken Thompson's brilliant backdoor in gcc

It's LaTeX using the ACM template that you can get from here I have used it myself a couple of times. It's really nice.

For example, one of the Bell Labs' UNIX gods (I forget which) demonstrated how a C compiler could (a) insert backdoor binary code into applications it was compiling and (b) recognize when it was compiling itself and insert the backdoor-inserting code. Thus none of the source files, for either the compiler or the application, showed that there was a backdoor. They were making the point that the system is not secure if you're initially dependent on some chunk of binary code (or at least you have to analyze that binary, which is much more difficult).

I believe you are talking about Ken Thompson, in Reflections on Trusting Trust:

http://www.acm.org/classics/sep95/

... one of the Bell Labs' UNIX gods (I forget which) demonstrated how a C compiler could (a) insert backdoor binary code into applications it was compiling and (b) recognize when it was compiling itself and insert the backdoor-inserting code

There is still an active APL community and there are APL implementations for Linux, UNIX, MacOS, OS/390, Windows...
After APL, Ken Iverson created J, a dialect of APL that uses the ASCII character set.

LIke Jeff Raskin's.

The [trojan or back-door] logic could be so well hidden that not even a careful review of the machine's source code would find it. This isn't as far-fetched as it might sound: Unauthorized features called "Easter eggs" are routinely hidden in commercial software, even software shipped by Microsoft.

(Emphasis mine). Bullshit! Careful review of source code finds as much as it wants to.

I guess you've never read Ken Thompson's Reflections on Trusting Trust, in which he describes how he hid a trojan password in the Unix login program which could not be found by inspection of any source code. Both the login program and the C compiler were compromised in a masterfully clever way. The resulting backdoor was present for years.

The author of this article suffers from an either/or, electronic or paper ballot, mindset. As I've said before, I like the mechanical lever machines best of all. Short of buying off every inspector at a polling place, there's practically no way to corrupt the results.

The ACM Digital Library saved my ass several times during my undergrad for sure. It was nice being able to look at the actual paper published describing an algorithm or data structure, for example, when trying to complete a programming assignment that involved it.

Call me a nerd, but journal articles are still interesting reading just so you can keep up on what's the state of the art, as well as being able to look back on some of the more famous pieces of published work... take Dijkstra's "Goto Considered Harmful," for instance.

Granted, the ACM library may not be free, but I know that my university's entire /16 worth of IP address space was covered under a site license, so your school might also have such an arrangement.

Taking email to task: the design and evaluation of a task management centered email tool, Victoria Bellotti, Nicolas Ducheneaut , Mark Howard, Ian Smith, CHI 2003, pp 345 - 352

Available from the ACM Digital Library if you've got access.

Your program won't work. It'll just keep prining out 1's indefinitely.

(I'm assuming that you forgot or HTML ate your less-than sign in line 130. Even so, it still won't work.)

You never closed your "for" loop with a "next." Instead, you cobbled together two ways of doing the same thing, repeatedly sending the program from line 130 to 100, where i gets re-set to 1 every time. You needed to either:

100 for i=1 to 10; print i; next; end

or:

100 i=1
110 print i; i=i+1
120 if i=11 then end
130 goto 110

The second example is not particularly elegant, but it'll work.

The ACM's position on the licensing of software Engineers is that licensing - even for safety reasons - is neither effective nor desirable. A similar perspective on licensing in general may be found here.

A lot of people think unionizing is for lower-paying, lower-skilled professions, but historically, high-skilled workers (draftsman, architects) were the FIRST to organize, both to counter unfair competition and lower-quality work.

Target companies that outsource labor

For Shareholders:

• Demand the project timelines for each project using outsourced staff
• Expose the slippage
• Highlight systems failures that involve outsourced labor
• Ask "what's the value"?

For the general public:

• Question the sending of citizen information overseas
• Expose companies that do
• Employ direct action (confront the person responsible, ask him to stop) to get more attention

At the same time, technical professionals need to raise the profile of this field. Recently the State of Texas had some story recommending not to accredit software engineers because software types were not subject to the same stringent safety responsibilities that physical engineers are (indirect mention). Techies need to combat this directly by organizing into professional unions that discourage bad programming (code-like-Hell), bad security (Microsoft), and bad data modeling.

But most of all, we need to take the fight for ourselves. In the beginning, we don't need the sympathy of the American public. Even if the US public is not inclined toward the tech worker, they're not inclined against them either. Everybody likes to hear the story of a group fighting back to rightfully protect their jobs.

ORGANIZE.

For more information, check out From the People who Brought you the Weekend , The Activist's Handbook and Organizing for Social Change .

It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. ...[W]e asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to... In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

Hoare, C. Anthony R. "The Emperor's Old Clothes." Communications of the ACM, Vol. 24, No. 2, February 1981, pp. 75-83.

His award from the ACM was for his fundamental contributions to the definition and design of programming languages.

Sir Tony Hoare has worked for Microsoft since 1999.

It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. ...[W]e asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to... In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

Hoare, C. Anthony R. "The Emperor's Old Clothes." Communications of the ACM, Vol. 24, No. 2, February 1981, pp. 75-83.

His award from the ACM was for his fundamental contributions to the definition and design of programming languages.

Sir Tony Hoare has worked for Microsoft since 1999.

Tempting to mod that down, but instead I'll reply with a correction.

This is the correct paper:
Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)

This is the abstract you read:
Robustness to Inflated Subscription in Multicast Congestion Control

These are separate papers by different authors. The TCP DoS does not involve Multicast.

Tempting to mod that down, but instead I'll reply with a correction.

This is the correct paper:
Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)

This is the abstract you read:
Robustness to Inflated Subscription in Multicast Congestion Control

These are separate papers by different authors. The TCP DoS does not involve Multicast.

I think you've been mislead by a previously posted bad link. Look at the correct paper here.

That's the wrong link the correct link is here.

At least a few people are already confused by this and think the attack is only for multicast group subscription (the paper the parent links to).

Uh, click on the word "paper" in the story, then click on "This paper is available in Adobe PDF format."

Or Cick Here

When the number of flows in the system is high, a fraction of flows' retransmission timers will expire sufficiently near time (alpha) such that those flows can partially recover and utilize the available bandwidth in the period from time (alpha) to time (beta), when all flows will again experience an outage.

DIY AI (Do-It-Yourself Artificial Intelligence) is now available to provide AI Minds for these "Executive Secretaries" in a growing list of programming languages:
APL;
JAVA (see code-link #001 :-)
Labview;
Lisp;
Perl;
Python;
Visual Basic (see link #001 :-)

The Technological Singularity of Vernor Vinge is happening right here and now -- all around you.

Please mod up this message as high as it deserves. If you doubt the AI Mind meme, please see
ACM SIGPLAN Notices: Mind.Forth AI paper by Dr. Paul Frenger;
Concept-Fiber Theory of Mind review by Ben Goertzel, Ph.D.

Every Slashdot-reading programmer ought seriously to consider dropping all other activities and joining the AI Revolution adumbrated in this SlashDot article on Executive Secretaries with AI.

BTW, if your system is compromised, compiling may not help.

Reflections on Trusting Trust, Ken Thompson

For those interested, the paper is available from ACM's digital library.

Need I say more?

which is why you should use latex! nobody understands that stuff. security through obscurity!

Some of the ideas presented in the Anti-Mac interface (Google Cache) guildlines. Also, this reminds me a lot of some research that was done by Douglas Hofstadter and Melanie Mitchell and described in "Fluid Concepts and Creative Analogies". I highly recommend the book if you are interested in AI.

definition
Architectures and Compilers to Support Reconfigurable Computing
brass

Houston Chronicle article on court case.

Novell wins one in Illinois.

The National Society of Professional Engineers doesn't want riff-raff.

IEEE Computer Society sasy NO, at least in Texas.

ACM editorial saying we shouldn't call it engineering anyhow.

Anyone have an address where we are supposed to send MD5sums?

Also, does this effect GCC sources?!?! See Ken Thompson's Reflections on Trusting Trust.

-molo

Of course, Ken Thompson has said some very interesting things about trusting code and compilers. The only way to really trust the code would be to hand code/compile/enter your own compiler in asm, and use this to bootstrap a more powerful compiler etc, until you were able to compile the code that you had reviewed and elected to trust. If you don't do it all yourself, you really can't be sure how trustworthy a binary is, your compiler might have done some dirty business behind your back.

Speaking of disney, I heard a report on NPR that Fritz Hollings, often refered to as the senator from Disney and sponser of such wonders of legislation as the Security Systems Standards and Certification Act (SSSCA), will not be running for re-election.

Article in the hollywood reporter (First link on new.google.com I found.
I'll be quite pleased to see him go, even though it may give the Republicans a bigger lead in the house. Probably the lesser of two evils.

Now that artificial intelligence (AI) has been solved, machine translation (MT) may advance to a higher plane of equality with human translators who spend years learning the nuances and subtleties of their target human languages.

Computer science has found the Holy Grail of AI in the Concept-Fiber Theory of Mind that led directly to the free AI source code of the Mind-1.1 Tutorial AI described in the AI For You textbook of artificial intelligence and robotics.

The Association for Computing Machinery has published an article on the robot Mind.Forth AI, and a well-known AI expert has favorably reviewed the Fiber-Concept Theory of Mind.

Traditional Artificial Intelligence Textbooks are suddenly obsolete, outmoded, or desperately in need of thorough revision and updating to teach Automatic Machine Translation now that AI has been solved.

> you'd -still- have to be sure
that -all- the executables
were made from the final source,

using a compiler that's known not to contain any code that can generate unexpected code from the supplied input... okay, so we need an open source compiler...

but how do we know that the compiler was compiled using a compiler that doesn't inject malicious code that would mean that the compiler compromised the ballot software?

You might want to check out this classic ACM paper

So you look at the disassembled binary code, and verify that it does what the sourcecode says, right? But then you have to trust that the chips do what the manufacturer tells you they do. Maybe you should dismantle the chips and get them under an electron microscope, verify that the gates and pathways all work according to spec... but what if the electron microscope is rigged to misrepresent certain images?

The thing is, you can't be certain that the intentions of sourcecode will be executed faithfully, without returning to first principles (basically the laws of physics), unless you start trusting some of the layers. And once you start trusting layers - say, the hardware layer, the compiler - why not extend that trust further up the stack? So, why is sourcecode access so crucial to trust?

What's important is that there be some external, verifiable proof that the machine results reflect the intentions of the voters. That means a system where the machine prints off a physical ballot paper, the voter checks it accurately reflects their vote, and deposits it in a secure ballot box. That way an audit trail exists that means that you can physically count the votes and ensure that the results are what the computer said they were. Source access isn't necessary to ensure this, just as access to electron microscopy of the chip surface isn't required.

Dijkstra was half joking, trolling even, in that remark about Basic. In the same piece are other hyperbolic comments such as "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." Have you really read any Dijkstra? He always seems level headed to me. Your rant seems to be about a different kind of person entirely. Are you seriously suggesting he should have been defending the status quo of Basic (and Fortran and Cobol)? That Basic is effective? If someone tells you goto is harmful, by all means try it out yourself, but also go and read the careful reasoning behind that little quote.

The eyes of people who read top-to-bottom, left-to-right will naturally gravitate first to the top left corner of a rectangular object containing text. Check out some usability studies to see what I mean.

Why would you trust the CRC?

this.

A well-hacked program will be completely invisible to you, as well. Your grep methodology is too simplistic to catch any sort of sophisticated trojan. Even if you were to laboriously go through the code, line by line, you still wouldn't catch anything but the most obvious of hacks/problems.

Here it would be fitting to point the original poster to Ken Thompson's Turing award speech, Reflections on trusting trust.

To quote:

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

Ok, why don't we take it a step further. How do you know that you can trust the C compiler? You sure got the binary for THAT, right?

Reflections on Trusting Trust

Don't get me wrong, my point is that most people are perfectly happy putting their trust in the maintainers of binary packages and do not want to look at the src/ of everything they want to install.

For example, if it's not a networking application, then I'll usually grep for system calls like connect() or bind() .. a dead giveaway that somebody has tried to slip some kind of a backdoor into the code. If I find something like that, I rm -rf it and forget it. You can also search for calls like gets(), strtok(), fopen(), and other well-known security risks and fix them if you feel like it.

I have two questions. What percentage of the packages you use did you download the source for and grep through? And how many of them did you find trojans in?

If you have not checked your trusted base (kernel, compiler, linker, libraries and whatever tools you use to look at the code), then you can never be completely sure. See Ken Thompson's article, Reflections on Trusting Trust for an excellent explanation of why.

Read here to find out why:

Filed brief supporting the petitioner: INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS
(i.e. The IEEE supports copyrighted laws)

Support the ACM - they have better policies!

See slides or more details.

In response to the statement: "Even if electronic voting machines can be made to work (this requires open-source software, ..."

We ought to remember Ken Thompson's famous ACM lecture about how he might have hidden a trojan horse in the Unix login program by buggering a version of the C compiler so that it could not have been found by inspection of the source code.

See: http://www.acm.org/classics/sep95/

The bigger issue is not where the code is written, it's whether you can audit the source yourself (and whether you actually do so.

See reflections on trusting trust for a nice article about why, if it really matters, you should be careful with other people's code.