On This Page
- Server Log Retention Policy
- E-mail Retention Policy
- Affiliate Links
- Security and Spying
Other About Pages
Unlike other sections of this site, the About section contains site policies and statements.
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.
Twitter, Youtube, 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".
Fonts cookie missing. If you are not on a low bandwidth connection, please .
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) <firstname.lastname@example.org>").
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.
Some links on this site are affiliate links, and are indicated as such either through an icon or text preceding or following the affiliate link.
While I will always try to be forthcoming about links being affiliate links, I may occasionally forget to add a disclaimer or icon. As with any other issues with the site, you can Tweet me @WatfordJC.
As with other affiliate links, I will either mention in the text before or after an Amazon affiliate link that the link is an affiliate link (or words to that affect) or I will use an icon like so:.
John Cook is a participant in the Amazon EU Associates Programme, an affiliate advertising programme designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.co.uk.
Security and Spying
For services hosted with OpenITC, 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.
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.
Hurricane Electric are US-based, and my IPv6 prefix(es) from them are delegated from ARIN. My .com domain is also "within U.S. jurisdiction" according to ICE.
My IPv4 addresses and IPv6 addresses from OpenITC (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), 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.
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.
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.
To my knowledge, all other content on this site is hosted in the UK, and served from RIPE-/ARIN-delegated IPv4/IPv6 IP addresses.