Slashdot Mirror

MS Office's behavior in this regard is not an innovation in UI design; this is a decades-old idea.

At a high-level, HCI research in this area will generally characterize an interface as static, adaptive or adaptable. Static interfaces never change, adaptive interfaces change based on the system's reaction to outside conditions including the users past behaviors, adaptable interfaces change when the user directs them to change.

Your preference that "the UI should not evolve or change with the user" describes a rejection of adaptive interfaces. And research (http://portal.acm.org/citation.cfm?id=985704&jmp=indexterms&dl=portal&dl=ACM/ gives a good starting point of references but you can easily find more by searching for "adaptive interface") supports your intuition that adaptive interfaces on computer software hinder users more than they help.

But that doesn't mean that UIs should be static. Research also confirms (again, see the previous citation for examples) that adaptable interfaces which allow users to customize the UI according to their preferences can let users be even more productive than a static interface.

Expose - Xerox "Rooms" (1985), AmigaOS WorkBench (1985), swm (1990)

Dashboard - Borland Sidekick (1984)

Spotlight - Lotus Magellan (1989), ISYS:Desktop (1989), dtSearch Desktop (1991), Enfish Find (2002), Copernic (2004), Google Desktop Search (2004)

.MAC - Online disk, email, backup, ecards and ratings were all extant by 1998.

I developed graphics workstation software in the period 1970-1990. There is an abundance of prior art for these claimed patents. Windowing and the idea of multiple views of a single workspace on a single display was commonplace during that period.

There were many academic papers and conferences; ACM SIGGRAPH publications go back to 1967 at least. By the time SIGGRAPH organized, the field of computer graphics was already well-established: many proprietary graphics systems were already in use in private industry and government. Newman and Sproull published their landmark text Principles of Interactive Computer Graphics in 1973.

Other especially good veins to mine for prior art are satellite imaging software for both government use (spy satellites) and for oil prospecting. Another active area was geophysical processing workstation software. The major oil companies were the non-military non-spy pioneers in these areas.

• "As a two-sided touch screen, the LucidTouch is a direct extension of our two-sided touch table, published previously as Under the Table Interaction (reference below).
  ...[snip]...
  Publications:
  Wigdor, D.; Leigh, D.; Forlines, C.; Shipman, S.; Barnwell, J.; Balakrishnan, R.; Shen, C., "Under the Table Interaction", ACM Symposium on User Interface Software and Technology (UIST), ISBN: 1-59593-313-1, pp. 259-268, October 2006 (ACM Press, TR2006-076)"

So is Apple copying Microsoft? Of course not. A table is not an iPod/phone is not a see-through tablet. As another replier mentioned, there's an obviousness about this "behind the screen" interaction. However, Apple fanboys (I'm not calling you one) like to think everybody's copying Apple.

Q: Where has AI failed?

A: AI's greatest disappointment is the failure to come up with a general theory of intelligence, or anything like a general theory of intelligence. In 1970, if you had asked what's the general theory of intelligence, you would have gotten answers like, ``It's all means-ends analysis,'' or ``It's all theorem proving,'' but there are very few people nowadays who say it's all anything. There's just no answer to that question. I don't see anything on the horizon that will provide that kind of theory in the future.

(c.f.)

Which is why brute force is popular.

CC.

P.S.: good.luck@conference.edu

Our Cryptography experts in the government are funding papers on Cryptography and mathematical and computer modeling related to it!

And NP! What will our government do with these horrors! The abuse of terrorists in Camp X-ray is mind boggling using papers like "A unified framework for enforcing multiple access control policies" http://portal.acm.org/citation.cfm?id=253260.253364&type=series

http://portal.acm.org/citation.cfm?id=1080441&dl=GUIDE&coll=GUIDE

This isn't the first time computer scientists have pointed out that Excel is wrong, or at the best, misleading.

Either you can let the compiler do static analysis to determine points where it is legal to deallocate (in that paper they also insert the free operation automatically as well, and see a significant reduction in overall memory usage), or you can support "weak pointers" (pointers that, whether via an extra indirection or a flag etc. can be checked for liveness of the object, or you can use ref-counting and only allow frees when there's only one reference, or you can let the compiler trace any variables free'd backwards and throw an error if at any point there's a chance of leaving a dangling pointer, or you can do a mark phase on the free call (potentially very expensive, though).

There are good reasons to do at least the static analysis, as the linked to paper shows - it's extra work compile time to significantly improve resource usage at runtime - a good trade-off.

But several of these options (ref-counted smart pointers, weak pointers etc.) are common idioms in C++ when dealing with allocation patterns where RAII and simple scoped smart pointers isn't sufficient.

There seems to me some (a lot?) of FUD mixed up in this article. (surprise surprise...)

It starts out with the fact that public key encryption relies on the existence of one trapdoor one-way functions. Now in practice we mainly instantiate these functions with the RSA function (f_e(x):=x^e mod n with trapdoor p,q such that pq=n). But there is no reason to believe this is the only possible example of trapdoor OWF! Admitedly in the 80s when this concept was first being explored there were quite a few failures when trying to base implementations on NP-Complete and/or NP-Hard problems (think knapsack for example). But since we already had RSA with all it's nice properties (efficiency, elegance and simplicity) the research community was not overly motivated to find others.

There have been and to this day still are other lines of research. Take Ajtai and Dwork's work in the direction of basing PKE on worst-case hardness of the shortest vector problem (SVP) or Micciancio's work on generalizing the knapsack problem such that average-case hardness of approximating the answer can be reduced to worst-case hardness of certain lattice based problems.

Another general direction has been to come up with groups and fields over which solving the DLP is difficult. (For example torus-based crypto and generalized Jacobian groups). AFAIK for most of these candidates there are no (known efficient) reductions from the DLP problem over Z_p or elliptic curves to the DLP in these new groups. Thus it is not immediately clear how or if Schorr's algorithm would break such systems.

In any case there is reason to believe that there can not be (or that we can't find) good candidates for trapdoor OWFs in the quantum computational model. After all there is such a thing as Quantum P and Quantum NP. Though the inequality of these set's of problems doesn't directly imply the existence of quantum trapdoor OWFs it is a good indication there of.

So basically the message is : Relax! The PKE world is by no means on the brink of an apocalypse. At most (and best in my opinion) we're in for a bout of some serious foundations research. to me that just sounds like more funding for applied mathematicians and complexity theorists from various corners and a WHOLE bunch of new candidates and interesting results. :-) i'm down with that.

There are the IEEE Code of Ethics and the ACM Code of Ethics that frown on that kind of behaviour.

That said, abuse by those with technical power can only be contained either by division (and therefore dilution) of power or by aggressive monitoring.

The ACM has done at least one thing right:

http://www.acm.org/about/code-of-ethics

> whose idea is this?

Just ask ACM...

Paulos, E. and Canny, J. 1998. PRoP: personal roving presence. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Los Angeles, California, United States, April 18 - 23, 1998). C. Karat, A. Lund, J. Coutaz, and J. Karat, Eds. Conference on Human Factors in Computing Systems. ACM Press/Addison-Wesley Publishing Co., New York, NY, 296-303. DOI= http://doi.acm.org/10.1145/274644.274686

Jouppi, N. P. 2002. First steps towards mutually-immersive mobile telepresence. In Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work (New Orleans, Louisiana, USA, November 16 - 20, 2002). CSCW '02. ACM Press, New York, NY, 354-363. DOI= http://doi.acm.org/10.1145/587078.587128

> whose idea is this?

Just ask ACM...

Paulos, E. and Canny, J. 1998. PRoP: personal roving presence. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Los Angeles, California, United States, April 18 - 23, 1998). C. Karat, A. Lund, J. Coutaz, and J. Karat, Eds. Conference on Human Factors in Computing Systems. ACM Press/Addison-Wesley Publishing Co., New York, NY, 296-303. DOI= http://doi.acm.org/10.1145/274644.274686

Jouppi, N. P. 2002. First steps towards mutually-immersive mobile telepresence. In Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work (New Orleans, Louisiana, USA, November 16 - 20, 2002). CSCW '02. ACM Press, New York, NY, 354-363. DOI= http://doi.acm.org/10.1145/587078.587128

I don't know enough from the question to know if this would supply the answers he needs. My answer below requires any system equations, set up as an initial-value problem. However, I would like to suggest that he try looking at the Parker-Sochacki solution to the Picard iteration (officially written up here in Neural, Parallel & Scientific Computations, and mentioned here in Wikipedia, and explained here. This can give you a taylor series solution. It occurs to me that the system might be modifiable to give fourier series solutions... hmmm... interesting problem there. Anyhow, good luck.

I phoned the ACM and got it sorted out. As you see now on their site, it's freely-available. The ACM was reasonable and reacted quickly. That isn't always the case.

But the real meat-and-potatoes is point #2. You chose to submit it to said journal. Live with the consequences. (I don't condemn publishing in journals - but they aren't the only method of getting the word out, and after submitting your article to a journal it certainly does not curtail you from sharing results with others via other avenues)

RAID was originally about Redundancy using cheap hardware. I'm doing the same thing but with a different and non-real time algorithm. The performance gains from striping come at a risk of data corruption that I have never found to be worth the tradeoff.

Very clever! I came across an article many years ago (written in 1996) by a guy named Stephen Savage about a RAID implementation that he nicked as "AFRAID". In a RAID 5 implementation, the small-write parity performance penalty can be avoided if you defer the parity writes until disk load drops. If you queue them up, you gain substantial speed in exchange for a slight reduction in reliability. But, he makes the point that most of the known instances of data loss are due to circumstances other than disk failure, but other reasons (virus, user error, etc.)

BTW, I also created a set of batch files for family using SSH and Cygwin rsync to do remote backups of Windows machines to my basement Linux server. Every time someone logs in, rsync does a backup to my server. Initial backup took several weeks, but incrementals now take almost nothing. I've got to tweak it so that the backup interval is more like hourly.

Your company would probably be happy to pay the $99 for you to join the ACM, if you're not already a member. They've got a slew of learn-when-you-have-the-time online courses (now from Skillpath) that cover a lot of management and business turf, as well as tech. Some of the content may make you want to shoot yourself, but whenever you get that nagging feeling that you didn't handle a situation just right, or want to prepare for something you know is coming, you can pick a topic, do some drill and kill (um, "online learning"), and at least get another perspective. I agree with all the advice here about listening to your people, finding mentors, and trying to crack a book, too. An ACM membership has a lot of legs, though, and makes a nice add to all of that.

Nope - I don't work for the ACM!

The author's website was pegged serving that 20MB PDF before slashdot got ahold of it, I doubt it'll survive now. The paper is also hosted by the ACM, if you're a subscriber.

IMO, single or multiple die configuration is not a big distinction; the impact is a constant factor on communications latency (and throughput). One of the other posters mentioned the Transputer; while not on a single chip, they went to a lot of effort to minimize inter-chip communications times. It's easy to get caught up in implementation details; sort of like arguments over what programming language is best. It's the underlying algorithms and complexity that matter.

Getting meaningful parallelism is difficult, even if you could get zero communications delay. It's amusing to me that Anant Agarwal is pushing this idea, when he had a CACM (Vol 34, No 3, March 1991, pp. 57-61). paper that mentions "for any algorithm in which the overhead due to parallelism increases with p, the scaled speedup is necessarily less than linear, and that when the parallelism overhead is linear or worse with p, there is actually a hard upper bound on the achievable scaled speedup." http://portal.acm.org/citation.cfm?id=102868.10287 1&coll=portal&dl=ACM&idx=102868&part=periodical&Wa ntType=periodical&title=Communications%20of%20the% 20ACM&CFID=32421333&CFTOKEN=50501291. These observations were based on some work by Richard Karp http://portal.acm.org/citation.cfm?id=894803&dl=AC M&coll=portal&CFID=32421333&CFTOKEN=50501291, who I have a lot of confidence in. What this means is that for most algorithms, Amdahl is right. If your communications time is non-zero, you're going to hit the wall. Better interconnect pushes the wall back, but not forever.

Anyway, this is all nit-picking. Whether or not Tilera survives depends a lot on what they're going to try to do with it. If the application is graphics (or, as you mention, video processing), the problem allows a lot of parallelism; multi-core makes a lot of sense here (nVidia and ATI have been doing this for years). Cisco-style router switches are good applications too. I heard Agarwal give a presentation at a conference earlier this year, where he was making his pitch; I thought there was way too much hand-waving about the application. The investors will find out the details soon enough, and in the mean time, I've got another stock to short!

IMO, single or multiple die configuration is not a big distinction; the impact is a constant factor on communications latency (and throughput). One of the other posters mentioned the Transputer; while not on a single chip, they went to a lot of effort to minimize inter-chip communications times. It's easy to get caught up in implementation details; sort of like arguments over what programming language is best. It's the underlying algorithms and complexity that matter.

Getting meaningful parallelism is difficult, even if you could get zero communications delay. It's amusing to me that Anant Agarwal is pushing this idea, when he had a CACM (Vol 34, No 3, March 1991, pp. 57-61). paper that mentions "for any algorithm in which the overhead due to parallelism increases with p, the scaled speedup is necessarily less than linear, and that when the parallelism overhead is linear or worse with p, there is actually a hard upper bound on the achievable scaled speedup." http://portal.acm.org/citation.cfm?id=102868.10287 1&coll=portal&dl=ACM&idx=102868&part=periodical&Wa ntType=periodical&title=Communications%20of%20the% 20ACM&CFID=32421333&CFTOKEN=50501291. These observations were based on some work by Richard Karp http://portal.acm.org/citation.cfm?id=894803&dl=AC M&coll=portal&CFID=32421333&CFTOKEN=50501291, who I have a lot of confidence in. What this means is that for most algorithms, Amdahl is right. If your communications time is non-zero, you're going to hit the wall. Better interconnect pushes the wall back, but not forever.

Anyway, this is all nit-picking. Whether or not Tilera survives depends a lot on what they're going to try to do with it. If the application is graphics (or, as you mention, video processing), the problem allows a lot of parallelism; multi-core makes a lot of sense here (nVidia and ATI have been doing this for years). Cisco-style router switches are good applications too. I heard Agarwal give a presentation at a conference earlier this year, where he was making his pitch; I thought there was way too much hand-waving about the application. The investors will find out the details soon enough, and in the mean time, I've got another stock to short!

Memory is not the issue here. Turbo Pascal was designed to run in a single 64K 8086 segment, and Pascal is the quintessential block-structured language. The real problem is that the designers of FORTRAN were totally ignorant of the principles of language design. They could hardly be otherwise: FORTRAN was the very first high-level language.

But here's a sobering thought: Dijkstra launched his attack on the goto statement in 1968. Every programmer who's grown up with block structured languages would take it as a given that Dijkstra was right. But at the time, the concept was extremely controversial, and there was a lot of resistance — as evidenced by the fact that Crowther and Wood were still using computed gotos in 1976!

We found no substantiation for the "common knowledge" that
early Mach 3.0-based Unix single-server implementations achieved
a performance penalty of only 10% compared to bare Unix on the
same hardware. For newer hardware, [9] reports penalties of about
50%.

Not creepy at all, and he may not be pretending to anything. It's more likely that he doesn't know that he doesn't know. Post 20026461 below gives a link showing this is an elected position. So what we have is a guy that knows how to win elections. For all I know, he's a solid, honest citizen, with a heart of gold, that every woman wants to take home to meet Mom.

That doesn't mean that he realized anything about the complexity of system security when he ran, and certainly doesn't mean that the general populace is going to be able to form the vaguest conclusions before they vote for or against him. But I wouldn't be comfortable with this being an appointed position, either.

To me, this is all a strong argument against e-voting without a paper receipt. The study didn't go on long enough, and new techniques for cracking systems are being still being developed, such as the recent dangling pointer article http://it.slashdot.org/article.pl?sid=07/07/23/162 4203 here on Slashdot.

Even old avenues are extremely difficult to protect against, when the stakes are very high, (see Ken Thompson's paper "Reflections on Trusting Trust" at http://www.acm.org/classics/sep95/. These stakes are about as high as they get, for a democracy.

As far as I can tell at this point, this isn't the time to be investing in e-voting systems. The odds are good that we'll end up replacing them one or more times, at vast expense, or more likely owning an ad-hoc system in which would be worse than paper ballots.

There's no harm in staying with paper ballots until we get this sorted. In fact, let's make the ability to successfully build and roll out a glorified paper punch a prerequisite for building an electronic system.

It will inconvenience news junkies, and people with instant-gratification issues, but I'm lot more interested in preserving electoral accuracy than enabling people with various personality disorders.

Students often need to download copyrighted material to support their work. I wonder if Kansas U has considered the implications of their policy: if the RIAA can get you disconnected instantly for downloading an MP3, surely other publishers can do the same.

In my own work, I often have to fetch journal and conference papers from digital libraries, e.g. a good one. Often I will find a paper is not available to me because it isn't covered by my University's subscription, like many of the papers here or here. That situation is supposed to force a trip to the brick-and-mortar library (if it has the document), but sometimes you can find the paper online anyway, using a search engine. It might be on the author's website or Citeseer. Sometimes people seem to "accidentally" leave copies of papers where a search engine can find them. This is extremely helpful for a researcher, saving much time, and it is known that online articles are more likely to be cited.

However, except in special cases (e.g. the author has retained the copyright and distributed it for free), this is technically copyright infringement. The publishers want you to get everything through their paywall. That would be fine if everything was accessible, but the exhorbitant fees charged for full access by some organisations prevent that. Therefore, copyright infringement actually helps scientific research by allowing information to flow. At my University, nobody seems to notice (or care about) students digging up papers from elsewhere. But if the Kansas U management style spread here, a publisher could presumably get students instantly disconnected for "bypassing the paywall". You might lose your Internet connection -- for studying.

Is this close to a situation where research is actively inhibited by greed?

"The content you requested is not part of your subscription, please pay $30 to download this 10 page article".

Too bad there isn't open-source software that can be used to compile code.

One of the things "professionals" know is that being able to see the source buys you nothing unless you have complete confidence in the person who wrote it. Let me once again recommend you read through Ken Thompson's classic Reflections on Trusting Trust to gain a better understanding of your faulty assumption.

I can buy a Dell, an IBM and an E-Machines PC, run that code on all of them, and ".

Let's presume, for the sake of this argument, that you meant to mention a collection of hardware which did not require different kernel-level drivers; in other words, hardware where you really could "run the same code on all of them". Let's further presume that you have found a way to create code which is provably 'correct'. Your argument fails because your requirements are incorrect.

The goal of such an electronic voting system would not be to be able to run the same code on all of them but rather to prevent code which is not the same from running on them.

We can create a test case which says something to the effect "If Candidate A is selected twice and Candidate B is selected 3 times, then the software result should be a win for Candidate B with a total of five votes cast, three for Candidate B and two for Candidate A.

We could then run this test case against software running on your selected hardware and verify the correct result. I think this is what you are meaning when you say "get the same results".

But how would you write a test case to verify something like "if the date is November 2nd and the time is between 8:30 AM and 4:30 PM and at least 2000 ballots have already been cast on this machine and the voter selects Candidate A, clears it, enters Candidate A again, clears it, enters Candidate B, clears it, taps the lower right hand corner of the touch screen 3 times within one second.....then the result should not reflect a transfer of 50% of all Candidate A votes over to Candidate B." A scenario like this is completely within the technical capability of anyone with moderate software skills to create, but beyond the capability of even the most advanced tester to verify.

In a nutshell, it is easy to verify it counts correctly, but impossible to verify that it doesn't count incorrectly.

And it's that "counting incorrectly" part that is unacceptable in a voting system.

I simple refuse to beleive that it is soooooo hard to make a 'trusted' system that adds 1+1 and gets 2.

"There is none so blind...." If you should decide that perhaps relaity is more important than you own personal beliefs, then feel free to rejoin the rational, scientific discussion parts of humanity are trying to have. Until then, though, I really haven't got the time to waste.

That "asswipe" is Ken Thomson, who (co-)invented Unix.

The compiler in question was the AT&T Unix cc.

See his ACM address Reflections on Trusting Trust.

Ah yes, the Ken Thompson hack. I wonder if what's happening in software is analogous to what's become of the United States since the early days -- it's a citizen's responsibility to know every line of the Code (both meanings), but the Code has bloated to the point where that is a practical impossibility for anyone, even a professional in the field. I won't go into the matter of closed-source Code in the legal sphere; John Gilmore is probably the one to ask about that.

These old "analog" computers are really cool. The Communications of the ACM 60th anniversary retrospective issue from a few months ago talked about how the computing machinery field was once divided between people who wanted to build machines to do continuous computation and those who favored the discrete route. As computational machinery moved toward the discrete route, there were even "hybrid" machines where the digital side controlled an analog side. Of course, as TFA points out, these differential analyzers were not "programmable" in the modern sense. Interesting stuff-- makes you think about what kinds of tradeoffs we make to go with our current digital designs.

See The ACM and IEEE-CS Guidelines for Undergraduate CS Education .

Notice that the emphasis is now much more on "liberal arts" versus mathematics, showing the growing awareness of what CS is really about.

I think we will definitely require compiler source per your first suggestion.

Actually, that wasn't my suggestion at all. Having the compiler source buys you nothing. See Reflections on Trusting Trust by Ken Thompson.

Have you thought about patches? Presume someone finds an exploit (defined any way you want) some 30 days before a major election. What do you do? Run un-patched boxes with known exploits? Run the design and QA teams ragged trying to push out a fix in time to get Federal certification and put the new code onto all the boxes everywhere? Do we get to see the source for the patches, too? What if there's a bug in the patch? (Now you're down to 5 days before that major election.)

And it doesn't buy you anything. The primary function of a election system is to convince the losers they really lost. Unless someone figures-out how to write bug free code, as well as how to prove the code is but-free, use of an electronic voting system as anything more than just an aid to producing a voter-verified, authoritative, ballot is a tactical error. A distraction. A sign that someone is doing extra work to make sure the simple solution is not the one selected.

Wouldn't you like to have the legal right to play with your county's chosen voting system?

Of course. But I'm not willing to buy that access in exchange for the right to ensure my vote is counted in a verifiable, democratic way.

Or were you implying that it's somehow indignant for a citizen to suggest that he should be allowed such access as a default right? Has our democracy really slipped so far that the citizens are forced to beg, borrow, steal, and compromise (not to mention learn Microsoft VisualBasic) just to ensure they have a change to cast a vote that cannot be arbitrarily stolen at the whim of some code monkey?

Now run the reverse thought experiment with me, if you will. Give me an election system requiring voter verified, authoritative, persistent ballots, marked in private and cast in public, with a mandate that the ballot box be publicly observable, and I'll wager your chances of 'rigging' such an election are no better than the chance of rigging a 'pen, paper, slot-top-box' election, even if the 'voting machines' are paid Party stooges in cardboard boxes.

You should be able to build a machine based entirely on open components, from the CPU, through the firmware to the OS and finally up to the voting software.

You should be able, indeed; and, as another poster says, there is no technical requirement to run voting software on a full general-purpose computer; a dedicated machine would be safer, avoid a lot of unnecessary complication and close a lot of potential holes.

Let me note though that using a dedicated machine, even if it ran completely open software won't close all security issues. As I mention somewhere else, an intruder may intervene during the assembly of the machine (for example, replacing the trusted CPU with a backdoored chip in similar packaging), the compilation of the code (see the famous article on trusting trust), so all those steps will need to be certified. Naysayers like Mr. Lipari will surely attack those potential vulnerabilities if the OS escrow gets somehow resolved. And, in the end, such a dedicated machine and the security-enhanced fabrication will very probably be quite expensive, so Mr Lipari will have a good economic argument for discarding e-voting.

In the end, I think e-voting should happen sooner or later, but the current approach is doomed to failure. You can't trust the current unholy combination of code developed in secrecy by private firms, some of them with known political biases, difficulty of verification by external parties, interested politicians and many other issues discussed here and in other places. Until a well-designed solution emerges, pen and paper are still better - and very probably cheaper as well

>>Video game addiction is very different than gambling in my eyes.

False. Gambling is a set of variable ratio reward schedules with an extremely potent reinforcer, money (and later after the rush is established, seratonin etc.) These same reward schedules exist in video games, particularly MMOs, and while they don't have quite as potent a reinforcer as cold cash pouring out of a slot machine, leveling can feel pretty close. However there is more ...

>>Players addicted to video games aren't really addicted to video games. They're addicted to being successful.

This is an additional hook, positive social interaction for some and negative social interaction (griefing) for others are extremely rewarding especially if your own self image or RL situation is less than perfect. What you call "being successful" is, in fact, a wide swath of needs which games can fulfill.

Should this be classified as an addiction? Yes, but if they use current guidelines far too many people would be diagnosed. There is a difference between being highly engaged (really fun hobby) and being addicted (all consuming and destructive habit).

For the unusually curious: http://portal.acm.org/citation.cfm?id=1223917.1223 994

-Ian

That's only true if you audit the entire Blackberry software stack for side-channel information leaks at the machine code level. I refer you to Ken Thompson's classic, Reflections on Trusting Trust. I've actually worked with a vendor that has tools for embedding special kinds of sentinels in object code, taking an even more direct and undetectable route than Ken did.

They're right to be wary.

Writing a voting app for the Java platform does not make the platform irrelevant. It makes the platform Java. If your JVM implementation is closed-source, you're left with the exact same problem, just abstracted a little more.

Of course, there are open-source JVMs and SDKs, with Sun's own not far behind. But you still have to make sure that the source of every layer between the JVM and the hardware is also open, or else there's nothing stopping it from waylaying data on its way to the filesystem or something. If it's GNU/Linux, then you're probably okay. But just to be safe, better make sure the firmware/BIOS is also open source, because sneaky changes to data at that level would be awfully hard to track down.

Oh, and while you're at it, don't just compile all of this fresh. Make sure you recompile the compiler first, using a trusted compiler that you compiled from a trusted compiler, etc., so that there's no chance of a hack like the one Ken Thompson put into UNIX. The moral of his story bears repeating here: "You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)"

Sorry. I like Java and the notion of write once, run anywhere. But don't think that adding an extra layer between OS and application makes the platform irrelevant in such a mission-critical sense. There's no substitute for full transparency, and even the definition of "full transparency" is not always as simple as it should be.

Even with open source software, unless you compiled the code yourself (or at least were present when it was compiled), how do you know that the "open" code is actually what they installed on the machine?

It's worse than that, actually.

Even if you have all the source code to Windows and all the source code to the voting application running on it, you may still not be able to detect the routines that may have been inserted illegally. For example, Microsoft could easily insert code into their compilers to insert backdoors into the source code of the compiler itself and any applications being compiled that count votes. By then recompiling the compiler itself without the logic that detects and inserts the backdoor, their compiler source code would have no evidence that the backdoors are inserted, but they would be nonetheless.

For a much better explanation of this, read Ken Thompson's essay "Reflections on Trusting Trust".

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

source code isn't everything.

and sure, you can claim gcc protects you from this with its multi-pass compile process, but you'd be wrong. at least generally you do get some level of protection by cross compiling a fairly random set of compilers in some sort of interesting chain but how many people actually have enough rare yet open source compilers that they're willing to use to circumvent this?

Huh? EE's create DRM and DRM-like systems all the time, you mean "true professionals" like that, or some other kind?

Also, you can always join the ACM if you want to buy into an ethics package.

1.5 Honor property rights including copyrights and patent.

Violation of copyrights, patents, trade secrets and the terms of license agreements is prohibited by law in most circumstances. Even when software is not so protected, such violations are contrary to professional behavior. Copies of software should be made only with proper authorization. Unauthorized duplication of materials must not be condoned.

-- Association of Computing Machinery

In other words, the ACM lend their support to all DRM schemes, no matter how inconvenient, by saying that it is unethical to remove DRM for any reason. Including removal of DRM for "non-pirate" reasons such as interoperability, research and fair use.

Twitter, read "Reflections on Trusting Trust" [no link provided]. Now. Free software doesn't provide full protection.

Thanks, I have read that before. So what? The point of free software is that you don't have to trust, you can see and verify for yourself. The learning compiler example is disturbing but not very. If you are really paranoid, you can start from scratch and toggle switches yourself. A less crazy method is to cross up distributions. Compile things from one distribution with another. Finally, you can simply trust the people at gnu.org and everyone using the tool chain that has not noticed problems. At the end of the day, free software still wins. You have every ability non free does and many more to validate what you think you have. People in the non free world are stuck trusting people who have violated that trust again and again.

Her homepage,
tortola and
possibly unrelated paper

You wouldn't be thinking of this?

I read Ken Thompson's Reflections on Trusting Trust, it has always occurred to me that any computer crime is completely untraceable. It is only laziness on the part of the criminal which allows him to get caught. It is possible for someone to completely cover their tracks and leave no evidence of their actions.

But it is also possible to log every action a hacker does. Erasing the logs doesn't do much when the compromised system is virtually hosted and every action recorded for later playback - on a system which isn't even visible to the hacker. And consider the possibility of tracing at the network level. It is possible to physically connect an ethernet chip to a network and capture all traffic on the network without ever joining the network. That is, the card can sniff the wire in a read-only mode without ever publishing its MAC address or responding to ARP queries. Even if the hacker does use encryption, can he really be sure that his machine hasn't been rooted and keylogged? Can today's hackers verify even the microcode inside their processors and BIOS? If he can cover his tracks, so can the FBI.

How does a hacker know his rootkit isn't spying on him? Even if you have the source, a compromised compiler or assembler can still produce a compromised executable. Should you verify the executable by hand, you still have the possibility of a vulnerability in the processor's microcode. Something as simple as making any area of memory available to the NIC when a certain opcode sequence is executed could be hidden very well and provide a veritable back door to law enforcement.

Unless you are willing to build your own computer from scratch and never connect it to a public network, you can never prove that you aren't compromised. Sure, we can talk statistics and likelihood and incentives and human factors and whatnot, but it doesn't change two fundamental aspects of the computer:

1. Changing computer data at the most basic level can be done without leaving any evidence, and
2. You can't prove the code you are running doesn't have security vulnerabilities without spending an inordinate and impractical amount of effort.

Your averge user - heck, even most programmers and hackers - don't have the time to trace through every possible instruction path in the software they use. They aren't going to burn their own BIOS EEPROMs to be sure the BIOS isn't bugging them. They aren't going to surgically remove the processor's cover and verify the die pattern to be sure the microcode isn't compromised.

Instead, they're going to trust the responses their computer shows them. Just like the rest of us - it's a gamble. Maybe the hacker compromised a bank - or maybe, the bank is in cahoots with the FBI, and he's just knocked over the honeypot. He won't know until he goes to the bank - and withdraws his cash, or gets arrested.

Still a pretty big risk, imho.

I am sure Ken Thompson still has access to Bell Labs' information.

I guess a few of us may be a bit young to remember this one.

Mitsubishi has a similar coffee table thing they call diamondtouch . It can handle two hands per user and the version I saw allowed 4 users. Oh yeah, and it was first publicized in 2001!

People may or may not process information in a linear fashion, but human brains are, apparently, massively parallel computational devices.

Addressing architecture for Brain-like Massively Parallel Computers

or from a brain-science perspective

Natural and Artificial Parallel Computation

The common tools (Java, C#, C++, Visual Basic) are still primitive for parallel programming. Not much more than semaphores and some basic multi-threading code (start/stop/pause/communicate from one thread to another via common variables). I've made programs, specifically, spiders, that can run 200-1,000 simultaneous threads usefully on a PC. They work ok, as long as the inter-thread coupling is minimized. Until we get enough exposure to parallel systems that we develop new languages to express the solutions, parallel programming will remain accessible to the few, the proud, the geeks. But I don't think it's because of our brains architecture.

Just about everything technology related - http://technews.acm.org/current.cfm
Operating systems - http://osnews.com/, http://osdir.com/
Programming languages (like Ruby and Python and functional langs.) - http://lambda-the-ultimate.org/, http://plnews.org/
Consumer tech news - http://news.bbc.co.uk/2/hi/technology/default.stm
And of course, http://slashdot.org/

As the top of their page states: "Timely Topics for IT Professionals". It's updated 3 times a week with summaries of a bunch of articles. It's mostly ad-free and the articles tend to have an academic slant.

http://technews.acm.org/current.cfm