Of Ads and Signatures

Both advertisements and signatures have been with us in the analogue realm for ages, the society has learned about their usefulness and limits. We have learned that it’s (usually) hard to judge the impact of a single ad, and that the process of actually validating a contested signature is not trivial. There is a good reason why the law requires more than a single signature to authorize the transfer of real estate.

Both concepts have been translated to the digital, online world.

And in both cases, there were promises that the new, digital and online versions of ads/signatures can deliver features that their old, analogue counterparts could not do.

For ads, it was the promise of real-time tracking of their effectiveness. You could do “clickthrough rates” measuring how often the ad was clicked by a viewer. The holy grail of ad effectivity tracking is the fabled “conversion rate”: you can measure how many people actually bought your product after clicking an ad.

For signatures, it was the promise of automated validation. If you get a digitally signed document, you should be able to actually verify (and can have 100% trust in the result) whether it was really signed by the signatory. Remember: in the analogue world, almost nobody actually does this. The lay person can detect crude forgeries, but even that only if the recipient has access to samples of authentic signatures. In reality, a closer inspection of handwritten signatures is only done for important transactions, or in the case of a dispute.

So how did things work out after a few years of experience with digital ads and signatures?

Digital ads are in a midlife crisis. We’re in a death spiral of low clickthrough rates, more obnoxious formats, ad-blockers and ad-blocker-blockers. Just look at the emergence of Taboola and similar click-bait.
Digital signatures are at a cross-road as well: The take-up rates of solutions based on smart-card readers have been underwhelming so far. This applies to the German ePerso as well as to the Austrian citizen card. The usability just isn’t there. So there has been a push to increase the take-up rate by introducing alternatives to smart-card technology. That won’t make it more secure. Not at all.

So what’s the common lesson? In theory, both digital ads and signatures can offer features that their old, analogue counterparts just cannot deliver. In practice, they are killing themselves by over-promising. As long as click-through rates are the prime measurement of online ads, their death spiral will continue. And as long as digital signatures continue to promise instant, high-confidence validation, they will not achieve the take-up rates needed for broad acceptance.

Continuing the current trajectory will lead to a hard crash for both technologies. On one side it’s the ad-blocker, on the other side it’s malware.

The level of spam in the email ecosystem meant that no mail-service can exist in the market without a built-in spam-filtering solution. And given the early ad-excesses every browser includes a pop-up blocker these days. If the advertisers continue on their path of getting attention at all costs, ad-blocking will become a must-have feature in all browsers, and not just an optional ad-on (as right now).

Any digital security solution that protects actual money has been under vigorous attack. The cat and mouse game between online-banking defenders and attackers is a good lesson. The same will happen if digital signature solutions start to be actually relevant. And good luck if your “let’s make digital signatures more user-friendly” approach is actually less secure than what online-banking is using these days.

So what’s the solution?

In my opinion the right way to approach both topics is to reduce the promise. Make digital ads static images. No animation. No dynamic loading of js-code (which is its own security nightmare). Don’t overtax the visitor’s resources (bandwidth, browser-performance). No tracking. Tone it down. Don’t expect instant effects. Don’t promise clicktrough rate.

For digital signatures: Mass deployment is only possible for “non-qualified signatures”. Don’t promise “you can fully and solely rely on our solution”. Just sell “this is a good indication”, or “use this as one factor in your security design”. Prepare for it to be attacked and broken. Only use it when you have a pre-planned way to recover from such a breach. The real word is full of applications where signatures are used in a very low-security / low-impact settings. The state-sponsored digital identity solutions needs to think of those, too. For the high-impact, high-confidence settings I always have to think about the mantra we use at work: “You can’t mandate trust.”

The Edge browser

Wasn’t one of the main goals of junking the Internet Explorer codebase and building a brand new browser “Edge” the hope that there won’t be the monthly batch of patches for remote code execution vulnerabilities?

I haven’t tabulated the advisories but somehow I don’t have the feeling that things have gotten substantially better.


It looks to me like we still aren’t using the right programming environments for such complex pieces of software. There is still way too much basic security tooling the programmers have to do by themselves. Just like you shouldn’t do string operations in pure ANSI C, we need to rise the level of abstractions that all these browser bugs (that lead to RCE) just are not possible any more.

StartSSL, S/MIME and Thunderbird

This cost me an hour or two:

If you try to get a free S/MIME certificate from StartCom / StartSSL, this worked fine and in Firefox the certificate was shown as valid. But once I transferred it to Thunderbird, I got an unspecified certificate error.

Solution: Turn off OCSP.

Positive Surprise …

Wow, they put up new ticket vending machines at Brussels Central train station.

So instead of accepting only the Belgian-only cards, they finally work with international cards (Maestro, master/Visa), too.

Progress indeed. Welcome to 2014.

Net Neutrality und Peering Disputes

Nachdem die FCC sich schon um Verkehr-Diskriminierung auf der Kundenleitung gekümmert hat, hat sich jetzt die Diskussion auf die Zusammenschaltung von IP-Netzen verlagert.

Siehe Ars Technica:

Network operators Level 3 and Cogent Communications today urged the Federal Communications Commission to prevent Internet service providers from charging what they deem to be excessive fees for interconnection.

Im Wesentlichen klingt das für mich wie eine Neuauflage der Interconnection im Telefonbereich, wo der Zielnetzbetreiber ja auch ein Monopol auf die Erreichbarkeit seiner Kunden hat.

Die Unterschiede sind meiner Meinung nach:

  • Beim Telefon ist die Erreichbarkeit binär: entweder es geht oder nicht. Hier geht es auch um die Qualität, damit Video-Streams auch wirklich gut funktionieren.
  • Beim Telefon haben wir ein klares “Anrufer zahlt den ganzen Weg”-Prinzip, beim Internet-Anschluss zahlt der Privatkunden auch seinem ISP ernsthaft Geld, damit er Daten vom Content-Anbieter abrufen kann.

Hier in Österreich ist das Thema noch nicht kritisch, da sowohl die A1, als auch UPC und Tele2 eine relativ offene Peering-Policy fahren. Das kann man so etwa in Deutschland von der dortigen Telekom nicht behaupten.

Meiner Meinung nach ist es nur eine Frage der Zeit, bevor wir hier die ersten echten Streitereien (und damit den Ruf nach Regulierung, und sei es nur durch das Kartellgericht) haben werden. In der Schweiz war es schon soweit.


As you might have noticed, I haven’t posted a picture of a wooden train track for some time now.

The kids have basically outgrown that stuff (which does not rule out the occasional relapse), so we stopped building elaborate tracks.

But: we now got a decent number of Kapla blocks. At first sight, these are very trivial wooden cuboids. They open up suprisingly interesting possibilities of constructions. Just do a Google search for “kapla images”.

I’ve been building decent Kapla stuff with nephews over the last years, now I can do the same at home. I will post images of interesting results here.


Fundstücke …

Da suche ich heute was ganz harmloses auf Google (Postadresse eines BKA-Mitarbeiters), und dabei stoße ich auf folgende Perle der Geschichte:

Begutachtungsverfahren, Rationalisierung;
Nutzung der elektronischen Kommunikation, insbesondere auch bei Übersendungen an das Präsidium des Nationalrates

Das ganze stammt aus 1998, und enthält folgenden Text:

Grundsätzlich wurde in der Bundesverwaltung X.400 als die präferierte Mail-Basis vereinbart, die bereits weitgehend zum Einsatz kommt. Im Bereich der Landesverwaltung hat sich eher Internet-Mail durchgesetzt, was aber durch die möglichen Übergänge (sogenannte Gateways) zwischen X.400 und Internet keine Inkompatibilität bedeutet.

Probleme bestehen bei der Versendung über Internet insbesondere bezüglich der Bestätigung des Erhalts elektronischer Sendungen. Im Internet gibt es – von Standardisierungsansätzen abgesehen – noch keine flächendeckende Problemlösung, da die von Systemen gelieferten Empfangsnachrichten nichts über den Empfang durch den Anwender selbst aussagen; etwas Hilfe bieten einige Mail Clients mit Anwender – konfigurierbaren Respondern. Diese Problematik ist bei X.400 von Anfang an gelöst.

Aus Gründen der Übertragungsqualität und -sicherheit wäre im gegebenen Zusammenhang jedenfalls – dort wo bereits vorhanden – X.400 der Vorzug zu geben.

So kann man sich täuschen.

Das erinnert mich an einen Artikel in den DFN-News von ~1990, in denen das Internet im DFN als Zwischenlösung (bis sich OSI durchsetzt) bezeichnet wurde.

Imitation is the sincerest form of flattery

2007: https://tools.ietf.org/html/rfc5105#section-7

The concept of the validation token may be useful in other registry-type applications where the proof of an underlying right is a condition for a valid registration.

An example is a Top Level Domain (TLD) where registration is subject to proof of some precondition, like a trade mark or the right in a name. Such situations often arise during the introduction of a new TLD, e.g., during a “sunrise” phase.

2013: https://tools.ietf.org/html/draft-lozano-tmch-smd-02

I thought the IETF discouraged re-inventing the wheel?