The rather obvious change that HTML 5 brings to the table is the HTMLMediaElement DOM Interface, and in particular the currentTime property, which at any time reflects the part of the media content that is played.

This means that it allows to synchronize any part of your HTML page with the video, as well as navigate through the video by setting the property to the section of the video you want to play!

And since I had already gathered a lot of timing information in the transcript of the video, extracting meaningful timings of the various sequences of the video was again only an XSLT style sheet away, provided I added relevant metadata in the transcription: typically, identifying subsections as <div> in the timedtext transcript, with a ttm:title set (which I achieved directly through my transcribing tool, Transcriber, that has all the needed interfaces to set these metadata).

And so I wrote that XSLT, added some further out-of-band metadata linking to slides and additional notes that I wanted to include in my presentation viewer (more details on the process involved are available).

The fact that I couldn’t embed these additional data in TimedText is actually quite disappointing – that a Web format should be developed without any way to add hyperlinks seems quite wrong! Generally speaking, it’s not clear to me that timedtext should be anything else than a set of additional timing attributes on top of XHTML – but I can’t claim that I have explored that space sufficiently to give much credit to that assertion.

Given that these metadata were not stored in the TimedText file, I ended up having them embedded in the resulting HTML page; it occured to me that the best combination to store them there was to use the extremely experimental media fragment syntax within an RDFa description of the table of content, e.g.:

<ul class="toc">
            <li about="http://media.w3.org/2007/11/parisweb-dom.ogv#t=00:00:44.209,00:01:28.432">
               <a target="slides" rel="foaf:depiction"  
                    property="dc:title" 
                    href="http://www.w3.org/2007/Talks/11-parisweb/slide-1.html">
                    Introduction
                </a>
            </li>
</ul>

This essentially annotates a given section of the video (#t=00:00:44.209,00:01:28.432 meaning between 44.209 seconds after the start of the video and 1 minute 28.432 second after the start) with a title and an illustration (in this case, the accompanying slide) – I chose foaf:depiction as a property, but it probably isn’t the best match – I’m hoping thet Media Annotations Working Group will come up with a useful ontology that could be used in these types of contexts.

These annotations are then parsed by a small Javascript layer (built on top of JQuery) which reproduces most of what the TimedText javascript player does, but in a much less verbose way… – another incitation for hoping that timedtext was really just XHTML.

The resulting presentation viewer allows to navigate through the video, with synchronized slides, notes and subtitles, provided your browser supports the HTMLMediaElement interface, as Firefox 3.1 does:

(also available as Ogg/Theora video with a Timed Text transcript.)

It also carries a set of RDF annotations to the video itself.

(I discovered only today that apparently Ian Hickson made a very similar demonstration a few months ago)

I must confess that I’m not quite sure that the accessibility of the resulting page is great – it uses the <object> element to load external pages (the slides and notes), while it should probably include their content automatically through AJAX, with a pinch of WAI ARIA to alert of pages updates.

The AJAX inclusion of content would be much facilitated by scoped style sheets.

My conclusion from this exploration is that clearly the new HTMLMediaInterface DOM interface is of great importance to really bring video (and similarly audio) into the Web browser; I can see how it could be improved to make it much easier to create synchronization effects:

• using some sort of timer callback interface with a begin and end period – currently, you have to use the generic setInterval function that polls every tenth of second to check whether you are in a period of the video where something should happen; ideally, you would just say video.setTimer(callback_function,begin,end), and callback_function would be called each time the video enters the period of time between begin and end;Err… it seems that’s exactly what addCueRange is about.… I guess what I really need is having it implemented :)
• ensuring that the HTMLMediaInterface is applied to any element where a time-based animation is used: being able to use it on SVG animations, Flash animations, and maybe even animated GIF (!) sounds as useful as on videos and audios; maybe this “just” means that the <video> element implementations should support image/svg+xml and image/gif as acceptable media types?
• it seems really backward that any JavaScript layer be required at all to run synchronized subtitles, and the <video;gt; element should clearly support linking media content and their transcript in a uniform way;
• it would be really neat if the media fragment URIs could be used again directly to go to a particular section of a video included in the page, without the Javascript layer.

The reporter of this abuse of service had the good idea to mention an existing technical solution to this type of problem: SURBL is a registry of registered domain names that have been reported as used by spammers. Although I’m not a big fan of this type of registries (they really seem the lowest type of trust network one can imagine, too easily abused), faced with the alternative of shutting down the service entirely or reducing the possibility of abusing it, I took the second option.

As the said service (that I’m not mentioning explicitely in case it would draw more attention that it needs at this point) is written in Python, I’ve been looking for a Python implementation of the SURBL mechanism; unfortunately, I haven’t been able to found one and so had to write my own implementation, which seems to work well (units tests also helped) and now supports the alluded on-line service.

SURBL uses DNS queries as a way to query their registry: you ask whether spam.example.multi.surbl.org exists; if it does, then spam.example is part of the blacklist, otherwise it isn’t. In terms of implementation, the only (rather small) difficulty is to identify the relevant part of the URI you want to check, namely the registered name used in the authority component of the URI. This implies removing the possible port and user information parts in the authority component, but also the possible sub-domains of a registered domain; this would be entirely trivial if one didn’t have to take into accounts delegated second-top-level domain names (e.g. as co.uk).

SURBL’s architecture is a rather smart way to re-use the existing caching/query infrastructure deployed for DNS (e.g. I just had to import DNS Python to query their blacklist). I suspect that the software infrastructure behind DNS implements caching more widely than most implementations of HTTP do, and thus would induce a smaller load on their servers – although I haven’t quite checked it. Of course, the DNS system is particularly well fitting to this, given that the queried items follow (by definition) the naming rules of DNS. Also, I guess that the primary usage of the system (mail filtering) made DNS a pre-requisite, while access to an HTTP client may be less obvious. But I wonder if there would be any compelling reasons to make this also available as an HTTP service?

The blue line is the number of messages that are directly trashed when arriving in my mailbox because their SpamAssassin score is greater than 12; the pink line is the number of messages that goes into a separate mailbox that I review periodically to find false positives, which still happen from time to time. The graphics doesn’t show the number of spam messages that I get in my final inbox; it’s never more than one or two a day, usually zero.

What this graphic shows is how much the number of egregious spams (those that SpamAssassin notes as more than 12) that are distributed to me has dropped in the past few days; the key changes in our anti-spam configuration that triggered that change were:

1. first, rejecting messages with many unescaped 8-bits characters in their subjects, which I think matches the first inflection in the graphic around 160; as it occurs, sending 8 bits characters in messages headers is invalid, and has been a very good indicator of uncaring senders. Note that as good email and Web citizens, our reject bounces document why we do so, and how to get around it.
2. secondly, the very sharp drop around 175 is a consequence of having SpamAssassin running at our MX level, and rejecting any message scoring more than 10; the benefit of having SpamAssassin running higher up in our mail distribution is pretty clear: instead of having 70 SpamAssassin running to check a message that have been sent to the 70 members of the Team, a single instance can reject it if it is really too spam-alike.

But why are there still messages that get discarded by my SpamAssassin with a score higher than 12, then? Because my SpamAssassin is carefully trained with SA bayesian system, and so is more accurate to find egregious spams. But even that may soon be no longer relevant, since we’re looking into feeding the instances running on our MX with blatant spams (either through honeypots or through messages marked as spams) and well-known ham…

The only dark side to this graphic is what the pink line shows: the number of messages that I get to review to detect false positive is significantly increasing. I could just give up and not review them anymore, but since I still get some of these, I can’t really feel confident about this.

The other option would be to lower the go directly to trash threshold, but I quickly checked on my false positives mailbox (that I use to train SpamAssassin) with: grep "X-Spam-Status:" ~/mail/ham |sed -e "s/.*=\([-0-9\.]*\) required=.*/\1/"|sort -n|uniq, and I had a few messages with a score higher than 9 as false positive, so I can’t really set it below 10…

I got around the moderation flood in my inbox using yet another procmail rule, and got around the second part using a small bookmarklet, which runs the following javascript code:

 fields=document.getElementsByTagName('input');
for (i=0;i<fields.length;i++) {
  if (fields[i].value=='delete') {
     fields[i].checked=1
  }
} 

In other words, find all the input elements, and if they have a value set to delete (the current convention in my WordPress version), mark them as checked; only needs to push the moderate button afterwards. Of course, this works well only if you receive mostly spam (as in my case) compared to real comments.

The idea is to use the Annotea protocol as a way to store and retrieve spam marks on archived messages, and to regenerate the relevant archives based on these marks; it uses lots of W3C Technologies (XSLT as a way to build a user interface, RDF/XML as a data format, HTTP as a query/update protocol), which makes it really interesting, if sometimes somewhat challenging.

I hope to get on finishing a proper documentation for it soon enough, but if you look well enough, you should already be able to see some mailing lists archives being cleaned through this very system… (hint: to detect a cleaned mailing list, find those where the number of messages displayed in the cover page doesn’t match the one displayed in a period-page; and yes, this is a bug :) )

(1 is Monday, 7 Sunday) These plots are based on the spam I received in the past 2 months.

Note that in fact, this interpretation is probably buggy; for instance, it’s likely that a fair number of Zombies computers used to send spams are shut down during the week-end.

X-Spam-Checker-Version: SpamAssassin 2.60-spambr_20030926a on popular_mail_service.com
X-Spam-Level:
X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no
        version=2.60-spambr_20030926a

Due to the way my SpamAssassin set up works, they were not re-checked when entering my spam filters!

Although this should probably fixed at a higher level in our mail distribution system, I’ve worked around it with the following procmail rule:

# clean spurious SA headers
:0fw
* X-Spam-Checker-Version: SpamAssassin 2\.60-spambr_20030926a on
| formail -IX-Spam-Status:

I don’t want to remove any previous SpamAssassin header, since our mail set up does set one already that I can trust; but since we’re not using the same version as the one given in the X-Spam-Checker-Version, I’m on the safe side. And after a quick check, these spams amounted to around half of the spams that went through my filters in June, so I should get even better results with my anti-spam set up.

Well, until spammers start upgrading their fake headers, I guess.

• I’m getting between 500 and 600 messages a day
• among those, around 400 are spam
• among them, the vast majority (~90%) is simply trashed, relying on SpamAssassin – I basically direct all messages with a SA score greater than 12 to /dev/null
• on the remaining 10%, 90 to 95% are put in a distinct mailbox (cleverly labeled spam)
• … which leaves me with about 3 spams in my inbox per day, which is quite manageable
• the false positives for these 6 months amount to less than 50 messages, most of them wouldn’t have been a big loss if I hadn’t spotted them in my spam mailbox

I’ve gathered these statistics from my procmail log, using a simple grep, à la grep -A 2 "Mon Jul 5" .procmail/log |grep "/dev/null"|wc -l (this gives the number of instance of messages directed to /dev/null on Monday, July 5th).

With a simple loop, I can get data across the past months in a comma-separated format: for i in `seq 190 -1 1` ; do day=`LC_ALL="en" date --d "$i days ago"|cut -b -11`; echo $day , `grep -A2 "$day" .procmail/log|grep "/dev/null"|wc -l` , `grep -A2 "$day" .procmail/log|grep "spam"|wc -l`; done > spam-evolution.csv; once loaded in Gnumeric (the Gnome equivalent of Excel), I can get graphics of the evolution of the repartition of my mail between /dev/null and my spam mailbox:

The one below (time on horizontal axis, number of messages on vertical) shows that the number of spams has steadily grown in the past months:

It would be interesting to see whether the peeks here and there matches some of the spam storms W3C has encountered this year.

The following graph (percentage of spams directly trashed vs those in my spam mailbox over time) seems to indicate either a slow gain in efficiency in SpamAssassin at trashing spams, or a raise of the rate of obvious spams

I’m tempted to think it’s the former, given that spams tend to get “smarter” at hiding themselves, and since there is a rational explanation for SpamAssassin at getting better – I’m using its Bayesian training functions. Also worth noting is that the variation of this percentage seems to diminish over time, although I have no idea how this should be interpreted!