Archiv

English

German freemail heavyweights web.de and gmx.net (several millions of users combined) are using deceptive techniques in order to manipulate Firefox and Chrome users into removing AdBlock and its variants. This message is displayed for people with the respective setup:

web_deThe yellow bar is part of the website (it even scrolls with the site). It says:

The security of your computer is compromised by a Firefox Add-On. [Restore Security]

Clicking the fake button or the „Further information“ link takes the user to a shady-looking website charmingly named browsersicherheit.info (browser security dot info).

This site imitates the look of Chrome’s browser settings and uses a seemingly objective and caring tone, explaining how „content manipulating browser add-ons“ pose an enormous security risk. It also contains a surprisingly short list of allegedly „known malicious browser add-ons“:

plugins2Note how AdBlock and several variants of it are shown at the top of this list, described as „filters page contents“. Every user of AdBlock is aware that it filters contents—that’s its purpose. Still, this list is obviously supposed to cause insecurity and fear, especially since the same list contains obscure and dubious sounding add-ons. Many of them are described as „inserting external elements like advertising“. One, ironically, is accused of „creating false security alerts“.

Otherwise, the page purports to be a well-meaning security initiative. Only the legally-mandated and well-hidden Contacts page shows that 1&1 Mail & Media is behind it. The 1&1 DSL and hosting franchise is part of the German United Internet company, which in turn owns web.de and gmx.net. A press release at gmx.net praises it, but gmx.net is not named as part of this „program“ anywhere on the site. However, in the ridiculously short „press comments“ section, gmx.net and web.de appear as two out of three sources (the third being a nasty tabloid’s computer spinoff magazine).

This practice is all the more more malicious, as it has taken years to establish that browsers show meaningful security notifications, and to get everyone’s parents to actually read and follow them.

Apparently, the Mozilla security team is looking at the situation, which I’m very grateful for.

Updated 2017-03-06: Now properly handles oldmail files to avoid multiple downloads of old mail when calling different sets.

Faced with a growing number of mailboxes to fetch messages from, I devised a little script to help me easily manage lots of accounts with getmail. It was inspired by this post from Charles Cazabon, the developer of getmail.

The advantage of this solution is that you need to create, name and manage getmail’s rcfiles for different mailboxes in one place only, without modfying other scripts, crontabs or whatever.

First off, this is the folder structure I created. It may remind you of the old /etc/rc.d/ folder structures that were common for system start scripts before we had upstart and all this modern whoop-de-do:

.getmailsets
├── set-all
│   ├── rc.blog
│   ├── rc.freemail
│   ├── rc.provider
│   ├── rc.uni
│   └── rc.work
├── set-often
│   ├── rc.provider -> ../set-all/rc.provider
│   ├── rc.uni -> ../set-all/rc.uni
│   └── rc.work -> ../set-all/rc.work
├── set-rare
│   ├── rc.freemail -> ../set-all/rc.freemail
│   └── rc.blog -> ../set-all/rc.blog
└── set-important
    ├── rc.uni -> ../set-all/rc.uni
    └── rc.work -> ../set-all/rc.work

.getmail/ -> .getmailsets/set-all/

All the getmail-typical rcfiles live in the .getmailsets/set-all/ folder, which is symlinked to .getmail/. This ensures that things will work like any normal getmail setup whenever you don’t use the sets.

Specific sets of rcfiles are defined by folders with a corresponding name and contain links to the actual rcfiles in the „all“ set.

This is the script that puts this structure to use. I call it checkmail:

#!/bin/bash

RCARGS=""
RCPATH=/home/myself/.getmailsets
RCSET=$1  # first argument names the set,
shift     # then gets deleted

for F in $RCPATH/set-$RCSET/rc.*; do
  RCARGS="$RCARGS --rcfile $(basename $F)"  # prepares --rcfile args
done

exec getmail $@ --getmaildir $RCPATH/set-all/ $RCARGS
                # make sure getmail always uses same oldmail-*
           # $@ holds all the (remaining) arguments to the script.

You use checkmail by calling it with the set name as the first argument, and any arguments you want to pass on to getmail, like in these examples:

$ checkmail all -q
$ checkmail important -v
$ checkmail rare -q -d

And these calls, of course, are what you want to place in your scripts, shortcuts and whatnot. You can then manage the set contents or rename the rcfiles in your .getmailsets without changing any of the scripts. How about, for example, a button on your desktop that runs:

$ ssh mailserver "checkmail important -v"

The script is also ideal, of course, for your crontabs. Here’s an example of my configuration:

*/5  0-3,9-23  * * * checkmail often -q
  0      8-23  * * * checkmail rare -q

Since $HOME/.getmail/ is symlinked to .getmailsets/set-all/, you can also call getmail for any single mailbox like your ordinarily would:

$ getmail -r rc.work
$ getmail -vr rc.uni

In my university’s research group, there’s a traditional weekly seminar known as „Kaffee und Technik“, where people will show each other tricks and methods they learned in the course of their research. Recently having taught myself a working knowledge of simple binary data storage and readout with Python, I compiled a little lecture on the subject.

Hoping that someone out there might also find this useful, I’m posting my slides here:

In case you’re wondering: The editor I am using is wxHexEditor. I found it to be a very good hex editor, with many more capabilities than most others out there. It is actively being developed and works equally well on Windows and Linux. It even compiled without any dependency hassle on an oldish system of mine.

So, if you’re looking for a good hex editor, try wxHexEditor. The project’s homepage is somewhat of a hassle to navigate around, but it’s definitely worth it.