SOP Maker › SOP Maker for IT

SOP Maker for IT: what it accesses and what leaves your network

Somebody in quality or hygiene wants to use this tool, and you have been asked whether a website should be reading and writing files on a company machine. This page answers that without you having to take anyone's word for it.

SOP Maker is free offline software for writing controlled Standard Operating Procedures. This page is written for IT and information security, and everything on it can be checked against the file itself – the last section says how. Applies to SOP Maker 0.68, the build currently published here.

Forwarding this to IT? The panel above is the whole answer; everything below it is the evidence.

Data-processing agreements and sub-processors

Most of a software review is about the supplier: where the data is processed, who the sub-processors are, what the data-processing agreement says, how an account is deprovisioned when somebody leaves. None of that applies here, because there is no service. What you are assessing is a file that runs on your own machines.

What the browser is being asked for

SOP Maker uses the File System Access API, the standard mechanism Chrome and Edge provide for a web page to work with local files. When the user clicks "Connect folder", Chrome shows its own folder picker and then its own permission prompt. The grant covers that one folder and its contents – not the drive, and not anything the user did not point at.

There is exactly one call to showDirectoryPicker() in the whole application, and a build check fails the release if a second one ever appears. That is not a policy statement – it is a test that runs on every build, so folder access cannot quietly spread through the code over time. Be precise about what that check covers, though: it guards that one function name, not the whole File System Access API. The complete list of prompts the application can raise is below.

Every File System Access prompt the application can raise

• The folder picker – showDirectoryPicker(), one call site. A persistent read-write grant on one folder the user chooses. This is the one the tool is built around.
• The save-file dialog – showSaveFilePicker(), one call site, reached only when somebody exports an SOP without having connected a folder. It is a one-shot, write-only grant on a single file the user names, it does not persist, and the location can be anywhere they choose. Where the browser does not support it, the tool falls back to an ordinary download instead. Worth knowing because a reviewer trying the tool without connecting a folder first will meet this prompt, and a page that had not mentioned it would look as though it were hiding something.
• A re-confirmation of the first grant, not a third one: when the tab is opened again, Chrome may ask whether access to that same folder can be restored. Chrome, not the page, decides.

There is no showOpenFilePicker(), and no other File System Access entry point in the file.

Separately from that API, the tool has three ordinary <input type="file"> controls – importing a document, and choosing a logo in two places. Clicking one opens the operating system's file chooser in the usual way. They are read-only, they grant nothing and they keep no handle, which is why they are not in the list above; they are mentioned so the list can be read as complete. There is no drag-and-drop file route: the file reads no dataTransfer.files.

Chrome and Edge apply their own restrictions on top: the picker refuses system directories, and the user has to confirm write access explicitly. SOP Maker stores the folder handle so it can offer to reconnect, but the browser, not the page, decides whether that reconnection is allowed.

What leaves the network

SOP Maker sends no document content anywhere. It makes three kinds of network request, all to sopmaker.uk, all for its own font and icon files. What that rests on:

• There are three fetch() call sites in the file. Two are literal relative paths – fonts/Jost-VF.ttf and icon-manifest.json. The third runs over each icon listed in that manifest, and every one of the 158 entries is a relative path under 07_Icons/. All of them resolve to the same origin the page was loaded from. (Three call sites, not three requests: the icon loop accounts for most of what you will see in the Network tab.)
• There is no sendBeacon, no WebSocket, no XMLHttpRequest, no EventSource and no RTCPeerConnection in the file. There is no <form> element anywhere in it, so there is nothing that can post.
• There is no service worker, so nothing runs in the background after the tab is closed.
• No eval(), no new Function, no document.write, no srcdoc, and no string-form setTimeout or setInterval. Zero of each.
• No external scripts, no CDN, no third-party stylesheets, no web fonts from anyone else, no tag manager, no tracking pixel. Subresource Integrity is therefore not applicable here, which is worth saying plainly rather than leaving it looking unchecked: there is no third-party subresource to pin.
• The one third-party library in the file is JSZip, used to build the ZIP export. It is bundled into the page rather than fetched, so it is covered by everything above – no request is made to a library host.

And above all of that sits the Content-Security-Policy, which is the browser's own rule about where a page is allowed to send data. It contains connect-src 'self'. Even if the code did try to reach another host, the browser would refuse the connection and log it to the console. That is the difference between a promise and a control.

One limit of that argument, since this page's standard is that every sentence survives a hostile read: a CSP cannot stop a page navigating the browser somewhere else and putting data in the URL. The navigate-to directive was dropped from the specification, so no policy closes that route. What closes it here is the code: there are no assignments to location.href, no calls to location.assign or location.replace, and the single window.open opens the literal string manual.html. Zero code-driven navigation, verifiable by search. The file contains twelve ordinary links a person can click; ten go to other pages of this site and two leave it – the author’s site and a mailto: – and none of them carries anything with it.

The response headers

Served on every path of sopmaker.uk:

The one-year HSTS max-age is deliberately without preload: preloading is difficult to reverse and this site does not need it. The full policy, line-wrapped here for reading but served as a single line:

Content-Security-Policy: default-src 'self'; img-src 'self' data: blob:;
  style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';
  font-src 'self' data:; connect-src 'self'; manifest-src 'self';
  worker-src 'none'; frame-src 'none'; frame-ancestors 'none';
  base-uri 'self'; object-src 'none'; form-action 'self'

Two notes on that policy. 'unsafe-inline' is present for scripts and styles because the application is deliberately a single file – its code and its stylesheet are inline, and a nonce cannot be attached to a file that is also meant to run from a shared drive with no server in front of it. The trade is deliberate: no external code is loaded at all, ever, and the directives that stop data leaving – connect-src, form-action, object-src – are not relaxed.

The icon directory is served under its own stricter policy – default-src 'none'; style-src 'unsafe-inline'; sandbox – so that an SVG navigated to directly cannot execute anything in the site's origin.

Where the data lives

In the folder the user chose, and in that browser's own storage. Nowhere else.

In the chosen folder

SOP Maker creates its own structure inside the folder it is given: the procedures themselves, reference lists for departments, sites and equipment, a settings file, an exports folder for finished HTML and PDFs, and one you should know about by name:

• 02_JSON/Library/_bak/ – before-image backups. Before a document is overwritten, the version being replaced is copied here first, so an overwrite can be undone by hand. The newest few per document are kept and older ones pruned.

Nothing about the formats is proprietary: an issued procedure is a self-contained HTML file that opens in any browser, the working records are JSON and the reference lists are CSV. If the tool disappeared tomorrow the documents would still open.

The save history, and the names in it

A folder called 07_Log/ holds the save history – one small JSON file per save event, never modified afterwards. Each entry records, and this is the whole of it: the timestamp; the name and role the person signed in with; the action and the save's own revision counter; the document's id, number, version, revision number, status and title; and the version of SOP Maker that wrote it. The title is the only part of the document in there – no procedure text, no step content, no images.

Nothing prunes it. Entries are added and never removed, so the history is kept for as long as you keep the folder, and clearing out old entries is yours to do because it is your folder. That is what makes it an audit trail rather than a log, but it is also the honest answer to the storage- limitation question, so here it is before you ask.

If the folder is on a shared drive, the people who can read the folder can read those names. The name is free text typed at sign-in, so a site that would rather not record individuals can sign in by role – "Line 3 supervisor" – and the history still does its job. That job is the point of it: it is what lets an auditor be shown who changed a controlled procedure and when, which is part of what makes the documents controlled rather than merely stored.

One thing that follows from the same sign-in and is easy to miss: the name is also written into each SOP's own record as its author, and it prints on the document. So it travels with any procedure your staff export and send to a customer, a contractor or an auditor – it does not stay inside the folder. If that matters to you, it is a further reason to sign in by role rather than by person.

In the browser

• An IndexedDB database called SOPMaker, holding the handle to the chosen folder so the tool can offer to reconnect, and one autosave draft per signed-in name so an unsaved document survives a crashed tab.
• Three localStorage keys: the signed-in name and role, the application's own settings, and a flag remembering that the user has seen the first-run message. Two further keys with a kpsop_ prefix are read if they already exist, to carry settings over from an older internal build; nothing writes them.

No cookies. No sessionStorage. Clearing site data for sopmaker.uk removes all of the above and touches none of the SOPs, because the SOPs are files in the folder, not browser storage. The formal version of all of this is in the privacy policy.

What the host can see

The site is served from Netlify, so loading it produces the ordinary web-server request log any hosting provider keeps – IP address, browser type, page requested. That log belongs to the host and contains no part of any document, because no part of any document is ever sent. Running the file from an internal share removes even that, since nothing is requested from the internet at all.

Running it from your own network

The application is a single HTML file. Copy it to a share, open it, and it works – no server, no install, no internet. On a site where the production floor has no external connection, that is the intended way to run it. The offline toolkit ZIP contains the file, the manual, the licence and a worked example.

The licence permits this explicitly. From §1, Use it across your organisation:

"You may copy SOP Maker onto as many of your own computers as you like, and host it on your own internal network, shared drive or intranet for your own staff and contractors to use."

What §2 prohibits is supplying the software to people outside your organisation, or selling it on. Documents your staff create are unaffected either way – those are yours, and you can distribute them without restriction. The full text is at licence.txt.

Three behaviours change when the file is opened directly from a drive rather than over HTTPS. None of them affects what the tool does with your data, but a reviewer testing an offline copy will meet all three:

• The icon files cannot be fetched from disk, so the tool falls back to the icon set embedded in the file itself. The user sees the same pictograms.
• Exported SOPs cannot embed the Jost typeface for the same reason, so a document exported from an offline copy prints in the fallback font stack rather than in Jost. Layout and pagination are unchanged; the lettering is not identical to a document exported from the hosted copy.
• The "Download the toolkit" button on the welcome screen does not work – there is nothing to download from. It says so, and the welcome screen carries a note pointing at the hosted site.

Requirements

Authoring needs desktop Google Chrome or Microsoft Edge, because the File System Access API is not implemented elsewhere. Firefox, Safari, phones and tablets can open and print an issued SOP but cannot create or save one. There are no accounts, no sign-up, no licence keys and no telemetry, so there is nothing to provision and nothing to renew.

What it does not do

Worth knowing before a decision. These are limits on what the tool does, not on where the data goes:

• No hosted accounts and no cloud sync. Two sites do not share a library unless they share a drive.
• No approval-routing workflow and no electronic signatures. What it does instead: the printed SOP carries ruled Prepared by and Authorised by lines with their dates, for signature on paper in the usual way, and every save is recorded in 07_Log/ with the name of the person who made it. What it does not do is verify that the person typing a name is that person.
• No training records and no read-and-sign tracking.
• No central administration and no group policy. The audit trail is the 07_Log/ history inside the folder, and there is nothing outside it.

Two people saving at once

Before writing, SOP Maker re-reads the file on disk and compares it with the version that was opened. If a colleague has saved in between, it stops and asks instead of replacing their work, and it copies the version it is about to replace into _bak/ first. That covers the ordinary case, and it is the case that actually happens.

The narrow case it does not cover is two people on two different computers pressing Save in the same instant – close enough together that each one's re-read finishes before the other's write lands. Neither check can see the other save in time, so the collision is not detected and not prevented. The later write wins. Be clear about what that costs: because both machines read the same version, both back up that same version, so in this one case _bak/ does not hold the overwritten work – it holds the version the two writers started from. What 07_Log/ gives you is the knowledge that it happened and who made both saves, not the lost text. No browser can lock a file on a network share, so this is a limit of the platform rather than something outstanding.

Within a single browser profile on one computer, saves are queued and cannot overlap, even with the tool open in several tabs. The queue is scoped to the browser profile, not to the machine – two Chrome profiles, or Chrome and Edge side by side, are two separate scopes and behave like two computers.

Checking any of this yourself

The application ships as readable source on purpose. The licence says so in §1, under Read the source: the whole program is there to be read so that anyone can verify the claim that nothing is uploaded. Some ways to do that in a few minutes:

1. Open the tool with DevTools on the Network tab. Create an SOP, add a photograph, save it. Every request you see will be for the tool's own font or icon files, and none of them will carry anything you typed.
2. Save the page and search it for fetch(, XMLHttpRequest, sendBeacon and WebSocket. The counts are three, zero, zero and zero.
3. Pull the response headers – curl -sI https://sopmaker.uk/app – and read the Content-Security-Policy for yourself.
4. Put the file on an isolated machine with no network and use it. It works, which is the most direct evidence available that it does not need to talk to anything.

If the answers matter to a decision, the two pages worth reading next are the privacy policy for the formal statement and the manual for how the tool is used in practice.

If something here is unclear, or you need a detail this page does not cover, email jakub@rimek.uk and ask. A question from an IT reviewer is worth more to this tool than a sale.