Skip to content
ROC HandbookCare and support in England, read from the law and dated.

The desk

Privacy

These pages are static files: no account, no form and nothing fetched from another domain while a page loads. The one thing a reader can send is an email to contact@roc-uk.org, and this page says what happens to it.

Last checked on 3 September 2026

A metal combination padlock closed through the ring of a binder, resting on a blank sheet of squared paper
A metal combination padlock closed through the ring of a binder, resting on a blank sheet of squared paper: a lock on a ring that holds nothing yet.

What does this page cover?

It covers this handbook and the single address that reaches it, contact@roc-uk.org. That is the whole territory. There is no account to open, no form to fill in, no comment box, no newsletter and nothing to buy, so there is no profile, no subscription and no order to describe. What follows is the mechanics of the two things that do happen here: pages being read, and messages being answered.

What do the pages load?

A page here is one HTML file, one stylesheet held on the same domain, the page's own photograph, and a block of structured data describing the page for a machine that indexes it. Nothing is fetched from another domain while a page loads: no font, no analytics file, no advertising code, no sharing button, no consent banner. The photographs are the only files a page pulls in beside its stylesheet, and they come from the same domain as the page. The structured data block is text about the page rather than a program, so there is nothing in a page here that runs, measures or reports back. What the browser shows is what the file contains, and a reader who wants to confirm that can open the file and see it.

What is stored while you read?

Nothing, by the pages. They are static files served as they were built, and they contain nothing that writes to the browser: no cookie is set, no identifier is created, and nothing is left behind when the tab closes. The pages are the same for everyone who opens them, because there is no profile to tailor them to and no history to continue from, so the eleventh page read looks exactly like the first. What the hosting of a site keeps in its own records is a separate question, and it is a fair one. It is not answered by these pages, because the answer lives with the service that serves the files rather than in the files, and a guide that guessed at it would be guessing on a page about exactness.

What about the feed?

The dated notes also go out as a feed, at /feed.xml and at /rss.xml, which is the same list at a second address. A feed is a file that any reader application can fetch, which means there is no subscription to join and no list of subscribers to keep: the file is there, and reading it is between the reader and the reader. Following a source link out of this site is the same kind of step. The sources are public sites with practices of their own, and a link here is a reference to a document rather than a handover of anything.

What happens to a message sent to the address?

It is read at the desk that writes the pages, and it is used for the purpose it was sent: a correction to a sentence, a question about a source, a request to reuse a page or a table. The reply is about the page. When a correction is accepted, the sentence changes and the change is logged with its date in the notes; the note describes what moved and names the source it was checked against. Correspondence is not quoted in the notes, and no mailing list grows out of a message, because there is nothing here to subscribe to.

A message is more useful without personal detail. A correction needs a page, a sentence and a source, and none of those is about you. If a message seems to need a person's situation in order to make sense, leave the names out: a guide can act on the document and the date, and an individual case belongs with a service that can act on the case.

How is a message removed?

Ask. The way to ask is to write to the desk from the address the message came from, saying what should go. A request like that is carried out rather than argued over, and the confirmation comes back the same way. What stays is the published note recording a correction, because the note records a change to a page and not the person who suggested it: the change is part of the handbook, the suggestion is not.

When does this page change?

When the mechanics do. The stamp at the top carries the date this page was last checked, and a change in what the site loads, keeps or asks for moves the stamp. The page sits inside the handbook and is written under the same rule as the rest of it, which is that a statement on it is a statement about the site as built; how this site works sets out the method behind the pages this one describes. The other half of the arrangement, what may be done with the pages themselves, is on terms of use, and it is written to be read alongside this one rather than instead of it.

Why is a privacy page written at this length?

Because a short list of promises is easy to write and hard to check. Describing the mechanism takes longer and lets a reader do the checking instead: the pages can be opened, the requests they make can be counted, and the absence of a form is visible on every page that would have carried one. That is the standard the rest of the handbook is held to, and this page is not exempt from it.