About

My name is John Cook and I live in Watford (the one in Hertfordshire/Herts), hence one of my online handles being WatfordJC (other handles include TheJC and JAWC).

This page contains details relevant to these websites.

On This Page

Other About Pages

Unlike other sections of this site, the About section contains site policies and statements.

Cookie Policy

These sites currently use one cookie, plus any third party cookies from embedded content.

Third Party Cookies

Third party cookies are cookies that are not set by the domain you are visiting. That is to say cookies not set by the domain in the address/location bar.

Google set third party cookies when you visit the Site Search page as I use Google Custom Search Engine.

How Google uses data when you use our partners' sites or apps

Youtube, Vimeo, and others may set third party cookies for content that is embedded on this site.

Other than the Site Search page, no content is automatically embedded on this site. For example, YouTube and Vimeo videos now require you to click a "Play Video Embedded" button for the content to be embedded on the page.

Where possible I also include links/buttons to third party content providers' pages for their privacy and (if available) cookie policies next to the links/buttons that embed the third party content on the page.

The __cfduid Cookie

I no longer use CloudFlare. Keep reading to see how to quickly remove any __cfduid cookie remnants.

This cookie is set by Cloudflare, a Content Delivery Network (CDN) for "security purposes".

Note: This cookie is strictly necessary for site security operations and can't be turned off.

Cloudflare, What does the CloudFlare cfduid cookie do?

I no longer use Cloudflare on my sites. To ensure this cookie no longer exists in your browser please visit https://johncook.uk/about—the redirect page will set the cookie to expired and redirect you to the canonical URL for this page. Your browser deletes expired cookies.

The fonts Cookie

The "fonts" cookie is stored for 30 minutes with a value of "1".

If you visit another page on the site, the expiry time on the cookie gets reset.

It is not sent only over HTTPS (it is not a secure cookie), nor is it valid only for HTTP (scripts can use it as well).

It can also be cached and seen by intermediaries and those on your network (if you are not connecting to the sites over HTTPS).

The purpose of the fonts cookie is pretty self-explanatory. If you have the fonts cookie, your browser tells the server hosting these sites "I have the fonts cookie, so I probably already have the fonts".

The fonts cookie is intended to make the site load faster. If your browser doesn't send it, you will see the following box if you have JavaScript enabled:

Upon clicking load fonts the fonts are loaded using the JavaScript font loader.

Currently with JavaScript font loading all text is dimmed for up to 15 seconds while the fonts are loaded. If they can't be loaded (or are still loading) after 15 seconds the text is undimmed and a Flash Of Unstyled Content (FOUC) may occur if the fonts load late.

With the cookie, the fonts are added to the <head> html section of each page by the server. When included in the <head> section, they are "blocking" and prevent your browser from rendering the page until they have been downloaded.

Thus, if the fonts cookie is set, you have viewed a page on the sites recently in your browser and either (a) already have the fonts in your cache, or (b) have browser settings (css and/or web fonts) configured so that fonts in the <head> section are ignored (and are therefore not "blocking" even if you don't have the fonts).

The pages on these sites can be cached by your browser and intermediary web caches. The sites send cache headers indicating that content may differ based on User-Agent (for outdated browser alerts), Cookie (page content differs based on fonts cookie), and Accept-Encoding (for example, a gzip compressed page is different in size and content to an uncompressed page until it is uncompressed).

Server Log Retention Policy

The raw server logs for visits to these sites (i.e. for all HTTP(S) requests on the server(s)) are stored indefinitely.

The raw DNS server logs (including for DNSCurve) are retained for a currently indeterminate time.

The raw e-mail logs (for incoming and outgoing mail including rejections and bounces) are retained for a currently indeterminate time.

Intermediaries may also be keeping logs.

E-mail Retention Policy

If you send spam e-mail to me and it isn't rejected by the server, it will be retained until it is no longer needed for abuse reports unless I decide to retain it. All e-mail I classify as spam will potentially be passed on to others.

If you send e-mail to one of my e-mail accounts that isn't spam, it will be retained indefinitely unless I decide to delete it. If neither S/MIME or PGP encryption is used, I shall assume it is not confidential unless stated otherwise (excluding standard footers - if all e-mails from an account are confidential information you should be using a From address that makes it clear to avoid shoulder-surfing, such as "John Cook (confidential) <some-mailbox@example.com>").

If you send mail to my Gmail account, it currently will be retained indefinitely, including in any backups Google make and any backups I make. The same rules as above will be applied when it comes to encryption and confidentiality.

Processing of Personal Data

Personal data may be processed automatically as should be expected from electronic communications. For example, if you e-mail me then mail servers between your e-mail client and my home mail server will process your name and e-mail address in order to deliver the e-mail and/or reject the e-mail and deliver a bounce/non-delivery notification.

Typical personally identifiable metadata that might be found in logs of all mail servers an e-mail passes through include your name (if the From: header contains one), your e-mail address, and the recipients name and e-mail address (if the To: header contains one). The date and time an e-mail was originally sent, was received by a mail server, and was forwarded by a mail server, are also typically processed in order to log how long it took an e-mail server to pass the message along.

When e-mail reaches one of my relaying mail servers or my home server, your e-mail address will be processed in order to verify DKIM, SPF, and DMARC policies. Your name and e-mail address may be processed in order to reject e-mail from you if I have blacklisted your e-mail address (or to compare your name to a string such as "FedEx" if I have a policy that restricts who can send e-mail purporting to be from someone), as well as to automatically organise inbound e-mail into sender-specific mail folders.

The entire contents of e-mails are automatically scanned by a virus scanner on my home server.

If you are sending e-mail from an IP address that is personally identifiable (e.g. through FCrDNS or because it is from your home mail server and only you use that IP address), that IP address will likely be stored by all mail servers your messages pass through. That IP address will be automatically processed on my servers for various mail receiving purposes, including FCrDNS checks, SPF checks, DNS lookups, DNSBL checks, and DMARC reports.

Messages I deem are spam may be processed by third parties both inside and outside the EU, such as SpamCop and your ISP, in order to report spam and improve DNS blocklists.

Personally identifiable information such as your e-mail address, name, IP address, domain name, and/or any data contained within an e-mail or other communication such as SMS may be manually processed using utilities such as grep and find in order to find a particular communication.

Security and Spying

For services hosted with OpenITC LoveServers and VMHaus, I do not have full control over the security and privacy of data and traffic. Based on my current understanding of the abilities of Deep Packet Inspection (DPI), security and privacy of traffic should be higher if you connect using TLS and/or CJDNS.

This is because using HTTPS and/or CJDNS, inspection of the data contained within traffic should only be possible within my virtual server, rather than at a higher level (i.e. at the host node or data centre level).

It should be noted, however, that because some of my sites now use Cloudflare that TLS termination of your connection to those sites is now done at Cloudflare, rather than at my VPS. Although I have turned on Strict HTTPS in Cloudflare encrypting the connection between Cloudflare and my VPS, it is possible that Cloudflare intecept traffic.

Some of my domains use Hurricane Electric for backup DNS, so if you are concerned about U.S. authorities being able to pressure a company that has links to the U.S. into disclosing your DNS requests, set-up your firewall to reject (rather than drop) outgoing DNS packets to their IP addresses (note: may cause connectivity problems to others' websites/services).

Alternatively, create a DNS caching proxy that has an option for specifying a list of sites that must be contacted over DNSCurve. As of 2015, none of my domains' DNS are currently protected by DNSCurve.

I use Hurricane Electric for some of my IPv6 addresses and some of my sites are only accessible over IPv6. Most of my IPv6 sites are secured by HTTPS, although HSTS is disabled for the time being slowly being rolled out to all of my domains.

Hurricane Electric are US-based, and my IPv6 prefix(es) from them are delegated from ARIN.

My IPv4 addresses and IPv6 addresses from OpenITC LoveServers (UK-based) and VMHaus (UK-based) are delegated from RIPE. My IPv6 prefix(es) from Netassist (Ukraine-based) are also delegated from RIPE. My .uk domains are delegated from Nominet (UK-based). I am currently waiting to hear whether U.S. jurisdiction also applies to RIPE and Nominet since the IANA/ICANN are US-based.

It is my current understanding that the worst the U.S. could do is steal my .com domain and IP addresses and launch a Man In The Middle (MITM) attack on visitors.

Although my TLS certificates are issued by StartCom (Israel-based) Let's Encrypt (US-based), it is possible for the U.S. authorities to create a fake certificate issued by one of the other certificate authorities trusted by browsers that they have control over, so HTTPS is no certainty that you are really connected to my website. This is a larger potential issue for sites where I am using Cloudflare. Certificate Transparancy and CAA DNS records should mitigate this.

For connections over HTTPS and CJDNS, it would almost certainly require someone in the data centre with access to the host node and my VPS for a MITM attack to occur on such connections.

As long as my server has at least one functioning IP address, I should be able to route around any censorship instigated by the United States, although it may require making the site less available (e.g. only browsers with SNI support, only IPv6 connections, only a particular darknet, only a particular alternate DNS root, etc.).

Mail stored with Google may potentially be secretly intercepted by U.S. authorities, and all e-mail stored with Google that is at least 180 days old may be secretly inspected by U.S. authorities without a court order.

Phone calls to me that are routed over SIP may be intercepted by U.S. spies, U.K. spies, and any intermediaries including but not limited to: those on your network, your ISP, your ISP's Internet exchanges, Internet backbone providers, and others.

If calling me by phone number or SIP, I advise using a SIP client that has ZRTP support: although call metadata may still be available to any intermediaries, call content should not be, depending on if the encryption algorithms are cracked/weakened, and whether or not ZRTP encryption is available at my end. I do not currently have ZRTP support available.

Once my new websites are up and running, my home Internet access is sorted out, and I have investigated bringing all my e-mail "in-house" (including shifting away from Gmail), I will investigate setting up a separate sub-domain for highly secure (and potentially slower) connections to each website/service.

Web fonts and jQuery used on my sites are currently served by Google's Content Delivery Network (CDN). Open Graph RDFa prefixes are from ogp.me, a domain registered by Facebook, Inc. with a Montenegro (.me) country-code top-level domain (ccTLD), and is currently served from Amazon's EC2 CDN using ARIN-delegated IP addresses. Twitter widgets are currently served by Twitter, from Edgecast Networks CDN using ARIN-delegated IP addresses. In order to improve loading times of the widget, any twitter quotes of mine have my profile thumbnail image added using JavaScript which is hotlinked to twitter, thereby ensuring a HTTPS/SPDY connection to twitter is established prior to the following of links to specific tweets.

To my knowledge, all other content on this site is hosted in the UK, and served from RIPE-/ARIN-delegated IPv4/IPv6 IP addresses, although content served by Cloudflare is served from Cloudflare's ARIN-delegated IPv4/IPv6 direct allocation IP address blocks.

Note that I have now enabled Cloudflare for some of my domains. As Cloudflare use Anycast IP addresses it is not possible to determine which countries your traffic to my domains pass through nor where the edge servers that serve your requests is located.

Posted by on .

Last updated on .

Accessibility

I have alluded to having a list of accessibility issues in previous articles - such a list does exist.