Cookie statement

This statement records what trygglabs.co.uk does with storage on the device you are reading it on, and what it asks of servers outside this site. It covers these pages and nothing else.

It sits alongside the privacy notice, which deals with information the practice holds about identifiable people and with the rights attached to it. The division is simple: that document is about records held here, this one is about your device and the requests this page makes.

Anything built for a client is outside the scope of both. Section 9 explains why, and what the practice does about it.

The governing provision is regulation 6 of the Privacy and Electronic Communications (EC Directive) Regulations 2003, which is read alongside the UK GDPR. Putting information onto the equipment a reader is using, or retrieving information already sitting there, calls for a clear explanation of what is happening and an agreement to let it happen.

The wording turns on storage and access, not on the word cookie, so everything of that shape is caught: local storage, session storage, an indexed database, a tracking pixel, a script assembling a fingerprint out of whatever the browser gives away. Picking a different technology moves nothing.

The exemption, and how narrow it is

Where storage is genuinely required to deliver something the reader asked for, no agreement is needed. The Commissioner construes that tightly. Holding a site up under hostile traffic sits inside it. Counting how readers move around a site sits outside it however the counting is described, on the straightforward ground that the reader came for the page and not for the measurement.

Two cookies, both belonging to the hosting provider, neither written by this site's own code.

Neither one carries an identifier this practice can read, and neither is used for any purpose beyond keeping the site available. Nothing else is written: no analytics identifier, no advertising cookie, no tag from a social platform, no session recorder, no data placed in local storage or in an indexed database by anything served from this domain.

There is also nothing to log into and no form to submit, so the usual reasons a site accumulates storage do not arise here.

A banner is a device for gathering permission. Both entries in the table above sit within the exemption, which leaves nothing to seek permission for, and putting one up would mean asking a reader to agree to nothing whatever.

Doing that carries a cost rather than being merely redundant. Readers learn to click past a control that does real work on other sites, and the banner itself implies an activity this one does not carry out.

Should something requiring permission ever be introduced here, the order of events is settled in advance. This page changes first and its version moves with it. The question is then put before the thing loads, with declining made no harder than agreeing. The answer is kept with its date and with the exact wording that was on screen when it was given.

The typefaces on this site are served by Google rather than from this domain. Rendering a page therefore involves two hosts operated by Google: fonts.googleapis.com for the stylesheet, then fonts.gstatic.com for the font files it names.

Google learns three things from it: the network address the request came from, the browser string the device sends, and which page referred it. Google's published position is that the Fonts service writes no cookie and puts none of these requests to advertising or profiling use. Regulation 6 has no application, because the request puts nothing onto your equipment, but a network address counts as personal data under the UK GDPR, so the request is set out here instead of being left unmentioned.

Hosting the files on this domain would end the request altogether, and that change is queued rather than dismissed. Until it is made, this is the description. Blocking both hosts leaves every page here entirely readable in whatever face your system substitutes, because nothing on the site depends on the typefaces arriving.

A server that answers a request keeps a note that it did so. The provider serving these pages retains the network address, the time, the path asked for, the browser string and the code it responded with.

A log of that kind touches nothing on your equipment, which puts it outside regulation 6 entirely. It does not put it outside data protection law, so the privacy notice carries it: legitimate interests under Article 6(1)(f), for the purpose of delivering pages and keeping abusive traffic off them, retained for under thirty days on the provider's rolling cycle. The log is combined with no other record, and there is no other record here to combine it with.

Every statement in section 3 and section 5 can be verified from your own browser in about a minute, which is a better assurance than the paragraph you are reading.

1. Open the developer tools your browser provides, on any page of this site.
2. In the storage panel, look at what has been written for this domain. The two provider cookies are what you should find, and nothing else.
3. In the network panel, reload the page and read the list of hosts contacted. This domain and the two font hosts are the whole of it.

If what you find differs from what is written here, that is a fault in this document and the address in section 10 is where to report it. A statement of this kind is only worth publishing if somebody can hold it against the evidence.

Every current browser will block storage for a named site, clear what has already been written, and show you the contents. The control lives under a privacy or site-data heading in settings; the exact path shifts between releases often enough that the browser's own help page is a better guide than a list printed on a page like this one, which would be stale within a year and would then be wrong with confidence.

Blocking the two entries in section 3 has one consequence worth knowing. The provider may put a challenge in front of you more often, because the record that you already passed one is what it has been blocked from keeping. The pages themselves are unaffected.

Signals sent by the browser

Global Privacy Control is honoured here, as is the older Do Not Track header. Neither commitment costs anything, since there is nothing running that either signal would switch off. It is recorded anyway, because a site that receives those headers and disregards them without saying so has made a decision it is relying on nobody examining.

What is written above describes trygglabs.co.uk. None of it should be read as a description of a system the practice has built or reviewed for somebody else, and one is no evidence at all about the other.

In that work the controller is the client, and what a client's own system keeps on a visitor's device is the client's decision to take. The practice contributes a written assessment before launch: item by item, which ones the exemption genuinely covers, which ones require an answer from the visitor, and the reasoning for placing each where it is placed. Where a client would rather see a non-essential item described as essential in its banner, the answer is no and the refusal goes in writing.

Questions about this page go to the address above. A data protection request is handled under section 13 of the privacy notice and answered inside the statutory month.

A concern that is not resolved here can be taken to the Information Commissioner, whose postal address, telephone number and website are set out in section 15 of the privacy notice.