13 January, 19–20 and 24–. This privacy statement remains in force, but see also the 2018 Privacy Statement R. Harmsen, under the GDPR.
The website uses web server software Apache 2.4.33 (reference date 16 May 2018), running under FreeBSD 10.4 (reference date 16 May 2018) on a VPS (Virtual Private Server) hosted by Tilaa.nl.
The default Apache logging is enabled. A typical logging of one page visit may look like this:
10.11.12.13 - - [19/Feb/2013:16:21:51 +0100] "GET /lingtics/noch.htm
HTTP/1.1" 200 1490 "http://rudhar.com/lingtics/lingtics.htm"
"Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
10.11.12.13 - - [19/Feb/2013:16:21:51 +0100] "GET /cgi-bin/colschem.cgi?url=toegesta.css
HTTP/1.1" 200 1208 "http://rudhar.com/lingtics/noch.htm"
"Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
10.11.12.13 - - [19/Feb/2013:16:21:51 +0100] "GET /cgi-bin/colschem.cgi?url=textfont.css
HTTP/1.1" 200 1441 "http://rudhar.com/lingtics/noch.htm"
"Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
10.11.12.13 - - [19/Feb/2013:16:21:51 +0100] "GET /cgi-bin/colschem.cgi?url=advert.css
HTTP/1.1" 200 1434 "http://rudhar.com/lingtics/noch.htm"
"Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
At the start of each logging line was my own IP number, because for the test, I myself was the website visitor. However I changed it to a meaningless number for display on this web page.
That one visit to one web page causes several logging lines, is because the HTML files invoke CSS files that contain formatting information. These in turn often invoked other CSS files. I call them through CGI, because of the way I implemented colours.
Once every five hours the Apache log file, after removing visits by
known robots, is reduced to only the most recent 3000 lines.
Algorithm:
tail -3000 access_log > a; cat a > access_log; rm a
In practice, that means the visit logging data is kept
for about 3.5 to 4 days, then deleted. Example: measured
at Tue Feb 19 18:08:17 CET 2013, the first
lines dated from
15/Feb/2013:22:43:53 +0100. The next day
at 11:55, the first line was from 17 February at 08:00.
Apache’s visit logging data is used automatically to display some live statistics: recently visited pages and a count of popular pages. There is also a randomised list of unpopular pages, i.e. randomly selected pages from the site map, corrected for recent visits.
None of these statistics display any personal information: no IP numbers and no search terms.
Sometimes, as a webmaster and writer, I get curious when
I notice that a page gets more visits than usual. What
causes this interest? I then occasionally look up an IP
number using tools like ‘whois’
and ‘nslookup’. This doesn’t
tell me who the visitors were – and I do not really
want to know – but it may sometimes reveal something
about the country the visitor visits my page from and the
language of preference.
Such information may help me set priorities for future writing activities: it is more fun to write things that are more unlikely to find a audience.
Sometimes, hits from search engines like Google reveal the search words that were used to arrive at a page. Here is a real-life (but trimmed and slightly modified) example:
10.11.12.13 - - [17/Feb/2013:20:05:52 +0100]
"GET /foneport/en/foneport.htm HTTP/1.1" 200 75124
"https://www.google.co.us/url?sa=t&rct=j&q=european%20portuguese%20pronunciation
&[..rest skipped..]
So here someone was looking for info about
“european portuguese pronunciation”
and found it (I hope) on
my site.
It’s interesting. Yet I look at such information only occasionally. Rarely, if ever, in fact. Maybe 3 or 4 times a month.
The webmaster will never pass web page visit logging information on to third parties, unless legally required to do so, for example by court order. That latter situation is not something I reasonable expect to ever happen, because I cannot imagine a valid reason.
I do not offer other people the possibility to post comments under my articles. That means I cannot be held responsible for such comments. This too makes it quite unlikely that a court order might ever force me to reveal personal details of guest commenters.
I did occasionally publish articles on my website, written by guest authors. But it is a rare occasion. The authors’ names were openly mentioned, with their permission.
Where notice&takedown procedures are concerned, I intend to comply with any applicable legal requirements, if the situation might ever occur.
This site does not itself employ any Flash cookies.
The only case where this website uses a cookie, is to remember a colour preference of the visitor, made known by clicking on a link. More details are here and (in Dutch only) here.
In my view this colour preference cookie is ‘strictly necessary’ (Dutch: “strikt noodzakelijk”) in the sense of the recently added article 11.7a, clause (“lid”) 3b of the Dutch Telecom Code, and also “strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user” in the sense of EU Directive 2009/136/EC, “whereas”-item 66 on page 20; that “specific service” being: being able to see the website with the preferred colour scheme.
See also the amended article 5(3) on page 30 of Directive 2009/136/EC:
“or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.”
The cookie is necessary to get the site in a specific colour scheme. The cookie need not be set and may be deleted. In that case, from then on the colour scheme will be the default one and the website content is still fully accessible.
Sitemeter used to be used by this website to obtain visit statistics. But Sitemeter uses third-party cookies. Therefore, in view of the amended Dutch Telecom Code, all Sitemeter counters were rigorously removed from this website.
Google Adsense used to be used by this website to gain some income by showing adverts. But Adsense uses third-party cookies. Therefore, in view of the amended Dutch Telecom Code, all Adsense adverts were rigorously removed from this website.
Several articles on this website contain promotional links to web store Bol.com. If people follow such a link and actually buy something in that store, I earn a small commission.
A list (in Dutch) of pages containing such promotional links is here. Displaying one of my pages with such a link, does not yet set cookies. But clicking one, means going to Bol.com’s site, and that does cause cookies to be set. Not my cookies, but Bol.com’s.
I suppose these fall into the category of strictly necessary cookies, in the sense of the Dutch Telecom Code and the EU Directive. That means Bol.com uses them to identify separate steps in the website’s dialog with the visitor, who might eventually buy something.
My page
https://rudhar.com/musica/ruivelte/en.htm
has Youtube.com videos embedded using iframes,
used to illustrate the point I am making in that page
of mine.
Unfortunately, Youtube tries to set cookies even before the videos are played, merely by showing they can be played.
These cookies are not mine, I don’t want them to be set and I don’t use them. If you don’t want them to be set, you can block cookies from Youtube.com, or block third-party cookies in general, using the settings of the browser program you are using (examples of browser programs are: Internet Explorer, Mozilla Firefox, Google Chrome, Opera).
The page
https://rudhar.com/toerisme/lmrkstyn/nl.htm
is an account of a holiday walk we had. As an illustration of
where we were, I embedded (iframed) two maps with
photographs, provided by Google Maps.
Unfortunately, maps.google.fr tries to set cookies just for the display.
These cookies are not mine, I don’t want them to be set and I don’t use them. If you don’t want them to be set, you can block cookies from maps.google.fr, or block third-party cookies in general, using the settings of the browser program you are using (examples of browser programs are: Internet Explorer, Mozilla Firefox, Google Chrome, Opera).
Some pages of this website can accept data, supplied by the user, apply an algorithm to them, and display the calculated results.
Examples are:
The input data is sent to the site unencrypted, no SSL
is used. This can be recognised by the URL having
http://, not https://.
The same is true of the output data that is sent from the website to the user.
The input data is stored only briefly in temporary variables, merely for the purpose of the calculation. No logging of any data takes place.
In addition to a web server, the VPS also
contains an e-mail server. The e-mail server uses
sendmail to implement the protocol SMTP. Spam is
reduced as much as
possible, using milter-greylist and
spamassassin.
The e-mail server keeps mails in storage for only a few days. Mails are transferred regularly (by ‘checking the mail’) from the e-mail server to the webmaster’s personal computer. This transfer uses the protocol POP3.
On the personal computer, an extensive e-mail archive is kept, encrypted in a virtual drive created using Bestcrypt software by Jetico. Backups are also encrypted. This means only the webmaster can have access to the e-mail archive.