Russ Garrett

Online Safety Act Notes for Small Sites

Tue, 17 Dec 2024 00:00:00 +0000

The UK’s Online Safety Act (OSA) was passed into law in 2023 and is now being implemented, with the first parts of it going into effect in March 2025. The guidance provided is rather impenetrable, so I’ve decided to write my own summary here.

If you run a small site, you might be interested in joining Promising Trouble’s mailing list – they are trying to get some more solid guidance for small sites out of Ofcom. Neil Brown also has a website which is collecting resources on Online Safety Act compliance.

Disclaimer

I’m not a lawyer and this document is not legal advice, but I am quite familiar with UK law and I’ve spent many hours reading the guidance. I’m mostly writing this to condense my own thoughts, but I hope others find it useful, and suggestions are welcome.

If you’re running a service covered by the OSA, you’re going to need to carefully review the law and the guidance yourself (hopefully this’ll help), or you’ll need to get a lawyer.

About this document

This document is targeted towards operators of small “user-to-user” services, with up to 700,000 UK users, and which are not “likely to be accessed by children” (as covered below). Regulated services are sometimes referred to as “Part 3” services.

You might see references to “Category 1/2A/2B” services – these are the largest services which are subject to additional regulation. If you’re one of those, you’ll have the dubious honour of being contacted directly by Ofcom in summer 2025, but if you’re running a smaller service, you still have plenty of new rules to comply with.

OSA compliance is a risk assessment based process, so if you’re trying to find solid answers to some questions, you may find there aren’t any. As long as you’re able to justify your answer, you’re unlikely to face an immediate fine if the regulator ever disagrees with it.

I’ll try and keep this document up to date as the situation develops, but I can’t provide any guarantees.

Summary of the Online Safety Act

In a nutshell, the OSA requires services which handle user-generated content to:

Have baseline content moderation practices
Use those moderation practices to take down reported content that violates UK law
Stop kids from seeing porn

Contrary to some rumours, as a small site the OSA does not require you to proactively monitor or scan people’s posts – you only have to respond to reports when they are made.

The guidance does recommend scanning uploaded images and posted URLs for CSAM (child porn), but this recommendation currently only applies to sites with more than 700,000 UK users, or sites which are primarily for file-sharing. This is covered in more detail below.

Guidance

The act itself provides a broad framework, but most of the useful detail is in the statutory guidance, which Ofcom has initially published in December 2024. That’s the “Regulatory documents & guidance” section on this page – not all the other documents above it, which are just their expansive response to the consultation.

In January 2025, Ofcom released a second batch of guidance relating to age verification.

Ofcom’s Assessment Tool

Ofcom offers an assessment tool which attempts to guide you through the compliance process. It still requires you fill in a separate .docx template to record your risk assessment.

While this tool is generally quite comprehensive, as of late January 2025 I think the “children’s access assessment” portion is badly over-simplified – it asks “Do child users access some or all of the service?” with no additional guidance. This might tempt you to answer “no” when Ofcom’s full guidance (summarised below) suggests that the majority of sites should answer “yes”.

Definitions

I’m trying to keep this relatively jargon-free but there are a few terms which get used constantly:

Priority offence: Terrorism, CSAM, grooming, assisting suicide, threats to kill, harassment, stalking, bunch of public order offences. (There’s a lot. See schedules 5-7 for the full list)
Relevant offence: Either a priority offence, one of the communications offences defined in the OSA itself (encouraging self-harm, threatening communications, etc), or any other offence the government decides to add in future
Illegal content: Any content which amounts to a relevant offence
Priority content: Any content which amounts to a priority offence

(s59)

Scope

The Online Safety Act applies to every service which handles user-generated content and has “links to the UK”, with a few limited exceptions listed below.

The scope is extraterritorial (like the GDPR) so even sites entirely operated outside the UK are in scope if they are considered to have “links to the UK”.

A service has links to the UK if any of the following apply:

the service has a “significant number” of UK users
UK users form one of the target markets for the service
the service is accessible to UK users and “there are reasonable grounds to believe that there is a material risk of significant harm to individuals in the UK” (this seems less likely to apply for smaller services but who knows)

(s4(5)-4(6))

“Significant number” is not defined, either in the law or the guidance. Ofcom says:

Service providers should be able to explain their judgement, especially if they think they do not have a significant number of UK users. (Overview of Regulated Services 1.11-1.13)

Exemptions

There’s a short list of narrow exemptions, which are not covered by the OSA at all:

Internal business services, only accessible to employees (or volunteers/contractors)
Email services (it appears this includes mailing lists)
SMS/MMS/one-to-one voice services
“Limited functionality services”
- This is when users can only post comments on the provider’s published content, not on user-generated content
- This includes, e.g., product reviews
- It probably includes blog comments but it may not include them if users can reply to each other – this is unclear (Overview of Regulated Services 1.17)
Services which enable combinations of Email/SMS/limited functionality services
Services provided by public bodies
Services provided by persons providing education or childcare

(Schedule 1 part 1)

Hosted services

The OSA puts obligations on the service provider, so if you host a community on a platform such as Discord or WhatsApp, the OSA doesn’t directly affect you (although it’s likely you’ll soon see the indirect effects).

While larger platforms are subject to more regulation under the OSA than smaller sites, I think it’s clear that it provides a centralising force, particularly given the complexity of the regulations and the lack of straightforward guidance for smaller sites.

Duties

As a small user-to-user service, the OSA requires you to:

Assess the risk of illegal content (s9)
Take proportionate measures to mitigate the illegal content risks you identified (s10(2)(c))
Take proportionate measures to prevent people encountering priority content (s10(2)(a))
Take proportionate measures to mitigate the risk of people committing priority offences (s10(2)(b))
Allow users to easily report illegal content, and content which is harmful to children, and take it down (s20)
Allow users to complain about reports, takedowns, etc (s21)
“Have particular regard to the importance of protecting users’ right to freedom of expression” (s22(2))

You don’t have to worry too much about these duties directly – the risk assessment process guides you through what you need to do to comply with them.

If your service is “likely to be accessed by children”, there are additional requirements, including to perform a separate “children’s risk assessment”. If your service is likely to be accessed by children and permits pornographic content, you’re required to carry out “highly effective” age verification (s12).

Children’s access assessment

You must perform and record a “children’s access assessment” to confirm whether your service is likely to be accessed by children.

Your service (or part of it) is “likely to be accessed by children” if the following applies:

You don’t use age verification or age estimation to prevent children from accessing it, and,
There is a “significant number” of children who are users (based on the ratio of total UK users to UK child users), or it’s “likely to attract” a significant number of child users

(s35)

Of course “significant number” isn’t defined here either. Ofcom has a guidance page on these assessments. Notably it says:

Even a relatively small number of children could be significant in terms of the risk of harm. We suggest you should err on the side of caution in making your assessment.

In the announcement of their age assurance guidance, Ofcom says:

Unless they are already using highly effective age assurance and can evidence this, we anticipate that most of these [user-to-user and search] services will need to conclude that they are likely to be accessed by children within the meaning of the Act.

The children’s access assessment guidance is fairly readable (although not necessarily clear) and I won’t reproduce it all here.

If you conclude that your service is not likely to be accessed by children, you must perform a new children’s access assessment annually to confirm this is still the case.

Freedom of expression

It’s worth commenting briefly on the “freedom of expression” duty. Ofcom is clear that it’s intended to prevent the OSA itself from unduly interfering with users’ freedom of expression.

Sites are still free to put whatever additional restrictions they like in their TOS, and Ofcom has no power to restrict that, though it’s worth taking the opportunity to make sure that your TOS supports the moderation actions you’re taking.

Ofcom does not have a power under the Act to compel providers to carry content they do not wish to carry. In practice, this means that services may continue to operate with regard to Terms and Conditions which prohibit more content than is covered in this Guidance, though they will not be compliant if their Terms and Conditions capture less. However, we encourage providers to consider carefully the impacts of their choices on users’ opportunities to express themselves. (Illegal Content Judgements Guidance 1.4)

Fees

The Online Safety Act gives Ofcom the ability to levy fees on sites which fall within the OSA’s scope. The fee structure has not been confirmed yet, and it appears they won’t start charging fees until 2026.

There is a consultation being run about fees, and Ofcom is proposing that only companies with a worldwide revenue above £250m (and revenue from UK users above £10m) will be required to pay fees. So at least this isn’t a concern for small sites.

(Online Safety - fees and penalties consultation)

Enforcement

If you’re found not to be complying with the OSA, Ofcom will generally aim to engage with you and ask you to fix it first.

If you’re still in breach, they will open a formal investigation. The outcome of this may be a “provisional notice of contravention”, which will detail the steps you must take, or fine you up to a maximum of 10% of worldwide revenue or £18m, whichever is greater.

While investigating a site, Ofcom can issue you with an “information notice” to request further information. It’s a criminal offence (s109) if you fail to comply with this.

Ofcom can make related companies jointly liable for a fine. They can also make “controlling individuals” (owners of a company) personally liable, if they exercise dominant influence or control over the service. (schedule 15, Enforcement Guidance section 7)

If a service doesn’t comply with a confirmation decision, and Ofcom believes the risk of harm is sufficiently high, they can deploy “business disruption measures”, by ordering ISPs, service providers, or app stores to block the service.

If you fail to comply with a requirement in the confirmation decision, and the requirement relates to children’s online safety, you can be prosecuted (s138). Corporate officers can be made personally liable for these offences (s202).

(Enforcement Guidance)

Illegal content risk assessment

This is really the core part of the OSA. All services must carry out a “suitable and sufficient” illegal content risk assessment. This must be done:

Before 16 March 2025 for existing services
Before making any significant change to your service (see risk assessment guidance s4)
Within 3 months of launching a new service (or a service coming into the scope of the OSA)
Whenever Ofcom changes their guidance

You need to keep records of each assessment. (s9(1-4))

The risk assessment guidance, at a mere 84 pages, is actually one of the better and more concise documents, and you probably do need to read that one all the way through.

I’ll summarise a few points:

There are 17 categories of priority content which you must individually risk-assess. You also have to assess the risk of other illegal content.
Each category needs to be assigned a risk level of “low”, “medium”, or “high”
The risk assessment needs to take into account (s9(5)):
- the user base
- the risk of encountering illegal content, taking into account any recommendation algorithms or sharing features
- the risk of users committing or facilitating a priority offence, and possibly harming other users in the process
- the nature and severity of the harm which could be caused
- how the service’s design might affect the risks
You’ll need to refer to the “Risk Profiles” in section 1 of the guidance and list the aspects which apply to your service
This is then combined with “evidence” (data about your service) to produce the final risk score. This is the fuzzy bit, although section 3 has some rules about this

Measures

So now you’ve got a risk assessment, you can finally find out what you have to do. Smaller services (which again, are the only services we consider here), are split into three categories based on the results of your risk assessment. This will then determine the list of measures you need to take.

Technically these are only recommended measures, and you’re not required to implement them, but if you implement these measures, you are considered to be complying with the duties. You can use your own alternative measures as long as you ensure they protect users’ freedom of speech and privacy, as well as complying with the duties. (s49)

The measures are numbered (in the form “ICU A1”), and as a user-to-user service you only have to care about those starting ICU. Those measures are summarised in the “Summary of our decisions” document and described in detail in the Code of Practice for user-to-user services. I’ve only summarised them here, in a more readable format.

Measures are split up by risk category. Every risk category includes the previous ones:

Low-risk services

This is the minimum standard for all services regulated by the OSA. You’re a low-risk service only if you have assessed your risk as low for all 17 kinds of illegal harms.

I suspect this category might cover the smallest forums, as well as other sites which have some user-generated content.

Measure	Summary
ICU A2	Name an individual (accountable to the most senior governance body) to handle content safety, reporting and complaints.
ICU C1	Have a process to review content which the provider (not the user, that comes later) thinks may be illegal.
ICU C2	Have systems designed to swiftly take down illegal content, unless it is currently not technically feasible to achieve this outcome. ("Swiftly" is not defined. The law doesn't mandate timeframes for smaller sites.)
ICU D1	Have a system for users to make a complaint.
ICU D2	Users should be able to complain about a specific piece of content, or just complain in general. They must be able to provide supporting information with the complaint.
ICU D7	A user complaint about illegal content should be treated as per ICU C1.
ICU D9	If a complaint is an appeal, it should be determined promptly. (No guidance provided on the difference between "swiftly" and "promptly".)
ICU D10	If an appeal is approved, the content or user subject to that appeal should be reinstated. If there's a pattern of content being taken down in error, guidance should be adjusted or automated systems should be changed.
ICU D11	If the complaint is about "proactive technology" (scanning/fingerprinting) not behaving correctly, the complainant should be told what the provider is doing to rectify it, and their right to take legal action (?)
ICU D12	If the complaint is about compliance with the OSA, it should be passed to a nominated individual, and should be handled within an appropriate timeframe.
ICU D13	A complaint should only be disregarded if it is manifestly unfounded, in accordance with the TOS. These events should be reviewed to ensure the policy is appropriate.
ICU G1	The provider's TOS must include a number of specified provisions regarding illegal content, proactive technology, and complaints.
ICU G3	The terms from ICU G1 must be clearly signposted, accessible, and easily readable for the age range of the site.
ICU H1	The provider must remove public content and accounts from proscribed terrorist organisations.

Single-risk services

Single-risk services are services where only one harm is assessed as being “medium” or “high” risk.

In addition to the measures in the low-risk services category, single-risk services are recommended to:

Measure	Applies if	Summary
ICU C9	High risk of image-based CSAM & is a file-storage/file-sharing service (see below)	Use perceptual hashing to scan uploaded images for CSAM.
ICU D4		Acknowledge receipt of each complaint and provide an indicative timeframe for deciding the complaint
ICU D6		Enable the complainant to opt out of receiving any non-ephemeral (?) communications about a complaint.
ICU F1	High risk of grooming & existing means to determine the age/age range of the user	Hide child user accounts from recommended follows, disallow direct messaging to child accounts the user does not follow.
ICU F2		Prompt child user accounts with contextual info about safety features and risks.

(Note that there are several measures omitted from this table which only apply to services “likely to be accessed by children”.)

A note on CSAM scanning

If you have fewer than 700,000 UK users, you’re only recommended to scan image uploads for CSAM if both of the following conditions apply:

You have assessed a high risk of CSAM uploads (there is specific guidance on how to assess this risk in Table 13.1 of the risk assessment guidance), and,
You are a “a file-storage and file-sharing service” (“services whose primary functionalities involve enabling users to store digital content and share access to that content through links”)

There are suggestions that the threshold for CSAM scanning will be lowered in future. This kind of scanning is free to use, has a low impact on user privacy (for non-e2e-encrypted services, at least), and is relatively straightforward to implement with services like Microsoft PhotoDNA or Cloudflare. I think any site which accepts more than a trivial amount of image uploads should consider using something like this, even if it isn’t required by the OSA.

Multi-risk services

Multi-risk services are all other services, where more than one risk is “medium” or “high”.

Measure	Applies if	Summary
ICU A3		Have written statements of responsibilities regarding illegal harms for senior managers.
ICU A5		Track evidence of new kinds of illegal content, using data from complaints/moderation/law enforcement referrals/etc.
ICU A6		Have a code of conduct for employees around illegal harms.
ICU A7	Does not apply to volunteers	Employees working in design and management of the service must be trained in compliance to safety duties.
ICU C3		Written internal content policies.
ICU C4		Content moderation performance targets covering speed and accuracy.
ICU C5		Written policy for prioritising content for review.
ICU C6		Content moderation should be adequately resourced.
ICU C7	Does not apply to volunteers	Content moderators should receive adequate training and materials.
ICU C8		Content moderation volunteers should have access to adequate materials.
ICU D8		Appeal processing should be monitored for speed and accuracy and adequately resourced.
ICU E1	Recommender systems are tested publicly & high risk of two or more harms from a specific list	Safety metrics should be produced and analysed when conducting on-platform testing of recommender systems.

Decentralised services

In their consultation response, Ofcom makes clear that they don’t intend for the Online Safety Act to make decentralised services unlawful:

We recognise that a wide variety of service types will fall in scope of the Act, including services with a decentralised and community-moderated organisational model. However, we have intentionally designed each measure with flexibility in mind as we recognise the importance for providers to have some flexibility in how they will implement these measures. We encourage providers to consider the safety outcome expected and to implement the measures in a way that is appropriate and effective for their own service and organisational structure. (Volume 1: Governance and Risk Management 5.19)

Given that the duties only require services to take “proportionate measures”, the implication must be that decentralised services will be given more leeway.

Mastodon & the Fediverse

Fediverse services like Mastodon should be able to re-use a standardised risk assessment, which should simplify things. However, they will likely end up in the “multi-risk” category, and some of the recommended measures don’t apply neatly to this situation, which means you may not get the guarantee of compliance which those measures provide.

If your fediverse service is considered “likely to be accessed by children” (and it’s hard to see how open-signup instances wouldn’t), then it’s fairly clear you’ll be required to deploy age verification technology due to the presence of pornographic content on the fediverse (s12, children’s access assessment guidance).

IFTAS is working on guidance.

The most interesting question here is: if your Mastodon server doesn’t have “links to the UK”, but it federates with servers which do, are you subject to the OSA?

Glastonbury Festival 2015 Premises License

Mon, 13 Jun 2016 00:00:00 +0000

In March 2014, I submitted a Freedom of Information Act request to Mendip District Council for the Premises License and supporting documentation for Glastonbury Festival.

Today, two and a quarter years later, I received an inch-thick sheaf of paperwork in the post.

The Documents

These documents were released by Mendip District Council under the Freedom of Information Act 2000, with reference number FOI/2015/341.

Editor’s note: I had to scan in some 350 pages to put these online. A few pages appear to have been truncated - this is an artefact of the page trimming from my scanning software, and no content has been lost. The size of the PDFs could probably be improved but bandwidth is cheap.

Copyright note: Although these documents retain the copyright of their original author, anyone may request a copy from MDC, incurring them additional expense and hassle at a time where they’re clearly very stretched for resources.

Cover Letter (800kB, 1 page)
Premises License and Operating Schedule (34MB, 24 pages)
Alcohol Management Plan (10MB, 7 pages)
Campsite Management Plan (17MB, 13 pages)
Command, Control, Communications, and Coordination Plan (21MB, 16 pages)
Crime Prevention and Reduction Plan (30MB, 28 pages)
Crowd Dynamics Plan (9MB, 8 pages)
Fire Safety Plan (17MB, 16 pages)
Public Safety Managment Plan (64MB, 48 pages)
Sanitary Facilities Plan (15MB, 14 pages)
Security and Stewarding Operational Plan (41MB, 41 pages)
Ticket and Entry Policy (6MB, 6 pages)
Trader Information Management Plan (97MB, 84 pages)
Traffic Management Plan (28MB, 22 pages)
Venues Plan (16MB, 12 pages)
Villages Proposal (13MB, 10 pages)

In my request, I gave permission for MDC to omit (at their discretion) any documents which would be especially sensitive and difficult to redact. As far as I can tell from the required documents in the Operating Schedule, the documents they didn’t provide are:

Major Incident Plan
Medical and Welfare Plan
Noise Management Plan
Site Plan
Water Supply Plan
Schedule of Key Dates

Why?

As well as being a fan of Glastonbury and an attendee for over 10 years, I’m also a festival organiser myself (on a rather smaller scale), and interested in the big infrastructure needed to put these massive events together.

You don’t need to FOI request EMF’s event management plan; you can find it on GitHub.

PostgreSQL Monitoring Cheatsheet

Fri, 02 Oct 2015 00:00:00 +0000

This is an attempt to build a fairly comprehensive list of metrics you should be monitoring on a PostgreSQL 9.4 database server. If you’ve found any particular metrics useful which aren’t listed here, please let me know.

Many thanks to the Government PaaS team at GDS, who I’ve been working with, for giving me the chance to put this list together.

System Metrics

You should be recording a comprehensive set of system performance metrics for any database server, but these are the ones you really want to keep an eye on:

Free disk space

This seems obvious, but you want to keep 10% available disk space on the Postgres data partition, since disk space can fluctuate during vacuuming, especially with high write loads. Running out of disk space will (at best) be detrimental to your availability. Alert on it.

CPU Usage

Again, pretty self-explanatory; max out the CPU and you’re going to get slowdowns. High user CPU usage can indicate badly optimised queries, but if your queries are reasonably well-optimised, being CPU-bound is a pretty good situation for Postgres to be in.

High system CPU usage can be an indication of too much query parallelism (also check out the number of context switches).

I/O usage

CPU percentage of IOwait should be your first port of call if you’re seeing Postgres slowness – it indicates the amount of time the machine is waiting for the disk.

It’s worth keeping metrics for the various individual I/O stats (iops, merged I/O transactions, queue size, service time, average wait time, etc.) which will help you drill down on any I/O problems. If you’ve got separate partitions for WAL and data, break those down.

Postgres Metrics

Total number of connections

This will tell you how close you are to hitting your max_connections limit, and show up any clients which are leaking database connections.

SELECT count(*) FROM pg_stat_activity;

Number of connections by state

This query breaks down connections by state:

SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

The possible states of interest are:

`active`: Connections currently executing queries. A large number tends to indicate DB slowness.
`idle`: Idle connections, not in a transaction.
`idle in transaction`: Connections with an open transaction, not executing a query. Lots of these can indicate long-running transactions.
`idle in transaction (aborted)`: Connection is in a transaction, but an error has occurred and the transaction hasn't been rolled back.

Connections waiting for a lock

The number of connections blocked waiting for a lock can be an indicator of a slow transaction with an exclusive lock.

SELECT count(distinct pid) FROM pg_locks WHERE granted = false;

Maximum transaction age

Long-running transactions are bad because they prevent Postgres from vacuuming old data. This causes database bloat and, in extreme circumstances, shutdown due to transaction ID (xid) wraparound. Transactions should be kept as short as possible, ideally less than a minute.

Alert if this number gets greater than an hour or so.

SELECT max(now() - xact_start) FROM pg_stat_activity
                               WHERE state IN ('idle in transaction', 'active');

Checkpoint interval

Checkpointing too frequently is a bad thing for performance. Postgres will warn you in its logs about frequent checkpoints, or you can monitor the frequency in the pg_stat_bgwriter table (more info in this article by 2ndquadrant).

Query execution time

Ideally measure this at your application level, not at the Postgres level. Alternatively, log queries periodically by setting log_min_duration_statement = 0 and analyze them, or investigate the pg_stat_statements module (tools linked below).

Beware that a global average query execution time means very little – you should be breaking execution time down by query, and distribution often matters more than the average. Measure percentiles, especially when your web page loads depend on these queries.

Log Archiving

If you’re archiving logs, for example with WAL-E, you should at least:

Check that your WAL files are being archived (there should be a new one at least every checkpoint_timeout seconds).
Check your last base backup ran and succeeded.

Streaming Replication

Standby server status

Check this to tell you whether your standby is connected and replicating (run this query on the primary):

SELECT state FROM pg_stat_replication WHERE client_hostname = '<hostname>'

Standby server lag in bytes

This tells you how many bytes behind the primary the standby is (again, run on the primary):

SELECT pg_xlog_location_diff(sent_location, replay_location) AS byte_lag
       FROM pg_stat_replication WHERE client_hostname = '<hostname>'

There are queries which tell you the standby lag in seconds, but these tend to break on low-traffic databases when there are no writes being replicated.

More Performance Troubleshooting Tools

I have a collection of Postgres views which I’ve found useful when investigating performance issues.
pg_stat_statements is a module which collects detailed, normalised query statistics and exposes them as a database view for analysis.
pg-query-analyzer and pgbadger are two query log analysis tools. They’re good for doing one-off analysis, but you don’t want to be logging all queries continuously on a busy server.
pganalyze is a hosted performance monitoring service which makes use of pg_stat_statements. Their stats collector process is open source.
PgBouncer is a Postgres connection pool which can be helpful with some Postgres workloads. It provides some additional metrics which might be useful.

/dev/fort 8: Scotland

Wed, 08 Jan 2014 00:00:00 +0000

In October I had the privilege to attend another lovely /dev/fort. The concept of /dev/fort is to bring a group of web types together in a beautiful, remote location, spend a week building something, and (ideally) result in something usable at the end.

Generally a /dev/fort cohort is around ten people, but in this case logistics meant there were eighteen of us heading to the Isle of Eigg in the Inner Hebrides.

On the Saturday night, we started the long journey by piling onto the sleeper train to Glasgow. I never sleep well on sleeper trains.

At 6am the next morning, we arrived in Glasgow and blearily found our next train: the five-hour West Highland Line service to Mallaig.

The West Highland Line has been called one of the most scenic rail journeys in the world, and it doesn’t disappoint. It weaves its way out of Glasgow, around the lochs on the west coast of Scotland, before climbing its way up to the desolate and beautiful Rannoch Moor and stopping at Corrour: both the highest and most remote station in Great Britain. After winding its way down, it stops at Fort William in the shadow of Ben Nevis.

Past Fort William, the line passes below Neptune’s Staircase, the longest flight of canal locks in Britain (eight of them), before twisting past Loch Eil and through a terrifyingly picturesque part of Scotland before it arrives at its terminus, the remote fishing village of Mallaig.

At Mallaig, close to 24 hours into our journey (at this point I began to realise it would have been quicker and easier to fly to San Francisco), we stopped for a well-earned beer before boarding the CalMac ferry which serves the Small Isles.

Eigg is a unique place: after a protracted struggle in the 80s and 90s involving a succession of increasingly eccentric landlords, the island is now entirely owned by the community of around 80 permanent residents.

Eigg also has a community-owned power company (primarily hydroelectric) and a wireless ISP (shared with the neighbouring islands) – BT has disavowed Eigg as uneconomical to provide broadband to, but the WiFi available on the island is faster than ADSL in some places in London.

Eigg is a distinctive piece of geology, with a massive volcanic ridge known as An Sgùrr. The climb to the top takes several hours, and after an abortive attempt to climb it in the rain and mist, we finally succeeded several days later. The view was worth the wait.

The highlight of the trip for me (besides, of course, the excellent company and copious whisky) was when we were lucky enough to stumble outside late one evening to be greeted by a stunning aurora.

Somehow, we still managed to tear ourselves away from the amazing landscape for long enough to build some things.

My team made Earth Lens, a site for exploring astronaut photography of Earth. Other projects to come out of /dev/fort 8 included Reading Gym.

We had to get up early for the long journey back to London, but we were greeted with a spectacular sunrise over the Scottish mainland, followed by a beautiful day.

You’d be forgiven for thinking this isn’t the Hebrides in mid-October.

Special thanks to James and Norm for the opportunity to come along, and Lucy who made us very welcome on the Eigg.

You can see a lot more of my photos from Eigg on Flickr. (All my photos for this trip were taken using the exceptional Fuji X100s)

Driving Monitoring Displays in Linux

Mon, 15 Apr 2013 00:00:00 +0000

After a rather long hiatus, here’s a bit of a technical brain dump while I have all the details in my mind.

I like graphs, and I like having them displayed on dedicated screens. My preferred way of doing this is to use Chrome on Linux to display the monitoring web page (generated by the likes of naglite2/nagdash or cactiview/graphview):

Whenever I set one of these machines up, I always spend an inordinate amount of time looking up obscure incantations on the internet. So here’s the comprehensive guide to setting one of these machines up. (Where these things are distribution-specific, they’re Debian/Ubuntuisms.)

Starting X up

You don’t want to fiddle with these machines using VNC/RDP, so forget about window managers. Remove the desktop manager (apt-get remove [mdm|gdm|xdm|...]), and give your non-root user the rights to start an X server in /etc/X11/Xwrapper.config.

Now we can get X11 to run Chrome in the root window directly, by editing ~/.Xinitrc:

#!/bin/sh
exec google-chrome --no-default-browser-check --kiosk http://server/monitoring

We’re using --no-default-browser-check to suppress the initial welcome dialog, and --kiosk full-screens Chrome by default. Nonetheless, depending on your Chrome version, you might still need to feed it a pre-existing profile (in ~/.config/google-chrome) to stop it from popping things up which you need to click on.

To start X11, I use a short looping wrapper script, passing the -nocursor X option to stop the annoying cursor:

#!/bin/bash
while [ 1 ]; do
        xinit /home/screens/.Xinitrc -- -nocursor
        sleep 10
done

I run this backgrounded from a crontab @reboot task. If you need to reload Chrome for any reason, pkill chrome will force an X restart (and without a window manager that’s a pleasingly swift operation).

Dealing With Screen Blanking

You’ll probably find that the screen blanks after 15 minutes, which is pretty annoying. Disabling this completely when you have no window manager is fiddly, but the best way is to alter your xorg.conf like so:

 Section "ServerFlags"
     Option         "blank time" "0"
     Option         "standby time" "0"
     Option         "suspend time" "0"
     Option         "off time" "0"
 EndSection

That inhibits screen power saving completely, but we like the environment so we should probably switch it off when everyone’s gone home. You can do this using the xset command, through cron or similar:

 DISPLAY=:0 xset dpms force [off|on]

Multiple Displays

Perhaps you want to attach multiple displays to one machine. As you’d expect, X makes this appropriately difficult. The default state for Xorg these days is to create a single desktop spanning both displays, but when you want to maximize a window on each screen, and without the assistance of a window manager which supports some kind of scripting, this isn’t ideal.

What we want is a separate X screen on each physical display, which is (of course) called “Zaphod Mode”. In the xorg.conf:

  Section "Device"
    Option     "ZaphodHeads" "DVI-0"
    Identifier  "Card0"
    Driver      "radeon"
    BusID       "PCI:1:0:0"
    Screen      0
  EndSection
  Section "Device"
    Option     "ZaphodHeads" "VGA-0"
    Identifier  "Card1"
    Driver      "radeon"
    BusID       "PCI:1:0:0"
    Screen      1
  EndSection
  Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
  EndSection
  Section "Screen"
    Identifier "Screen1"
    Device     "Card1"
  EndSection
  Section "ServerLayout"
    Identifier "default"
    Screen     "Screen0" 0 0
    Screen     "Screen1" LeftOf "Screen0"
  EndSection

Once this ugly deed is done, instead of one X display called :0 you’ll have two, called :0.0 and :0.1. To take advantage of both, you’ll need to use two separate Chrome profiles (or it’ll try and be clever, and open a new window on the same display as the existing session). Copy ~/.config/google-chrome to ~/.config/google-chrome-2 and alter your .Xinitrc as follows:

#!/bin/sh
DISPLAY=:0.0 exec google-chrome --no-default-browser-check --kiosk http://server/screen1 &
DISPLAY=:0.1 exec google-chrome --no-default-browser-check --kiosk \
  --user-data-dir=/home/screens/.config/google-chrome-2 http://server/screen2

Conclusion

This should be a chef cookbook. I’m planning on putting one together for our next monitoring project (which involves the six Raspberry Pis currently on my desk…).

Health and Safety

Sat, 21 Jan 2012 00:00:00 +0000

Every time I get depressed about things being shut down because of “Health and Safety” and the compensation culture, I like to take time to read the judgment in Grimes vs Hawkins et al (2011) (pdf).

It’s a court case filed by an extremely unfortunate 18-year-old (Grimes) who ended up at a friend’s house late at night, misjudged a dive into the pool, shattered her spine, and ended up tetraplegic. Subsequently she sued the friend’s dad (Hawkins) and, rightfully, lost.

I’d encourage you to read it in full, because it’s probably one of the most reasonable, clearly-stated, sensible pieces of justice ever administered.

The pool was not unsafe for diving. I have no doubt that some mature adults faced with a group of young adults in high spirits, some of whom had had too much to drink, would send them all home rather than allow any of them into a swimming pool. But that is not to say that the duty owed to the claimant under the Occupier’s Liability Act 1957 required the defendant to put the pool out of bounds that night. The defendant was not required to adopt a paternalistic approach to his visitors, all of whom were adults, all of whom were making choices about their behaviour, exercising their free will.

Green Threads and Pipes in Python

Fri, 16 Dec 2011 00:00:00 +0000

I’ve been hacking on WAL-E, a nice little Postgres backup system from Heroku which uses gevent for concurrency. Much of my changes are related to UNIX pipelines, and I’ve run into a subtle issue which not only affects gevent but also Eventlet (which is our coroutine library of choice at Smarkets).

Here’s a trivial example — an Eventletized version of an example in the Python manual:

from eventlet.green.subprocess import Popen, PIPE

fp = file('./input.file', 'r') # Should be reasonably large
tf = file('./output.file', 'w')

p1 = Popen(['sort'], stdin=fp, stdout=PIPE)
p2 = Popen(['cat', '-'], stdin=p1.stdout, stdout=tf)
p1.stdout.close()

p1.wait()
p2.wait()

You’ll get the following error:

cat: -: Resource temporarily unavailable
sort: write failed: standard output: Broken pipe
sort: write error

The problem is that you’re not expected to actually pipe data between separate processes. Eventlet assumes that you’ll be using the p1.stdout file descriptor from within your Python process, and it helpfully marks it as non-blocking for you so methods like communicate won’t block. When you hand that file descriptor to cat, the flags are preserved, and cat isn’t happy when it tries to read from what it thinks is a blocking socket and gets -EAGAIN.

Gevent doesn’t have a patched version of the subprocess library, but the pattern of patching stdin and stdout of Popen is repeated in a lot of gevent-using code, including within WAL-E itself.

I’m not sure if there’s an easy fix for this; the code can’t know whether you’ll be using the pipe yourself or passing it onto another process. In any case I’d rather be explicit about changing the options.

Facebook's Scrobbler

Thu, 22 Sep 2011 00:00:00 +0000

We knew Facebook was going to announce a big music-related feature today, and the rumour was that it was going to basically be scrobbling. So a small army of Last.fmers and ex-Last.fmers convened our legendary keynote backchannel on IRC to watch it.

It almost crept up on me. This was a developer event, so Zuckerberg (as inexpert as he is at giving these talks) assembled their scrobbling feature in front of us. It’s a combination of their “frictionless” way of enabling apps to post updates, and the new “verb” system which adds a bit of semantic structure to them.

At Last.fm we always said that we’d love to see other types of action scrobble, but finding actions which fit the scrobbling concept was hard. The key part of scrobbling is the automation, it can’t be a manual thing.

Facebook have solved this - they’re now a generic platform for scrobbling anything. Add that to the fact that there are an increasingly large number of things which can automatically scrobble — books from my Kindle, films through Netflix — and I think Facebook may have solved it.

Of course Facebook can’t scrobble from desktop media players yet, but that feature will come. Last.fm could provide it, but then it would increasinlgly be just a commodity.

The music features Facebook has built are fairly lacklustre. But I don’t think that matters - they have practically a billion-user head start on Last.fm, and the convenience will soon outweigh the experience Last.fm has gained for talking to music-lovers.

It’s going to be an interesting few months.

Visiting the Red Sands Sea Fort

Sun, 21 Aug 2011 00:00:00 +0000

Yesterday morning, close to a year’s worth of planning and aborted attempts finally came to fruition. Twelve of us involved with London Hackspace took a train from Victoria to Whitstable, then boarded a boat for the 45-minute journey to the Red Sands sea fort.

With the weather not looking too promising, we managed to hop onto the fort before the wind picked up and it started raining. Half an hour later, though, the August weather finally cut us a break.

Red Sands is one of two remaining Maunsell sea forts built by the army in the Thames estuary, and during World War II it housed six anti-aircraft guns. (The other is Shivering Sands, but that’s likely to be demolished at some point because it poses more of a hazard to shipping.) After being abandoned in the 1950s they’ve been standing empty, give or take a few pirate radio stations, slowly rusting and falling into the North Sea.

Project Redsand is trying to change that by gradually restoring the forts to their former glory, but they’ve got their work cut out. They’re under-funded and it’s slow progress.

Inside, the forts are surreal and almost post-apocalyptic; crumbling into rust inside as well as out. All you can hear is the sea and the clanging of the bell in the nearby buoy which marks the edge of the shipping channel.

Only one of the seven towers which make up Red Sands is currently accessible by boat, although they’re working on running a bridge over to the central control tower. Despite the rust, this fort is livable-in — people stay here during the yearly temporary radio broadcasts.

More photos in my Flickr stream. Massive thanks to Tom Scott for organising and to Project Redsand for letting us on the fort.

Sentimentality

Thu, 21 Jul 2011 00:00:00 +0000

The last space shuttle has landed. It’s sad, but not because America has lost its only way of putting humans into orbit; not because there’s no replacement ready (there wasn’t one when Apollo ended either).

It’s sad because each shuttle wasn’t just a disposable machine like all its predecessors; it was a ship, and like earthbound ships each orbiter had a life — and a personality — which was contributed to by the thousands of people who flew them, worked with them, and followed their flights.

So yes, I’m sad to see the shuttle go. It was a gigantic, expensive, dangerous, fantastically complex white elephant — a product of a government design process gone pathologically wrong. But each shuttle had a life, and that’s what differentiated them from just another capsule.

Perhaps one day we’ll be ready to try building a reusable craft which works, which actually makes economic sense, but until that day I think we’ll remember the shuttle more fondly than we did Apollo.