Guidelines for Dutch governmental websites
Dutch governmental websites have to be accessible to all citizens. Guidelines have been created to accomplish that goal. A large part of it covers user experience. GRRR has already written a post about that and colleague Michèle wrote an article on Frankwatching about the subject. This post covers both technical and non-technical aspects of analytics, email and security because fulfilling those properly uses different disciplines. Just skip the parts you don't have to understand.
Who’s who
Let’s start with an overview of involved parties and names. It took me a while to figure it out. Most words are in Dutch but won’t be more clear after translating them. So I give you an explanation of the Dutch words:
- DigiToegankelijk Basically a layer on top of WCAG. The website contains news, updates and explanations about the guidelines for website accessibility.
- CommunicatieRijk is a website about communication between government and citizens. It’s very broad and covers both technical and non-technical aspects of communication. They cover subjects like visual identity of the government, writing speeches or dealing with polarization in society. This post will cover the technical guidelines this organization created for Dutch governmental websites.
- Het Nationaal Archief is the governmental organization responsible for storing and researching the Dutch history. Its collection consists of 137 km of documents, 15 million photographs and nearly 300.000 historical maps and drawings and 800 terabytes of digital files. 😳
Comply or explain
When it’s not possible to comply with a guideline it’s possible to explain why you can’t comply. “Comply or explain” is an approach used by governments to regulate something without having to create a law.
Website analytics
Which tool do you use to do website analytics? The most common answer is Google Analytics, because it’s free, easy and integrates well with other (Google) tools. But the Dutch government doesn’t want their data to be stored on foreign servers. So no Google Analytics or other foreign hosted tools.
Piwik is a well known open source Google Analytics alternative. The current state of the project isn’t very clear to me, but the project is renamed to Matomo. That company offers services on top of the open source software. PiwikPRO does the same. A quick search for “google analytics alternatives” gives a lot of other possibilities. I’m not going into details on all those systems, but the Dutch government offers PiwikPRO as a tool for website analytics: statistiek.rijksoverheid.nl. It’s hosted by the Dutch government, so you don’t have to worry about possible foreign data storage. Governmental organizations can request the Ministry of General Affairs for an account. The tracker API is very similar to Google Analytics.
SSL certificates
The Dutch government issues their own certificate PKIoverheid and government websites are obligated to use it. PKIoverheid certificates comply with the European regulation to support Qualified Website Authentication Certificates (QWAC)1. To get a certificate the owner of the website has to contact one of the official companies that are allowed to issue PKIoverheid certificates.
📖More information from CommunicatieRijk about HTTPS, TLS and certificates in Dutch.
Email security and spam
Secure email covers in my opinion anti-spam, anti-phishing, anti-spoofing and unauthorized reading. A wide variety of fast evolving techniques are available to prevent bad things from happening. I’ll give you an overview. Within a year I expect this information to be outdated, because adoption rates, opinions, users and spammers change. Sending emails around the world seems easy, but doing it securely requires a lot of precautions to be taken. Let’s get started.
STARTTLS and DANE are techniques to encrypt communication between email servers. Support for STARTTLS is very common, but for DANE it isn’t. To support DANE, email servers have to support it, a TLSA record must be added to the DNS zone and DNSSEC must be enabled. DNSSEC is necessary because DANE relies on a DNS record with an encryption key in it. Without DNSSEC it’s possible to manipulate the DNS response which makes it possible to change the key in the TLSA record. Mail server software support is good nowadays and DNSSEC is generally available for TLDs. So building an email server with DANE support is possible, but cloud email providers barely support DANE. So you can’t use cloud email providers like Office 365 and G Suite. ProtonMail does support DANE but that’s a Swiss based company.
Most cloud email providers don’t have the option to only store data in The Netherlands, another reason why it’s not possible to use them. But it could be possible to find a provider which supports hosting in The Netherlands or explain why you can’t comply with this guideline.
📖More information from CommunicatieRijk about STARTTLS and DANE in Dutch.
SPF and DKIM are techniques to detect forging sender addresses during the delivery of an email. By changing the From header of an email a spammer is able to make the message look legit. SPF gives the receiving email server the ability to verify the sending server. A DNS record contains a list of addresses which are allowed to send email on behalf of that domain.
To comply to SPF you have to add a TXT record to your DNS zone. Let’s give an example: I have an organization called GRRR with email sending domain grrr.nl. It has an email server on mail.grrr.nl and sends newsletters with Mailchimp. The SPF record of grrr.nl will look like this:
v=spf1 include:mail.grrr.nl include:servers.mcsv.net -all
This means mail.grrr.nl and servers.mcsv.net are allowed to send e-mail on behalf of grrr.nl. All others (-all) are not allowed to do that.
📖More information from CommunicatieRijk about SPF in Dutch.
With DKIM enabled the sending server signs messages with a private key. The receiving server validates the message with the public key published by a DNS record. So with DKIM you’re sure the message was sent from a legit server. It’s slightly harder to implement than SPF, because all sending servers have to sign with the right private key. If one of your services doesn’t do that the message will likely be marked as spam.
DKIM must be enabled on your server or in your app. There’s no generic explanation on how to do that, because it varies per service. After enabling DKIM you have to add a DKIM record to your domains’ DNS zone. DKIM uses a special TXT record to publish the public key. It could look like this:
v=DKIM1; k=rsa; p=MIIBIjANBgk and the rest of the public key;
DKIM records are published with subdomain label _domainkey and a selector. With the selector you can distinguish multiple public keys. This makes revoking a compromised private key much easier when you give every service it’s own key. You can for example use default for your email server and newsletter for your newsletter app:
default._domainkey.grrr.nl TXT v=DKIM1; k=rsa; p=public-key-x;news._domainkey.grrr.nl TXT v=DKIM1; k=rsa; p=public-key-y;
📖More information from CommunicatieRijk about DKIM in Dutch.
After enabling SPF and DKIM it’s time to enable DMARC. With DMARC a domain owner can specify what to do with a message when SPF or DKIM fail. It could deliver, quarantine or reject the message. To get insight in the message sent on behalf of your domain you can add a reporting address to the DMARC record.
DMARC records are published with subdomain label _dmarc. For example _dmarc.grrr.nl.
Let’s use an example to explain all the options.
"v=DMARC1;p=none;pct=100;rua=mailto:reports@grrr.nl;"
This DMARC record uses the policy “none” (p=none) on 100% of the messages (pct=100) and sends reports to reports@grrr.nl. With this record your security won’t increase, but by analysing the reports you’re sure all your email servers are properly configured.
To increase security you can adjust the records and let it reject every message that doesn’t pass SPF or DMARC.
"v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:reports@grrr.nl;"
The policy has been changed to reject message (p=reject) including messages sent by subdomains (sp=reject). The other options didn’t change: apply policy to all messages and send email reports.
Use the pct option to slowly apply the policy to all messages. It saves from a potential big spike in delivery failures.
📖More information from CommunicatieRijk about DMARC in Dutch.
Archiving
Storing historical information is obligated by law2. The Dutch government requires all data it creates to be archived. After 20 years the archives must be made public. The archived information could be used for legal reasons, to validate democratic processes or historical research. This law is about data – which includes websites. Het Nationaal Archief created guidelines to make it easier to comply with the law. It’s in Dutch so I give you a short summary: hire a specialised company. Doing it yourself is hard because you have to scrape, store, and backup data, ensure data integrity and make it publicly available.
In retrospect
I hope this post gives you an overview of the involved techniques, guidelines and organizations that affect your governmental website. This subject is prone to change and opinions so don’t hesitate to give me feedback or share your opinion.