How an E-Reader Is Made: E-Paper, SoCs, Firmware and Ebook Formats

An e-reader is made by laminating a film of electrophoretic ink, charged pigment particles sealed in microcapsules or microcups, onto a thin film transistor backplane, then pairing that panel with a front light, a touch layer, a low power ARM system on chip, flash storage, Wi-Fi and a small battery. Firmware, usually embedded Linux or Android, drives the panel with timed voltage waveforms and renders EPUB books under the W3C reading system rules.

The screen is the reason the device exists, and it is also the reason the battery lasts so long: an e-paper image stays on the glass with the power removed, so the device only spends energy when a page changes. Everything else in the box, from the power management chip to the update channel and the DRM licence on a library loan, is designed around that one property.

This post goes one level deeper than our post on how OLED and LCD displays are made, and it pairs with our walkthroughs of lithium ion cells and packs and laptop materials, components and firmware. Makers do not publish line yields or update signing details, so where no official document gives a figure we describe the step without inventing one.

Key takeaways

• Electrophoretic ink moves oppositely charged black and white pigment particles through clear fluid inside microcapsules or microcups. It is bistable: the 1998 Nature paper from the MIT Media Lab describes "intrinsic bistability", and E Ink says it was spun out of the Media Lab in 1997.
• A panel stacks a TFT backplane, the ink frontplane laminate, an optional colour filter array, a touch sensor, an edge lit front light and a cover.
• Pixels are driven by waveforms: sequences of positive, negative and zero voltage frames chosen by update mode and by temperature. The Linux kernel driver for an early E Ink controller reads a waveform file that contains a temperature range table and checks its checksums before use.
• Inside sit a low power ARM SoC, RAM, eMMC, Wi-Fi, a lithium ion cell and a PMIC that makes the panel's high positive and negative rails.
• The software is mostly open source at the bottom. Kobo publishes the Linux kernel, U-Boot and Qt sources it uses; Amazon publishes a source code archive for Kindle devices under open source licence terms.
• EPUB 3.3 became a W3C Recommendation on 25 May 2023 and the current published version is dated 13 January 2026. EPUB Reading Systems 3.3 is dated 17 October 2024. EPUB 3.4 is a Candidate Recommendation Draft, last published 22 October 2026, and EPUBCheck 5.4.0 (15 September 2026) already validates against it.
• DRM on ebooks falls into a few categories. Readium LCP is the open, published one: AES 256 content encryption, a content key wrapped by a key derived from the reader's passphrase with SHA-256, and a licence signed with RSA and SHA-256.
• The W3C reading system spec says to treat sideloaded books as insecure, isolate scripts, skip external XML entities and get consent before collecting reading data.

From pigment and film to finished e-reader: the step table

The table names the check at each stage rather than a pass rate, because no maker we could find publishes one.

Steps 9, 11 and 14 are where software enters the device. Step 9 is unusual: part of the display's behaviour lives in a data file, not in the glass. We come back to that in the waveform section.

How does electrophoretic ink work?

Electrophoresis is the movement of charged particles through a fluid under an electric field. An electrophoretic display puts that effect behind a pixel electrode.

The two particle system

E Ink's technology page describes its two particle electronic ink as millions of tiny microcapsules, each about the diameter of a human hair. Each capsule holds white particles and black particles carrying opposite charges, suspended in a clear fluid. Apply a field one way and one colour rises to the top of the capsule, where the reader sees it. Reverse the field and the other colour rises. That spot on the screen now looks white or black.

One small inconsistency is worth knowing about if you read the source yourself. The same E Ink page describes the white particles as negatively charged in one paragraph and positively charged in its FAQ. What matters for the physics is that the two pigments carry opposite charges; which sign each carries is a design choice and can differ between ink generations.

Grey levels come from not finishing the move. If the field is applied for part of the time needed to bring black all the way up, the capsule shows a mix. The display controller manages this by applying a series of short voltage pulses rather than one long one, which is why the drive signal is called a waveform.

Microcapsules and microcups

Capsules are not the only way to hold the ink. E Ink describes its Spectra 3000 shelf label ink as a three particle system in a Microcup structure: cells embossed into a film, filled with the liquid and sealed. Cups and capsules solve the same problem, keeping particles from drifting sideways and pooling over time, with different manufacturing processes.

Bistability: why the picture stays without power

The original research paper, "An electrophoretic ink for all-printed reflective electronic displays" by Barrett Comiskey, Joseph Jacobson and colleagues at the MIT Media Laboratory, was published in Nature on 16 July 1998 (volume 394, pages 253 to 255). Its abstract describes microparticle displays as having "intrinsic bistability" and extremely low power d.c. field addressing, with high contrast, reflectivity and a near lambertian viewing characteristic. It also names the problem that had held such displays back: short lifetimes and difficulty in manufacture. Microencapsulating the dispersion solved the lifetime issue and allowed a display to be made by printing.

Bistable means a pixel has two stable states and holds either one with no power applied. Once the particles are in place, nothing pulls them back. An LCD has to keep refreshing and keep its backlight on to hold an image; an e-paper panel does not. E Ink's FAQ makes the practical point: because the screens are bistable, only the regions that are changing need updating.

Where E Ink came from

E Ink's company page says E Ink Corporation was spun out of the MIT Media Lab in 1997 to commercialise electronic ink and EPD technology. Prime View International, founded in 1992 as Taiwan's first TFT LCD company, acquired E Ink Corporation in 2009, and the combined companies were branded E Ink. That merger matters to how panels are made: it put the ink film and the transistor backplane under one roof.

Colour: filters versus multiple pigments

There are two routes to colour on e-paper.

• Colour filter array. E Ink describes a Kaleido module as a TFT backplane, an ink layer, a colour filter layer and a protective sheet. The ink underneath is still black and white; a printed colour filter above it tints the light. Kaleido offers 16 grey levels and 4,096 colours, according to E Ink. E Ink says the second generation Carta ink underneath is faster and brighter than earlier generations.
• Multi pigment ink. E Ink's Advanced Color ePaper (ACeP) platform, first shown in 2016 according to E Ink, puts coloured particles in every pixel and removes the need for a colour filter array. The Gallery and Prism product lines use it, and Spectra shelf label inks use three or four particle systems. Moving more particle types takes more complex waveforms and more time, which is why these inks are found in signage and shelf labels more than in fast page turning readers.

How is an e-paper panel built?

The frontplane laminate

E Ink describes its ink as laminated to a plastic film and then adhered to electronics to create an electronic paper display. That plastic film carries a transparent electrode on the viewing side. The capsules sit on it in a binder, and an adhesive layer on the back lets the whole sheet be laminated to a backplane. The industry calls this sheet the frontplane laminate. Making it is a coating process, closer to printing than to semiconductor fabrication, which is what the Nature paper meant by an "all-printed" display.

The TFT backplane

The backplane is an active matrix of thin film transistors, the same basic structure used under an LCD. Each pixel has a transistor that acts as a switch and a storage capacitor that holds the pixel voltage for the duration of a frame. Gate lines select a row at a time; source lines carry the voltage for each column. Our OLED and LCD post walks through TFT array fabrication in detail; e-paper backplanes use the same deposition, photolithography and etching steps.

Backplanes can be glass or plastic. E Ink's blog explains that Mobius was its first plastic based TFT offered in mass production, and lists the benefits: lighter, thinner products, larger screens a reader can still hold in one hand, and panels less likely to shatter when dropped.

The front light

E-paper is reflective. It uses whatever light is in the room, which is why E Ink says its displays remain readable in direct sunlight. In the dark you need light, and an e-reader adds it from the front rather than from behind. E Ink's blog describes front lights as built into the sides of the device, with a very thin material used to spread the light uniformly, angled down across the display surface so the reader sees reflected light rather than light shining into the eyes. In practice that thin material is a light guide plate: a clear sheet with tiny printed or moulded features that scatter light from edge mounted LEDs downward across the panel. Models with adjustable colour temperature mix warm and cool LEDs.

The touch layer

E Ink's blog lists four touch technologies paired with e-paper: resistive, inductive, capacitive and infrared. Capacitive touch is detected by a controller IC that senses the change in capacitance from a finger. Infrared touch uses beams across the surface that a finger interrupts. Inductive (electromagnetic resonance) digitisers sit behind the panel and are what writing tablets use for a stylus. E Ink also describes On-Cell Touch, built into the display stack for better optical performance.

Colour models add a printed colour filter array above the ink, every model adds a protective cover, and water resistant models add gaskets at final assembly.

What are waveforms and the display controller?

What a waveform is

A waveform is a lookup table. For each pixel transition, say from grey level 3 to grey level 12, it lists a sequence of drive voltages to apply frame by frame: positive, negative or zero. The controller reads the current and target value for each pixel, looks up the sequence and drives the source lines accordingly for the duration of the update.

The Linux kernel documentation for the Metronome display controller, an early E Ink controller, shows how this works in software. The driver "requires waveform information" that is loaded from user space through the kernel's firmware interface, typically as /lib/firmware/metronome.wbf. The driver source in drivers/video/fbdev/metronomefb.c parses a header from that file, uses a temperature range table to pick the waveform for the current temperature, and verifies several checksums (header, temperature range table, mode table and waveform data) before use. The documentation also warns that manipulating the waveform could possibly have permanent effects on the display media.

Two lessons follow. A waveform is a calibration artefact tied to an ink formulation, which is why step 9 pairs the file with the module. And the checksums in that driver detect corruption; they are not a cryptographic signature. Whether a modern device verifies the authenticity of its waveform data is something vendors do not generally document.

Update modes and ghosting

The E Ink FAQ says a module supports numerous update modes, and update times can be as short as 120 ms for the entire display. The controller trades speed against image quality:

• Full refresh. Every pixel is driven through a sequence that typically flashes through black and white before settling. This clears the residue of the previous image. It is slower and visibly flashes.
• Partial or fast modes. Only changing pixels are driven, often with fewer grey levels. These are used for page turns, menus, typing and pen input. They are faster but leave faint traces of the previous image.

Those traces are ghosting. Particles do not all return to exactly the same place every time, and charge can build up in the stack, so a short waveform that skips the clearing phase leaves a faint shadow. Reading software manages it by doing a full refresh every few pages, which many devices let you configure. E Ink's FAQ also says constant updates reduce power efficiency, and that current production modules do not support video rate updates.

Temperature compensation

Particle mobility depends on the viscosity of the fluid, and viscosity depends on temperature. In a cold room the particles move more slowly, so the same pulse produces a lighter grey. The waveform file therefore holds different sequences for different temperature bands, and the controller reads a temperature sensor before each update to pick the right band. The Metronome driver's temperature range table is a concrete public example. E Ink's description of Spectra 3100 as having an expanded temperature range for its red and yellow states shows the same constraint from the other side: some ink states are harder to drive at the edges of the range.

Discrete controllers versus SoC controllers

E Ink's blog describes two kinds of EPD controller. Discrete controllers are dedicated electronics with the display control hard wired into the design. SoC controllers are microprocessor based, and the EPD control functions are usually implemented in firmware developed by the IC supplier. Most current e-readers use the second kind: the application processor includes an electrophoretic display controller block, and the vendor's kernel driver feeds it frame buffers and waveforms.

The power rails the panel needs

E-paper needs voltages a phone battery does not supply. Texas Instruments' TPS65185 page, for a PMIC designed for E Ink Vizplex panels, lists a 3 V to 6 V input range and these outputs: two LDOs of 15 V and -15 V at 120 mA for the source drivers, two charge pumps of 22 V and -20 V at 15 mA for the gate drivers, and an adjustable VCOM driver, with power sequencing, I2C control and thermal shutdown. VCOM is the common electrode voltage; it is trimmed per panel at calibration because a small offset produces visible drift and ghosting over time. The PMIC brings the rails up in a set order before an update and turns them off afterwards, which is a large part of why an idle e-reader draws so little current.

What else goes inside an e-reader?

The system on chip

E-readers use low power ARM application processors with an integrated EPD controller, or a general purpose SoC with a separate controller. Rendering a reflowed page needs little CPU; what matters is deep sleep states, fast wake on a button press and a display pipeline that computes pixel transitions without the CPU.

Memory, storage and wireless

The SoC is paired with low power DRAM and an eMMC flash chip holding the boot loader, kernel, root file system, the user's library and often a recovery partition. Wi-Fi handles the store, library loans, sync and updates; many models add Bluetooth for audiobooks. Radios are among the largest power consumers, which is why devices switch Wi-Fi off when idle.

Battery, charger and fuel gauge

A single lithium ion or lithium polymer cell, a charger IC and a fuel gauge sit alongside the EPD PMIC described above. Our lithium ion battery post covers how the cell itself is made.

Why an e-reader lasts weeks on a charge

Battery life comes from the fact that almost nothing is running most of the time. When you read, the device wakes on a page turn, renders the next page, drives the panel for a fraction of a second, and goes back to a low power state. The panel holds the page with no power, the radios are off, and the front light, when on, is a few LEDs.

Here is an illustrative calculation. The numbers are invented for the arithmetic, not taken from any product.

• Suppose a device draws 300 mA for 0.5 seconds to render and refresh a page (CPU and PMIC busy), and 1 mA in between.
• A reader turns a page every 60 seconds. Each minute uses 300 mA times 0.5 s plus 1 mA times 59.5 s, which is 150 plus 59.5, about 210 mA seconds, or 3.5 mA on average.
• Half an hour of reading a day uses 3.5 mA times 0.5 h, about 1.75 mAh. The other 23.5 hours in deep sleep at an assumed 0.3 mA use about 7 mAh.
• That is roughly 9 mAh a day. A 1,500 mAh cell would last about 160 days on that model.

Real devices do much worse because of the front light, Wi-Fi sync, indexing, self discharge and regulator losses, which is why makers state battery claims with usage assumptions. The shape is what matters: the refresh is expensive, holding the page is free, and the radio and front light dominate the rest.

What firmware runs on e-readers?

Embedded Linux is the norm

Most dedicated e-readers run an embedded Linux system with a custom reading application on top. Two public examples show what is inside.

• Kobo publishes a GitHub repository, kobolabs/Kobo-Reader, containing "the open source packages and patches that are used on the Kobo Reader". Its layout lists the Linux kernel and U-Boot sources used on the family of Kobo Readers under hw/, the configuration script Kobo uses to build Qt for embedded devices, the source for the application stack, and a small daemon that passes wireless events to the reading app.
• Amazon publishes a Source Code Notice for Kindle e-readers and Fire tablets. It says that, in accordance with certain free and open source software licences, Amazon makes available an archive of machine readable source code for download.

Those disclosures exist because copyleft licences such as the GPL require them for the kernel and other components. They also tell you the general shape of the software bill of materials: boot loader (U-Boot), Linux kernel with the vendor's EPD and power drivers, a C library and BusyBox style userland, a GUI toolkit, a web engine or HTML renderer for EPUB content, image and font libraries, networking (Wi-Fi supplicant, TLS library, HTTP client), compression libraries for ZIP containers, XML parsers for the package document, and the vendor's own closed source reading application and DRM components.

Android based readers

Some e-readers and e-paper tablets run Android instead, bringing its app sandboxing, update and verified boot machinery, with e-paper aware refresh handling added to the display stack.

Open source reading software

KOReader, an AGPL 3.0 document viewer "primarily aimed at e-ink readers" that runs on several e-reader platforms, Android and Linux, is a public reference for how much e-paper work lives in the application: refresh scheduling, ghosting control and front light handling.

How updates are delivered

Amazon's Kindle software updates page says updates download and install automatically when the Kindle is connected wirelessly, and that you can also download an update file on a computer and install it manually. When we fetched it on 24 October 2026, the page listed version 5.20.1 as the latest for several current models, and noted that older devices on certain earlier versions must step through an intermediate update first.

What vendors rarely document is how the update package is authenticated: which key signs it, where the public key lives, whether rollback to older versions is blocked, and whether the boot chain verifies the kernel. Treat those as questions to ask, not facts to assume.

What the standards expect of an update

Consumer device security standards set the baseline even where vendors are quiet.

• ETSI EN 303 645 V3.1.3 (2024-09), the European consumer IoT baseline, says software components that are not immutable for security reasons should be securely updateable (provision 5.3-1), that the device shall have a secure update mechanism unless it lacks the resources (5.3-2), and that updates should be simple to apply and configurable to be automatic. It explains that a secure update mechanism can include authentic update servers, integrity protected channels and verifying the authenticity and integrity of software updates.
• NIST IR 8259A (May 2020), the IoT Device Cybersecurity Capability Core Baseline, lists software update as one of six core capabilities a device should provide, alongside device identification, device configuration, data protection, logical access to interfaces and cybersecurity state awareness.

An e-reader meets these through signed update packages, TLS to the update server and, ideally, a verified boot chain. If you are buying devices for a school or a library, ask the vendor how each is done and how long updates will be provided.

What are EPUB 3.3 and the reading system rules?

The format in one paragraph

An EPUB publication is a ZIP file with a defined structure. The EPUB 3.3 specification calls the container the Open Container Format (OCF). Its rules are strict: the mimetype file must be the first file in the ZIP, its contents must be exactly application/epub+zip, with no padding or line break, and it is stored uncompressed so software can identify the file by reading its first bytes. A META-INF/container.xml file points reading systems to the package document (the .opf file), which lists every resource, the reading order (the spine) and metadata. Content documents are XHTML or SVG, styled with CSS, with a navigation document for the table of contents.

Status and dates

Core media types and remote resources

EPUB 3.3 defines core media types that every reading system must support without fallbacks, such as XHTML, CSS, common image formats, fonts and some audio formats. EPUBCheck 5.4.0's release notes show the EPUB 3.4 work adding AVIF and JPEG XL images and Opus and AAC audio codecs in MP4 to that list.

The specification strongly encourages storing all resources inside the container. When a resource has to be remote, EPUB creators are recommended to reference it over https, and reading systems might refuse to load remote resources over plain http.

Font obfuscation is not DRM

EPUB 3.3 defines a font obfuscation algorithm keyed to the publication's unique identifier. It exists to stop casual extraction of embedded fonts whose licences forbid redistribution. It is not encryption of the book text and it is not a rights management system.

The reading system rules that matter for security

EPUB Reading Systems 3.3 sets what software must do with that content.

• Scripting is optional, but isolated when supported. Reading systems should support scripting in some contexts. If a reading system supports scripting, it must assign a unique origin shared by all spine level scripts of the publication, so one book's scripts cannot reach another book's storage.
• Treat new and sideloaded content as insecure. The security section says reading systems should treat content from any new source, including an integrated bookstore, as insecure, for example by asking the user before allowing scripting and network access. Each sideloaded book should be treated as insecure.
• Do not resolve external XML entities. When processing XML documents, reading systems should not resolve external identifiers in DOCTYPE, ENTITY and NOTATION declarations. That single rule closes a whole class of XML external entity problems in package and content documents.
• Know the threat model. The spec lists malicious scripts, content crafted to exploit flaws in the reading system or operating system, file indirection such as symbolic links, remote resources used to track readers, and external links. It also notes that EPUB has no standard signing method, so reading systems cannot always tell whether content was altered between authoring and loading.

How does DRM work on ebooks?

This section explains how ebook rights management works so readers and buyers can make informed choices. It does not cover, and we do not provide, any way to remove or bypass DRM.

The categories

Readium LCP in detail

LCP stands for Licensed Content Protection. The Readium specification site describes it as a DRM technology developed by the publishing industry for the publishing industry, vendor neutral and interoperable, created by Readium members and managed by EDRLab. Its building blocks are standard:

• AES 256 encryption for content and content keys.
• SHA-256 to hash user passphrases.
• RSA with SHA-256 to sign licences.

The flow, from the LCP 1.0 specification:

1. Publication resources inside the EPUB are encrypted with a content key. META-INF/encryption.xml, following the OCF spec, lists which resources are encrypted and points to the content key with a JSON pointer into the licence (license.lcpl#/encryption/content_key).
2. The licence document, META-INF/license.lcpl, holds the content key encrypted with the user key, plus rights such as the loan period and print or copy limits, information identifying the user, and links.
3. The user key is a hash of the user's passphrase. A key_check field, the licence id encrypted with the user key, lets the reading system confirm it has the right key before trying to decrypt anything.
4. The licence always carries a digital signature. A provider certificate in the licence identifies the content provider and validates that signature; a root certificate embedded in the reading system confirms the provider certificate is valid.

The companion License Status Document 1.0 supports library lending. A status document shows whether a licence is active, returned or expired and offers links to register a device, return a loan early or renew it. The spec says access to a status document must not require authentication and that it should not be served over an insecure connection.

The Readium site adds that LCP is designed for privacy and GDPR compliance because no third party collects user data, that browser based applications cannot integrate it because they cannot handle DRM details safely enough, and that its only mandatory cost is a yearly certification fee per server or client application.

What are the privacy implications of reading telemetry and sync?

An e-reader knows a lot: what you bought or borrowed, how far you read, how fast, where you stopped, what you highlighted and which words you looked up. Sync features send much of that to a server so your phone app opens to the same page.

The W3C EPUB Reading Systems spec is direct about it. Its threat model says collecting information about users and their reading habits without permission can violate their privacy even if the data is only for internal use, and that profiling users from reading habits or from metadata such as accessibility preferences can cause unintended harm. It recommends that reading systems say what they collect and seek consent, let users control and opt out of collection, treat stored personal data as sensitive and keep it from third parties, and anonymise what they collect.

Remote resources inside a book are a second channel. A book that loads an image from a server tells that server when, and from which network, it was opened. The spec advises reading systems to limit the information exposed in those requests and in link traversal.

For a reader who cares about this, the practical controls are: turn off sync features you do not use, keep Wi-Fi off while reading, prefer DRM free or LCP protected books where you have the choice, read the store's privacy policy on reading data, and use a reading system that blocks remote resources in sideloaded books by default.

E-paper versus LCD versus OLED

Only what primary sources support is in this table. Marketing claims about eye strain are common; we do not repeat claims that we could not tie to a primary source.

For a book, e-paper wins on power and outdoor reading. For video, scrolling and fast UI, emissive screens win. That is the whole design trade.

Step by step: check firmware, validate an EPUB and sideload a DRM free book

These steps are read only for the device apart from copying a book file. Nothing here modifies firmware.

1. Check the firmware version and update channel

On the device, open settings and find the device information screen, which shows the software version. Compare it with the vendor's published latest version. For Kindle devices, Amazon's software updates page lists the latest version per model (5.20.1 for several current models when we fetched it on 24 October 2026) and explains that updates install automatically over Wi-Fi.

If the device is behind:

1. Connect to a trusted Wi-Fi network and charge the device.
2. Use the built in update option in settings, or follow the vendor's manual update instructions.
3. Download manual update files only from the vendor's own support site, never from a mirror or forum.
4. Check the version again afterwards.

For a school or library fleet, keep an inventory of model, serial number, software version and last check date.

2. Inspect an EPUB's structure

Before validating, look at what is inside. On macOS or Linux:

# List the container contents; mimetype should be the first entry
unzip -l book.epub | head -n 10

# Print the mimetype file; it should be exactly application/epub+zip
unzip -p book.epub mimetype; echo

# Find the package document
unzip -p book.epub META-INF/container.xml

# Check whether the book is encrypted (LCP or other) or has obfuscated fonts
unzip -l book.epub | grep -E "META-INF/(encryption\.xml|license\.lcpl|rights\.xml)"

# Look for remote resources declared in the package document
unzip -p book.epub $(unzip -p book.epub META-INF/container.xml \
  | grep -o 'full-path="[^"]*"' | cut -d'"' -f2) | grep -i "remote-resources"

If encryption.xml is present, read it: it may list only fonts (obfuscation) or every content file (DRM). A license.lcpl file means the book is LCP protected and needs a certified reading system and the passphrase.

3. Validate it with EPUBCheck

EPUBCheck is the official conformance checker for EPUB publications, maintained by the DAISY Consortium on behalf of W3C. It runs as a command line tool or a Java library, and it is published on the GitHub releases page and in Maven Central as org.w3c:epubcheck.

# Download the release zip from https://github.com/w3c/epubcheck/releases
# (5.4.0 at the time of writing) and unzip it
unzip epubcheck-5.4.0.zip
cd epubcheck-5.4.0

# Show the options
java -jar epubcheck.jar --help

# Validate a book and write a JSON report
java -jar epubcheck.jar ~/Books/book.epub --json report.json

# Treat warnings as failures in a publishing pipeline
java -jar epubcheck.jar ~/Books/book.epub --failonwarnings

The EPUBCheck wiki documents the exit codes: by default the tool returns 1 if errors are found and 0 if not, and --failonwarnings also fails on warnings. It also documents --mode exp for an expanded (unzipped) EPUB folder and --profile options for dictionaries, indexes, previews and EDUPUB. The wiki's Java version notes date from older releases; use a current Java runtime.

To add EPUBCheck to a publishing pipeline in CI:

# .github/workflows/epubcheck.yml
name: epubcheck
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"
      - name: Fetch EPUBCheck
        run: |
          curl -sSL -o epubcheck.zip \
            https://github.com/w3c/epubcheck/releases/download/v5.4.0/epubcheck-5.4.0.zip
          unzip -q epubcheck.zip
      - name: Validate
        run: java -jar epubcheck-5.4.0/epubcheck.jar build/book.epub --failonwarnings

Pin the version and update it deliberately, the same way you pin any other build tool.

4. Sideload a DRM free book

Only sideload books you have the right to read in that form, such as DRM free purchases, public domain titles and your own documents.

1. Connect the e-reader to the computer with a USB cable. calibre's FAQ advises connecting a Kobo directly to the computer rather than through a USB hub.
2. Unlock the device if asked. Most readers appear as a USB drive (mass storage) or as an MTP device.
3. Confirm you are looking at the reader and not another drive before copying anything:

# macOS: list mounted volumes and confirm the reader's name
ls /Volumes
diskutil list external

# Linux: list removable block devices and their mount points
lsblk -o NAME,SIZE,RM,LABEL,MOUNTPOINT

4. Copy the book into the reader's documents or books folder (the folder name varies by device):

cp ~/Books/book.epub "/Volumes/<reader name>/"

5. Eject the device properly so the file system is not left dirty, then let the reader index the new book.
6. If the device does not support EPUB natively, use the vendor's own document sending service or a format the device lists as supported. calibre can convert formats and send books to a device, and its FAQ notes it cannot open books that carry DRM.

Common mistakes

• Leaving a reader on the version it shipped with. Devices that sit in a drawer between uses often miss updates. Connect to Wi-Fi and check the version after unboxing and every few months.
• Assuming a waveform checksum is a signature. Checksums detect corruption. If you build e-paper products, make sure display data, like the rest of the firmware, is covered by your signing and verified boot design.
• Treating EPUB as a document, not as web content. EPUB carries HTML, CSS, SVG and optionally scripts. If you run a reading platform, follow the W3C advice: isolate scripts, block external entities, ask before network access for new sources.
• Shipping EPUBs without validation. Malformed containers, a compressed mimetype file or missing manifest entries render differently across reading systems. Run EPUBCheck in the build.
• Ignoring reading data in a privacy review. For schools and libraries, reading history is sensitive. Ask vendors what is collected, where it is stored and how to opt out.
• Buying a fleet without an update policy. Ask how long software updates will be provided and how they are authenticated before you buy hundreds of devices.

FAQ

How does an e-ink screen work?

Tiny capsules or cups hold black and white pigment particles with opposite charges in a clear fluid. A voltage on each pixel pulls one colour to the surface. The image stays when power is removed because the particles stay where they were put.

Why do e-readers flash when turning pages?

The flash is a full refresh. The controller drives pixels through black and white to clear traces of the previous image, which is called ghosting. Fast modes skip the flash but leave faint residue, so readers do a full refresh every few pages.

Why does an e-reader battery last so long?

The screen uses power only when it changes. Between page turns the processor sleeps and the radios are usually off. The front light and Wi-Fi are the biggest drains, so turning them down or off extends battery life the most.

What operating system do e-readers use?

Most run embedded Linux with a custom reading app. Kobo publishes the Linux kernel, U-Boot and Qt sources it uses, and Amazon publishes a source code archive for Kindle devices. Some e-paper tablets run Android.

What is the difference between EPUB 3.3 and EPUB 3.4?

EPUB 3.3 is the current W3C Recommendation. EPUB 3.4 is a Candidate Recommendation Draft (22 October 2026) that adds items such as AVIF and JPEG XL images and Opus and AAC audio to the core media types, according to EPUBCheck's release notes.

How do I check if an EPUB file is valid?

Download EPUBCheck from its GitHub releases page and run java -jar epubcheck.jar book.epub. It reports errors and warnings and exits with 1 if errors are found. Add --json report.json for a machine readable report.

What is Readium LCP?

An open DRM specification for ebooks and audiobooks, managed by EDRLab. It encrypts content with AES 256, unlocks the content key with a key derived from the reader's passphrase, and signs licences with RSA and SHA-256. Libraries use its status document for loans, returns and renewals.

Do e-readers track what I read?

They can. Store connected readers sync reading position, highlights and purchases. The W3C reading system spec recommends asking for consent, letting users control and opt out of collection, and anonymising data. Check your device's privacy settings and the store's policy.

Where Safeguard fits, honestly

Safeguard does not analyse display hardware, scan firmware images, manage devices or generate hardware bills of materials, and it has nothing to say about pigments, waveforms or panel lamination. The honest overlap is the software around the reader. Publishing pipelines that build EPUBs, reading apps for phones and desktops, library lending servers and the web services behind an ebook store are code your team writes and ships with open source dependencies, from ZIP and XML libraries to HTML renderers. If those live in a repository or a container image, Safeguard can scan them (for example safeguard scan --dir . on a checkout, or safeguard scan --image followed by an image name), match components against vulnerability databases, rank findings with reachability analysis, and open fix pull requests when you switch autonomous remediation on. It does not replace the vendor's firmware updates for the device itself.

A reading app or EPUB build pipeline rebuilt from scratch pulls every dependency again, and e-reader firmware itself is assembled from hundreds of open source components such as the kernel, boot loader, GUI toolkit, XML parsers and compression libraries. The same supply chain hygiene that applies to your web services applies to the software that publishes, serves and renders books, which is where the section below comes in.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fits a JavaScript reading app, an EPUB build tool chain or the web front end of a library lending service.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits a publisher or library team that keeps its EPUB production scripts and lending server code in repositories it prefers to scan locally.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A team that asks an assistant about its reading app or publishing pipeline can keep that assistant limited to the read and scan tools it actually needs.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• E Ink, Electronic Ink: How it works
• E Ink, About
• E Ink blog, ePaper Module Components
• E Ink, Kaleido
• Comiskey, Albert, Yoshizawa and Jacobson, "An electrophoretic ink for all-printed reflective electronic displays", Nature 394, 253 to 255 (1998)
• Texas Instruments, TPS65185 PMIC for E Ink Vizplex displays
• Linux kernel documentation, Metronomefb
• Linux kernel source, drivers/video/fbdev/metronomefb.c
• W3C, EPUB 3.3
• W3C, EPUB Reading Systems 3.3
• W3C, EPUB 3.4 Candidate Recommendation Draft
• Readium, LCP Specifications overview
• Readium, Licensed Content Protection 1.0
• Readium, License Status Document 1.0
• W3C EPUBCheck, GitHub repository
• W3C EPUBCheck, v5.4.0 release
• W3C EPUBCheck wiki, Running
• Kobo, Kobo-Reader open source repository
• Amazon, Source Code Notice for Kindle E-Readers and Fire Tablets
• Amazon, Kindle E-Reader Software Updates
• KOReader, GitHub repository
• calibre user manual, FAQ
• ETSI EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
• NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020)

Last reviewed: 24 October 2026.