Slashdot Mirror

The rules of academic publishing are that you have to cite relevant related work. This includes both fresh results and old classics. Where possible, we tried to cite the most recent studies. Some studies that are appear dated indicate a research opportunity to update the corresponding area. Also, it would be wrong to dismiss a paper because of its age. Some of the older studies we cite present theoretical frameworks of enduring value and importance, demonstrated by the thousands of citations they have received over the years. For instance, the 2003 study by Venkatesh and his colleagues on the user acceptance of information technology, which we cite, has received almost five thousand citations. It would be wrong to ignore it, just because of its age.

Long story short: It makes it easier, but it's not required. If they've got it, they can just copy the call at the switch level. If they don't, they can: Install software on the persons phone, sniff + break the radio waves, bribe a telco employee, plant software on the towers (see http://www.dmst.aueb.gr/dds/pubs/jrnl/2007-Spectrum-AA/html/PS07.pdf - really interesting read), or i'm sure they've got more methods.

Cell phone's aren't secure.

Just for reference:
This is why the current AV model is ultimately hopeless in the long run:
"Reliable Identification of Bounded-length Viruses is NP-complete "
http://dmst.aueb.gr/dds/pubs/jrnl/2002-ieeetit-npvirus/html/npvirus.html

And because I'm bored and I like PHP, my reply to all of the above:

* PHP sucks.

PHP has functions for practically anything you can imagine. Of course, I'll get into why it doesn't suck in the replies below, as this is a bit too general.

* PHP is for n00bs.

PHP is for developers who want to get something done quickly. The syntax is very easy to learn, and variables are loosely typed, but in my experience this doesn't mean that the language is flawed; it means that one can code up something without having to worry about unnecessary things like pointers, variable conversion and the like. And to be honest, in website scripting I've never come across a need for more advanced syntax than PHP provides in my five or more years of using it.

* PHP is usually poorly written.

This, unfortunately, is usually true. Because PHP is easy to use, it is often used by people who don't want to worry about writing good code either. But like everything else, there are varying grades of professionalism. PHP *can* be written well, it's just a case of taking the time to do so.

* PHP is a scripting language and you can't do anything but write web pages with it.

Scripting language, yes. But it most certainly can be used for things other than websites.

* PHP sucks because the function names are inconsistent.

True, but this is why one has a manual. I've never been all that concerned about it.

* PHP is slow.

Actually, it's really not. Take a look at this comparison between different CGI modules for Apache: PHP actually outdoes Perl here.

* PHP isn't capable of working in a real enterprise.

I haven't had experience with integrating PHP into an "enterprise" situation personally, but I'll refer you to Zend's Enterprise PHP page for various reasons why PHP is indeed ready for the enterprise.

* Real coders use Perl.

Real coders use the tool that best fits the problem.

* PHP doesn't scale.

Now THIS is something I can definitely refute. I work for a company that creates mods for a PHP / Smarty-based online shopping cart known as X-Cart and I can tell you, PHP scales wonderfully, otherwise stores wouldn't use it as a base of their business operations. X-Cart is on the order of hundreds of thousands of lines of PHP code, and very commonly has tens of thousands of customers accessing it concurrently.

And yeah, I know you were joking, but hey, I was bored. ;^)

I thought it was going to take place in Athens, Greece.

Generate a public/private keypair for them using a computer at home. Make sure to use relatively small prime numbers. Now, read them the public key over the telephone, and have them generate a shared key, encrypt it with your public key, and read the result back to you (in binary, of course).

From now on you don't need the public/private keypair, have them burn any note paper that they might have used while calculating the message. Make sure they put the ashes in at least 4 different trash cans in different parts of town. From now on you will communicate with them using the shared key. This will be much easier to do by hand, and you can use a slightly larger key size. In fact, maybe it's best if you use some shared source for a one-time pad. For instance, they can probably get a copy of the NIV bible, and you can get one too. Pick a particular passage to start at, and there you go, you have a one-time pad. But don't use the NIV bible, because someone reading this post will have a much easier time cracking the message. Instead, pick a source and send that in the encrypted message. Keep the messages short. You can communicate most of the information over the phone unencrypted, just make sure the sensitive data is encrypted.

Now, have them send you all their current passwords (these would be encrypted, of course). You should now log in and change all those passwords to random ones which you generate. From now on, if they need to access something, they should call you up (or email you using a newly created email account) and tell you what they need to access. You will then change their password, and send the new one encrypted to them. They will decrypt the password by hand, possibly using a calculator if they can ensure that there is no keylogger installed on it (obviously don't use a calculator on the possibly compromised machine). Once they are done using the site, they should contact you and you'll change the password again, to something new and random.

Obviously all of this would have been a lot easier if they had set things up before leaving. For instance, when I'm at work I only connect to my home computer via https using a a password which automatically changes every single time I connect. My home computer contains the actual passwords to the sites and thus it logs in for me and relays the information. I carry around the next 15 passwords every time I go, though they are obviously encrypted using a special scheme which I have memorized and can perform in my head. Yes, it's possible the browser itself is compromised, but that's a lot less likely than that a keystroke logger is installed. I used to use a secureID device which automatically changed the password every 5 seconds, but then someone told me that the NSA installed a backdoor into those devices.

Oh yeah, I'm just kidding about all this... Or am I?

The course is an elective, and was offered for the first time last year; not many students decided to take it. Those who did, got hooked; some commented that it was the course where they really understood what it meant to program.

The following projects were completed last year:

• Support for PDF actions in PDFBox.
• Improvements to the GUI interface of the ZGRViewer
• The addition of a new question type in the ETH Lecture Communicator

This year the course will be taught in English and will be offered to students across Europe through the EU's Erasmus student mobility programme. I hope to be able to report on new exciting results through slashdot next year.

The course is an elective, and was offered for the first time last year; not many students decided to take it. Those who did, got hooked; some commented that it was the course where they really understood what it meant to program.

The following projects were completed last year:

• Support for PDF actions in PDFBox.
• Improvements to the GUI interface of the ZGRViewer
• The addition of a new question type in the ETH Lecture Communicator

This year the course will be taught in English and will be offered to students across Europe through the EU's Erasmus student mobility programme. I hope to be able to report on new exciting results through slashdot next year.

The results of PHP were not what we expected. Being exposed to the hype that rules on the Internet about PHP, we expected it to be at least at the second place. It did not scale well (see BENCH4) and exhausted system processing power when it run, leaving it unusable. We must admit that PHP is tightly linked to MySQL, which was not how we used it, but it is our belief that a fast system can be fast irrelevant its environment.

You can see from the graphs that mod_perl performs way better than PHP on the whole, and places less load on the server than PHP. They were not using MySQL.

I think it's worth while to take the time to build up a corpus of SPAM and "good" messages as I can then evaluate competing filters.

Anybdoy looking for a can of spam might want to check out the Ling Spam corpus created by Ion Andoutsopoulos, also available here.

I think it's worth while to take the time to build up a corpus of SPAM and "good" messages as I can then evaluate competing filters.

Anybdoy looking for a can of spam might want to check out the Ling Spam corpus created by Ion Andoutsopoulos, also available here.

Diomidis Spinellis
Code Reading: The Open Source Perspective
#include "/dev/tty"

I did a little testing of Bayesian filtering on my own, and I used the Ling-Spam Corpus from Dr. Ion Androutsopoulos. He's collected about one thousand messages which consist of "legitimate" messages to a linguistics mailing list, and "spam" messages. They are preclassified, and divided into ten parts to make ten-cross-fold-validation easier. Check out his publications. Scroll down to the "Document filtering" section.

I did a little testing of Bayesian filtering on my own, and I used the Ling-Spam Corpus from Dr. Ion Androutsopoulos. He's collected about one thousand messages which consist of "legitimate" messages to a linguistics mailing list, and "spam" messages. They are preclassified, and divided into ten parts to make ten-cross-fold-validation easier. Check out his publications. Scroll down to the "Document filtering" section.

There are several papers describing using Naive Bayes classification, as well as others AI techniques, to filter spam here. Look for the section on "Document Filtering".

While not part of the kernel, have a look at Win32 and COM (pick any version of Windows you like). I think it is fair to claim that the equivalent Linux libraries (POSIX and KDE in particular) are generally better designed. Remember that Win32 and COM is what Windows programs use.

No matter what, though, I think Win32 and COM have a bizarre design. If you want to discuss it, you could start by reading:

Spinellis' critique

Here is the abstract:
The architecture, interface, and functionality of the Windows Application Programming Interface (API) make it difficult to master and use effectively, and contribute negatively to the safety, robustness, and portability of the applications developed under it. The API is structured around a large and constantly evolving set of functions and is based on a problematic shared library implementation. The provided interfaces are complicated, non-orthogonal, abuse the type system, cause name-space pollution, and use inconsistent naming conventions. In addition, the functionality of the interface suffers from inconsistency, incompleteness, and inadequate documentation. Application developers, programming tool vendors, and Microsoft should face the above problems and provide appropriate solutions.

<karma hoard>
This is quite a good thing when doing ports, e.g. Wux applications from Unix to Windows PDF here. Particularly insightful is "Chapter 3.2.2 Operating Systems Differences". This document can also serve as Unix to Windows porting 101. I wonder if the Win 3.1 stuff they are talking about is still valid in the non-MSDOS WinME,NT,2000,XP ?
</karma hoard>