Release note · August 1, 2026

A Word editable range can carry an editor identity

A Word document can be broadly read-only yet leave selected text, a table column, or another region editable. That exception can be intentionally useful in a review template or controlled form. It can also preserve a named person’s e-mail address, alias, or domain identity inside the OOXML package. A clean-looking document handoff therefore needs to ask two separate questions: does the package retain an editable-range exception, and does a report reveal the identity stored with it?

Microsoft’s protected-document guidance describes this workflow directly: a protected document can allow everyone or selected individuals to edit a chosen region, with e-mail addresses recommended when authentication is used. The Open XML SDK’s w:permStart contract gives the stored representation; its paired w:permEnd marker closes the range.

DocFence 0.14 makes that package state review-visible without printing editor identifiers, marker IDs, or exact editable content.

What the package can retain

A w:permStart marker stores the beginning of an editable range. Its w:ed attribute can hold an individual editor value; w:edGrp can hold a predefined application group such as everyone, editors, or owners. The corresponding w:permEnd shares the range ID. A start marker can also carry w:colFirst or w:colLast for a table-column selection.

These markers are useful only in the broader behavior of a Word client and its document-protection configuration. They are not a live identity directory, a proof that an editor is authenticated, or evidence that anyone can presently edit the file. Microsoft’s implementation notes also record that, when both individual and group attributes are stored, Word gives the individual attribute precedence.

Counts in reports; identities stay private

DocFence scans supported body, header, footer, footnote, endnote, comment, and glossary stories in Transitional or Strict OOXML. It validates recognized marker leaves, required IDs, standard attributes, known group values, column-selector syntax, custom-XML placement values, and unambiguous IDs within a story.

Profile JSON, Markdown, and SARIF expose only aggregate start/end, paired/unpaired, individual-editor, predefined-group, table-column-selector, and custom-XML-placement counts. They do not expose the w:ed value, a marker ID, an exact table column, a story path, or a fingerprint. The complete marker shape is privately fingerprinted, so a same-count identity rewrite still appears as a review-relevant inventory change without putting an identity in CI output.

An unmatched boundary is still counted as stored review state. It is not presented as an effective permission. This matters because a malformed or residual marker can still carry sensitive metadata even when Word does not honor it as an editable region.

Choose a clean handoff or freeze an approved baseline

For a handoff that must carry no stored editable-range permission markup:

rules:
  require_no_word_permission_ranges: true

This produces DFP041 whenever a recognized start or end marker is present, including an unmatched boundary. For a template that intentionally preserves known editable regions:

rules:
  no_word_permission_range_changes: true

DFP042 compares the private inventory against the approved baseline. It detects a changed editor value or marker shape even when the safe public counts did not change.

What this deliberately does not do

DocFence does not authenticate a person, resolve a group, calculate the exact editable text or cells, emulate client precedence, determine whether Word will honor a marker, or decide whether a document is secure. It does not turn a stored editable-range exception into an authorization claim. The inventory is a bounded package-review signal for CI and handoff workflows.

Release evidence

The 0.14 suite has 37 tests. It covers aggregate categories, same-count editor-identity changes, JSON/Markdown/SARIF redaction, policy findings, body/header discovery, Strict OOXML, unmatched boundaries, and malformed leaves, IDs, attributes, groups, columns, placement values, and duplicate boundaries. It passed Python 3.11 and 3.13 CI, Ruff, and compilation checks.

The wheel and source archive were independently rebuilt from the release commit and matched byte-for-byte. A clean installed wheel profiled a standard-shaped range-permission package with paired individual and group markers, plus independent Open XML SDK Strict and ordinary Word fixtures to confirm the zero-state path. The release artifact download was then verified against its SHA-256 manifest.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.14.0/docfence-0.14.0-py3-none-any.whl

docfence profile candidate.docx --format markdown
docfence check approved.docx candidate.docx --policy docfence.yml --format sarif --output docfence.sarif

The public release includes the wheel, source archive, and SHA-256 manifest. The exact scope and limits are in the policy reference and threat model. For the preceding protection boundary, read A Word restriction is not encryption.