Why not having changes to the Debian archive broadcasted via IP multicast to all
hosts subscribed to the broadcast? Large installations — at least in closed
environments — could save network bandwith used for updates...
posted at: 14:01 |
path: /Ideen |
permanent link to this entry
In order to fight spam, several people use SpamAssassin or dspam,
which uses a Bayesian classifier to predict a spam score based upon text
patterns found in messages received in the past. Whereas this approach
catches a reasonable amount of spam it is limited to text-implicit
indicators (spammy buzzwords, known bad URLs and so on). Observing the
choice of nowaday's solutions against spam you will realize that there
are several other means of spam recognition available.
Greylisting is a widely used (sometimes hyped) way which benefits
from the knowledge about spambots, which do not re-send a message (like
real mail servers) if the targeted SMTP server is temporarily
unavailable. Other deviations from the behaviour of real SMTP clients
(i.e. other mail servers) might be indicators for sources of spam too.
They all have in common that they concisely watch the peers involved in
a SMTP dialogue and the dialogue itself and draw conclusions about the
sending party.
I wonder if it is possible to measure a set of such indicators
surrounding the SMTP dialogue and take them as input indicators for a
simple bayes classifier scoring the SMTP dialogue. This might gain
another, alternative way of detecting spam.
I'm open to any idea, what to take as indicator for such a
classifier. Please send me your comments...
posted at: 19:37 |
path: /Ideen |
permanent link to this entry
Gestern bei meiner Schicht als
Wahlhelfer bei den Wahlen
zum Unabhängigen Modell ist mir mal wieder aufgefallen, wie
umständlich es eigentlich momentan ist, die Daten vom Studiausweis
abzutippen. Dabei sind unsere Studiausweise, auch FriCard genannt, ja doch
eigentlich dazu in der Lage, über ihren eingebauten Mifare-Chip die auf der
Karte enthaltenen Daten elektronisch zu übermitteln. Für die Bibliothek und
die Mensa funktioniert das schon ganz prima.
Die auszulesenden Daten müssen dabei eigentlich nur einem Kriterium
genügen: Sie müssen ein-eindeutig mit einem Wähler übereinstimmen. Die
Karten-ID der Karte genügt diesem Kriterium leider nicht, denn ich hab schon
mehrere Leute getroffen, die mehr als eine FriCard besitzen. Derzeit
wird die Matrikelnummer als eindeutige ID verwendet - stellt sich bloß die
Frage, ob man da irgendwie dran kommt.
Überhaupt ist das Dran-Kommen so ein Problem: Kartenleser stellte uns die
Univerwaltung bisher nicht zur Verfügung, und der Kauf eines kommerziellen
Lesers schien unerschwinglich. Mit zunehmender Verbreitung der RFID-Maschinerie
ist anzunehmen, dass solche Kartenleser immer billiger werden. Dennoch stellt
sich aber — wie schon bei den Wahlmaschinen, die punktuell für die
letzten Bundestagswahlen verwendet wurden — die Frage danach, wie
vertrauenswürdig solch ein gekaufter Kartenleser ist. Und überhaupt: Wie ist
gewährleistet, dass es Treiber nicht nur für proprietäre Systeme Windows gibt
usw....
Selberbauen kam mir dann in den Sinn, aber die für RFID-Technik verwendete
Elektronik verlangt dann doch einiges Know-How über Hochfrequenz-Elektronik
usw. Doch wie schon so oft wusste Google auch hier Rat: Das von Harald Welte
(für Linux-Firewall-Gurus sicherlich ein alter Bekannter) ins Leben gerufene Projekt OpenPCD stellt einen
bis hin zum Schaltplan und zur Firmware quelloffenen Leser samt rudimentärer
Linux-Treiber zur Verfügung, auf dem man Leseterminals für die
FriCard-Wahlurnen aufbauen kann.
Aber bevor sich jetzt jemand vorschnell an die Umsetzung macht bitte nicht
vergessen: GEH WÄHLEN!
posted at: 14:13 |
path: /Ideen |
permanent link to this entry
In the need of providing people easy access to their files on a WWW server
without giving them shell access for file uploads only I discovered some time
ago the nifty DAV feature
supported by Apache.
This provides an easy but yet authenticated way of accessing the files on the
server. Windows users are able to access their webspace as a network share
using WebDAV.
Unfortunately on server side all files are owned by the same user, which is
not exactly what I looked for. But having heard about
suExec
and suPHP I wonder
why apparently there is no suDAV which switches to the authenticated user
before doing the DAV work on the files stored on the server...
posted at: 23:38 |
path: /Ideen |
permanent link to this entry