Last week Microsoft confirmed, in response to reporting by TechCrunch and others, that it had handed BitLocker recovery keys for three laptops to the FBI following a valid court order. The underlying case was a fraud investigation in Guam. The laptops were encrypted with BitLocker — the full-disk encryption built into Windows, which many institutions and individuals rely on as their primary protection against unauthorised data access.

The mechanism is simple and was not widely known. When you set up a modern Windows device and sign in with a Microsoft account, BitLocker automatically uploads your recovery key to Microsoft’s cloud. No prominent notification. No opt-in. The key sits there, associated with your account, accessible to Microsoft. When a US court issues a lawful order, Microsoft complies. Redmond confirmed this is policy, not an exception.

Bruce Schneier’s response was characteristically direct: “The lesson here is that if you have access to keys, eventually law enforcement is going to come.” Jennifer Granick at the ACLU called remote key storage in this configuration “quite dangerous,” particularly given that the same mechanism is available to any government that can issue a Microsoft-compatible legal order — not only the US Department of Justice.

That last point is the one European institutions should be reading carefully.

Why This Is a European Problem

The CLOUD Act — the US Clarifying Lawful Overseas Use of Data Act, passed in 2018 — allows US law enforcement to compel US-based companies to produce data held on servers anywhere in the world. If your university stores its BitLocker recovery keys in a Microsoft account, and Microsoft is a US company, the geographic location of the servers those keys sit on does not limit a US court’s reach. The keys are in Virginia, legally, wherever the hardware is.

This is not speculation. It is the explicit structure of US digital law. The European Court of Justice has repeatedly ruled that certain US surveillance frameworks are incompatible with GDPR — the invalidation of Privacy Shield in Schrems II (2020) being the most prominent example. But court rulings about data transfer frameworks do not automatically change the operational reality for an institution whose laptops are running Windows with default settings.

European universities hold exactly the kinds of data that make this a real rather than a theoretical concern:

• Research data: medical studies, clinical trials, interviews with human subjects, social science datasets — all subject to strict ethical and legal protections
• Student records: academic performance, personal circumstances, disciplinary proceedings
• HR data: employment contracts, salary records, health information, union activity — particularly sensitive under German and EU labour law
• Correspondence and draft documents: research in progress, grant applications, peer review material

If the disk holding any of this is encrypted with BitLocker, and the recovery key has been uploaded to a Microsoft account by default, the encryption provides less protection than it appears to. The key is accessible to a foreign state with a court order. That state is not party to GDPR.

The Structural Problem

The BitLocker story is one instance of a larger pattern. It is not that Microsoft behaved unusually or maliciously — it complied with a lawful order in its home jurisdiction, as it is legally required to do. The problem is structural: when an institution depends on a closed-source, US-headquartered platform for its critical infrastructure, the institution has delegated control over its own data to an entity whose legal obligations lie elsewhere.

This applies beyond encryption. It applies to email (Exchange Online, Outlook), document storage (SharePoint, OneDrive), communication (Teams), identity management (Azure Active Directory), and any service that runs through a Microsoft account or Azure tenant. For each of these: the data is subject to Microsoft’s terms, and Microsoft is subject to US law.

The same argument applies, with different specifics, to Google Workspace and any other US-headquartered platform. The issue is not that these companies are bad actors. It is that their legal accountability and the legal accountability of European public institutions point in incompatible directions, and the institutions mostly have not noticed.

What Sovereign Software Looks Like

The alternative is not paranoia and air-gapped servers. It is a coherent strategy for institutional digital infrastructure that is based on software the institution controls.

In Germany, this conversation has a name and a project. OpenDesk — developed under the aegis of the federal and state governments — is a stack of open-source tools (Nextcloud, Collabora Online, Matrix/ Element, Jitsi, Keycloak, Open-Xchange) assembled into an integrated workspace alternative to Microsoft 365. The Souveräner Arbeitsplatz (sovereign workspace) concept behind it is exactly what the BitLocker story illustrates: if the software is open, the keys stay in your institution, and no foreign court can reach them via a warrant served on a US company.

Several German states and federal agencies have been piloting OpenDesk. The city of Munich’s earlier experiment with Linux (LiMux) and its eventual rollback to Windows is the cautionary tale here — not because open source failed, but because the transition was not supported seriously enough over time, and the incumbent vendor’s lobbying was. The BitLocker story is a reminder of what is at stake in that political negotiation.

The FSFE’s “Public Money? Public Code!” campaign has articulated the principle cleanly: software developed with public funding should be released as open-source software. The argument is not only about freedom as an abstract value. It is about the practical consequence of being locked into a proprietary platform: your institution loses the ability to audit what the software does, to modify it to meet your requirements, to host it where your data protection law applies, and to switch providers without losing access to your own data.

What I Do, and Why

I work at a publicly funded institution. The software I build for institutional contexts — campus infrastructure, workforce management, archival systems, alert systems — is public.

Not because I am ideologically committed to open source as a movement, but because the alternative is incoherent. If I build tooling for a university with public funds and keep it closed, I have produced a private asset with public money, duplicated by every institution that builds the same thing independently, inspectable by nobody, and ultimately dependent on my continued willingness to maintain it or hand it over. None of those outcomes serve the institutions I am building for.

Here is what that looks like in practice:

zammad-ticket-archiver — automated archival of Zammad support tickets as cryptographically signed PDFs, with RFC 3161 timestamps for non-repudiation. Built for institutions that need legally defensible audit trails of their helpdesk operations. The signing infrastructure is self-hosted; no external party holds the keys.

alarm-broker — a silent panic alarm broker for campus facilities. Receives emergency triggers from hardware devices (Yealink keys), distributes notifications via Zammad, SMS, and Signal, with acknowledgment tracking and escalation scheduling. Runs locally, logs to self-hosted PostgreSQL; no external dependency for the alarm path.

campus-app-kit — a React Native / Expo starter for university mobile applications, with a pluggable Node.js backend designed for institutional data sources (room booking, events, schedules). The architecture separates institution-specific connectors (which institutions keep private) from the shared foundation (which is public). Any university can take it and build on it without starting from scratch.

cueq — an integrated workforce management system for German universities under TV-L (the collective agreement for public sector employees in the German states). Handles time recording, shift planning, absence management, payroll export, and GDPR-compliant audit trails. Built around NestJS and Next.js, with a PostgreSQL backend and Honeywell terminal integration. The HR data stays on the institution’s own infrastructure.

These are all boring. They are not research contributions; they are plumbing. But plumbing is what holds institutions together, and the question of who controls the plumbing — and under whose legal jurisdiction — is exactly the question the BitLocker story makes visible.

The Principle

Public money, public code. If an institution funded by public money develops software for its own operations, that software should be released under an open licence, inspectable, forkable, and deployable by any institution with the same needs.

The corollary: institutions funded by public money should prefer software that is itself openly licensed, auditable, and deployable on infrastructure the institution controls. Not as a blanket ban on proprietary tools where they are genuinely the best option, but as a starting presumption that shifts the burden of justification.

The BitLocker story is not a story about Microsoft doing something wrong. It is a story about the logical consequence of a procurement decision that was made without asking “and what happens when a US court sends a subpoena?” That question was available in 2018 when the CLOUD Act passed, in 2020 when Schrems II was decided, and before both. It is still available now, for every institution that has not yet asked it.

The FSFE “Public Money? Public Code!” campaign is at publiccode.eu. The OpenDesk project is at opendesk.de. The original TechCrunch reporting on the BitLocker handover is at techcrunch.com.

The short answer is that YouTube does not work fine, for reasons that matter specifically to universities. The longer answer is what this post is about.

What Is Wrong with YouTube

YouTube is the world’s dominant video platform. It is free to use, globally available, handles any file size, transcodes automatically, and comes with an audience of two billion logged-in users. For individual creators who want reach, it is genuinely hard to beat.

For universities it fails in at least three important ways.

Data protection. When you upload a lecture or a concert recording to YouTube, the content, the metadata, and the viewing behaviour of your students go to Google’s servers — which are predominantly in the United States. Under the GDPR, transferring personal data to third countries requires either an adequacy decision, standard contractual clauses with additional safeguards, or explicit informed consent. After the Schrems II ruling (Court of Justice of the EU, 2020), the adequacy of US-based data transfers became legally contested in a way that makes institutional YouTube use genuinely difficult for European universities. Using it for anything with identifiable students — which includes most teaching content — is a compliance problem.

Platform logic. YouTube is designed to maximise watch time. Its recommendation algorithm is not neutral. It will recommend whatever comes after your lecture, and what comes after your lecture is not under your control. For educational content — especially sensitive material, or content that should remain in a defined pedagogical context — this is a real problem. The platform is not indifferent to what is hosted on it; it shapes how it is consumed.

Institutional fragility. YouTube is free until it isn’t. Platform terms change; monetisation policies change; content is demonetised or removed based on automated systems with imperfect appeal mechanisms. Building institutional infrastructure on a free commercial service is a bet that the commercial incentives of that service will remain aligned with your needs. That bet has a poor historical record.

None of this means that individual instructors should never use YouTube. It means that universities should not make YouTube their default institutional solution.

educast.nrw: A Cooperative Model

educast.nrw is a project of the Digitale Hochschule NRW — a cooperative of North Rhine-Westphalian universities building shared digital infrastructure. The concept is a state-wide video service, run by universities for universities, for the recording, processing, management, and distribution of video content in teaching and research. The platforms calls itself “Hochschul-YouTube”, which is both accurate and slightly underselling what makes it different.

The HfMT Köln participates as a user institution, which is where I come in as the IT contact for setting it up on our end.

The technical foundation is Opencast, an open-source video management system developed by a consortium of universities. This matters: the software is auditable, the development direction is set by the institutions that use it rather than by advertising revenue, and the infrastructure runs on German servers that are explicitly GDPR-compliant. Licenses on uploaded content are freely choosable — CC-BY-SA is an option, which means the university’s teaching materials can be open access if that is what the instructor wants.

What It Can Do

The feature set covers the actual use cases of a university, not the use cases of a content creator trying to build a following.

Recording. The Opencast Studio browser app records in three modes: screen only, camera only, or screen and camera simultaneously as a synchronised multi-stream. That last option — Presentation and Presenter as separate streams, played back with the viewer switching focus between them, or as picture-in-picture — is the format that works for a lecture. You get the slides and the speaker in the same video, but the viewer can choose which to focus on. That flexibility is not something you get from a simple screen recording uploaded to YouTube.

Multi-perspective video. For a music university this is the feature that changes things. A concert or a masterclass is not well-served by a single camera angle. The platform supports simultaneous recording from two camera perspectives — a wide shot and a detail shot, say, or a front view and a hands view for a piano performance. The viewer can switch between them in playback, or the institution can set a default presentation. This is infrastructure that makes the teaching use of concert recordings actually feasible, not just technically possible.

Formats. Video up to 4K with adaptive bitrate streaming (the player adjusts automatically to the viewer’s connection), audio up to broadcast quality (48kHz/16-bit, exceeding CD’s 44.1kHz), with FLAC at up to 96kHz/24-bit in development. No file size limit. These specifications matter for music. A piano recording compressed to whatever YouTube decides to do with it is not the same as an uncompromised audio stream. The difference is audible.

ILIAS integration. This is the practical hinge. Video that lives in a separate platform is video that students may or may not find. Video embedded directly in the ILIAS course page, in the learning module, at the point in the curriculum where it is relevant — that is video that is part of the course rather than adjacent to it. The integration between educast.nrw and ILIAS is direct: upload to the video platform, embed in ILIAS on pages, in learning modules, or as standalone video objects, all from within ILIAS.

Access rights. The granularity here is what distinguishes it from any public platform. Each video can be set to: public (anyone on the internet), institution-wide (anyone logged in at the university), course-wide (only enrolled students in a specific course), individual (specific named people), or private (only the uploader). A graduation concert might be public. A practice session for student feedback might be course-only. A recording made for an individual student’s reflection might be shared only with that student and their teacher. These are all normal use cases in a music university; they all require different settings; the platform handles all of them.

Use Cases in a Music University

The general university use case — lecture recording, video tutorial, self-study module — applies at HfMT as much as anywhere. But a music and dance university has some specific ones.

Concert recordings. HfMT Köln runs performances at both its Cologne and Wuppertal sites. Recording these and making them available to students, faculty, and selectively to the public used to mean someone had to manage files, find hosting, deal with YouTube’s automated copyright detection flagging student performances of copyrighted repertoire, and explain to students why their graduation concert had been muted by an algorithm. The controlled platform makes all of this manageable.

Stage presence as a reflective tool. Watching yourself perform is a standard part of performance training. It is uncomfortable, useful, and until recently required either dedicated recording equipment or the ad-hoc use of a phone propped against something. A proper recording infrastructure with controlled access — the student sees the video, their teacher sees the video, nobody else does — changes the pedagogical viability of this approach. The barrier to actually using video feedback in practice teaching drops substantially.

Theory and practice. This is the institutional argument I made in the presentation and stand by: video infrastructure that works for a lecture also works for a concert. The same system that stores the introduction to music theory also stores the masterclass by a visiting artist. This is not incidental — it is the point of a shared infrastructure. You do not need to choose a platform for academic content and a different one for performance content. The platform works for both.

The Argument Behind the Argument

There is a broader principle at work here that extends beyond video platforms. Public universities are funded by public money. The infrastructure they build with that money — software, platforms, data, content — should be under their control, governed by their values, and ideally available to other public institutions. The commercial platform model inverts this: you get free hosting in exchange for your data, your students’ attention, and your institutional dependence.

educast.nrw is an example of what the alternative looks like in practice: a cooperative of public institutions building shared infrastructure on open-source software, governed collectively, with data on European servers under European law. It is not perfect — the setup overhead is real, the user experience does not match YouTube’s, and the feature roadmap (automatic subtitling, H5P support, livestreaming, annotation tools) is still catching up to what commercial platforms have had for years. But the model is right.

The question of who owns the video infrastructure of a university is the same question as who owns its email, its learning management system, its student data. The answer should be: the university, operating under law, answerable to its students and to the public that funds it.

The slides from the Tag der Lehre 2022 presentation are available on request. For educast.nrw setup at HfMT Köln, contact the IT department.

Links

• educast.nrw
• Opencast
• Opencast Studio
• Tobira Videoportal
• opencast-ilias plugin (GitHub)

Changelog

• 2025-08-18: Corrected the capitalisation of “OpenCast” to “Opencast” throughout (matching the project’s official spelling on opencast.org).