WEB / WEB-16.S04

Archives and media processing isolation

Follow processing admission, bounded work, and admitted output as separate facts.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Approved archive

Processing input ready
The example supplies ZIP: 226 byte; catalog.txt=3, notes.txt=5. Archive and media use different application profiles; decompression, raster admission and consumer output have not occurred yet.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
No processing decision
Owned worker
No completed work
Result consumer
No result
Selected-admission decision
The 226-byte input, exactly two approved members and advertised total 8 bytes satisfy the 1024-input/16-expanded budgets. Admission is not actual stream reading or record publication.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Profile admitted
Owned worker
No completed work
Result consumer
No result
Bounded actual work
Two bounded stream reads completed: catalog.txt gave Tea with 3 bytes and notes.txt gave Bread with 5, totaling 8 bytes and two members. Memory records are prepared; no filesystem extraction runs.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Profile admitted
Owned worker
Members=2; bytes=8
Result consumer
No result
Completed output contract
Observed member lengths match advertised values; both titles satisfy strict UTF-8 and the domain contract. Two completed records are admitted; process separation is not a requirement of this archive flow.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Completed output admitted
Owned worker
Members=2; bytes=8
Result consumer
No result
Consumer projection ready
The projection is ready with record-1/title=Tea and record-2/title=Bread. These are application IDs; archive member names became no output paths. The consumer has not updated yet.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Completed output admitted
Owned worker
Two approved records
Result consumer
No result
Publish decision completed
The consumer received two admitted memory records, Tea and Bread. expandedBytes=8 and decompressedMembers=2 correlate with this completed result; they do not prove general archive isolation.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Completed output admitted
Owned worker
Two approved records
Result consumer
Public records=2

Expanded budget

Processing input ready
The example supplies ZIP: 226 byte; catalog.txt=3, notes.txt=5. Archive and media use different application profiles; decompression, raster admission and consumer output have not occurred yet.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
No processing decision
Owned worker
No completed work
Result consumer
No result
Selected-admission decision
Input has 226 bytes within the 1024-byte limit, but advertised members total 3+5=8 bytes, exceeding this branch’s 7-byte expanded budget. Admission is REJECT; small input is insufficient.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Rejected: expanded-budget
Owned worker
No completed work
Result consumer
No result
Decompression did not start
The advertised total of 8 bytes exceeds the selected 7-byte budget, so no member is decompressed; both work counters remain 0.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Rejected: expanded-budget
Owned worker
Members=0; bytes=0
Result consumer
No result
Output checking skipped
Admission rejection skips domain-record checking. No member was processed and no admitted output exists.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Rejected: expanded-budget
Owned worker
Members=0; bytes=0
Result consumer
No result
Consumer output withheld
Expanded-budget rejection retains output=null. Neither partial nor completed records are prepared for the consumer.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Rejected: expanded-budget
Owned worker
Output null; no publication
Result consumer
No result
Publish decision completed
The consumer shows expanded-budget rejection with output=null. decompressedMembers=0 and expandedBytes=0 remain; no Tea or Bread record was published.
Processing input
ZIP: 226 byte; catalog.txt=3, notes.txt=5
Profile gate
Rejected: expanded-budget
Owned worker
Output null; no publication
Result consumer
No result; expanded-budget

Complete raster

Processing input ready
The example supplies P6: 14 byte; dimensions=1×1. Archive and media use different application profiles; decompression, raster admission and consumer output have not occurred yet.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
No processing decision
Owned worker
No completed work
Result consumer
No result
Selected-admission decision
The P6 input is within 64 bytes and evaluated under the narrow selected format. A separate child process is not a full OS sandbox; dimensions and raster outcome are not yet consumer data.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
Profile admitted
Owned worker
No completed work
Result consumer
No result
Bounded actual work
The fixed media worker read the P6 header: dimensions=[1,1], Maxval=255. These dimensions require three RGB raster bytes. Parsing the header does not yet establish complete pixel output.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
Profile admitted
Owned worker
Parsed dimensions=1×1
Result consumer
No result
Completed output contract
The raster contains exactly three bytes and satisfies the selected profile; RGB [15,118,110] is admitted. This pixel list is not color calibration, browser rendering or another codec’s behavior.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
Completed output admitted
Owned worker
Parsed dimensions=1×1
Result consumer
No result
Consumer projection ready
The completed single RGB pixel [15,118,110] is ready for consumer projection. Worker output and consumer use are separate local stages; the view has not updated yet.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
Completed output admitted
Owned worker
One approved RGB pixel
Result consumer
No result
Publish decision completed
The consumer received admitted RGB [15,118,110]. This narrow P6 result does not establish other coder/delegate behavior or OS resource enforcement.
Processing input
P6: 14 byte; dimensions=1×1
Profile gate
Completed output admitted
Owned worker
One approved RGB pixel
Result consumer
RGB: 15,118,110

Incomplete raster

Processing input ready
The example supplies P6: 13 byte; dimensions=1×1. Archive and media use different application profiles; decompression, raster admission and consumer output have not occurred yet.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
No processing decision
Owned worker
No completed work
Result consumer
No result
Selected-admission decision
The P6 input is within 64 bytes and evaluated under the narrow selected format. A separate child process is not a full OS sandbox; dimensions and raster outcome are not yet consumer data.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
Profile admitted
Owned worker
No completed work
Result consumer
No result
Bounded actual work
The fixed media worker read the P6 header: dimensions=[1,1], Maxval=255. These dimensions require three RGB raster bytes. Parsing the header does not yet establish complete pixel output.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
Profile admitted
Owned worker
Parsed dimensions=1×1
Result consumer
No result
Completed output contract
The 13-byte input lacks all three required raster bytes. Although dimensions=[1,1] are known, raster-length is REJECT; missing pixels are not guessed and pixels=null remains.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
Rejected: raster-length
Owned worker
Parsed dimensions=1×1
Result consumer
No result
Incomplete raster withheld
Although dimensions are known, raster-length rejection retains pixels=null. No image result is prepared for the consumer.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
Rejected: raster-length
Owned worker
Output null; no publication
Result consumer
No result
Publish decision completed
The consumer shows raster-length rejection; pixels=null and dimensions=[1,1] remain. Header information is not displayed as a completed image or empty success.
Processing input
P6: 13 byte; dimensions=1×1
Profile gate
Rejected: raster-length
Owned worker
Output null; no publication
Result consumer
No result; raster-length

ACTORS · STATE · DATA FLOW

Upload admission is not processing permission

Storing an attachment does not establish that every parser or converter may process it. Atlas uses two selected profiles here: reading public catalog text records from its own tiny ZIP and reading its own minimal P6 image bytes in a narrow worker. Processing profiles, formats, budgets, and consumer outputs are application-owned decisions. A client filename chooses neither a decoder nor an archive extraction destination.

The ordinary archive contains catalog.txt:Tea and notes.txt:Bread. The ordinary media case has a 1×1 raster and three channel bytes. Both use own data. These selections do not establish malware scanning, full media-codec correctness, or general archive safety. The preceding upload/download boundaries meet processing admission, actual work, and publication decisions here; the consumer changes only after all selected checks complete.

Compressed bytes, expanded bytes, and entry counts have different budgets

The native ZIP has 226 bytes. Its member uncompressed lengths are 3 and 5, totaling 8. The selected profile requires at most 1024 input bytes, exactly two approved member names, DEFLATE, and an expanded budget of 16. Selecting budget=7 rejects advertised total 8 before decompression: decompressedMembers=0, expandedBytes=0, and null output. Small input size does not replace expanded-size policy.

A header’s file_size differs from an actual member read. The admitted branch reads each stream within remaining budget+1, compares actual and advertised sizes, and converts strict UTF-8 text to domain records. The normal case observes 8 actual bytes and two completed members. This tiny proof does not establish general decompressor memory/time bounds or every malformed-archive behavior. No bomb, traversal, or parser-vulnerability fixture is generated.

Member names do not become extraction destinations

The model uses neither extractall nor arbitrary directory extraction. Selected members are read from memory streams and mapped to application-owned record-1 / record-2 identifiers. catalog.txt and notes.txt are archive metadata, not assembled filesystem output paths. Ordinary draft.txt fails the selected manifest before any member decompresses. Storage naming/root containment in the preceding lesson remains a separate responsibility.

If a second ordinary text member fails UTF-8 admission, the earlier Tea record is not published as public output. The native check observes two actual reads while retaining null output. Temporary intermediate work differs from an admitted consumer result. Presenting partial archive output as completed import would hide the failure boundary. File extraction, symlink entries, permission restoration, and archive overwrite behavior do not execute in this model.

Media bytes, dimensions, and rasters are distinct facts

The native worker accepts only a minimal P6 profile: P6 newline, width height newline, 255 newline, and an RGB-channel raster. Normal input has 14 bytes; width=1,height=1 requires exactly 3 raster bytes. The returned channel values are 15, 118, 110, not a color-calibration or browser-render measurement. It is no full Netpbm decoder accepting comments, multiple images, different Maxval values, or other variants.

An ordinary incomplete raster has 13 bytes: the header/dimensions parse, but the expected raster length fails. The result records raster-length, dimensions=[1,1], and null pixels. Small width=3 fails the selected dimension budget. Pixel output is consumed only after the selected profile completes successfully. An extension or Content-Type label cannot replace these checks. This is no general PNG/JPEG/SVG/PDF converter.

Separate processes do not prove isolation

Media processing runs in an actual separate Python child. The native check observes a PID different from its parent, starts fixed worker code through an argument sequence without a shell, supplies a literal child environment, and chooses timeout=5. Python -I narrows interpreter import/environment behavior; it does not claim an OS sandbox or a network/filesystem privilege boundary.

A real media pipeline needs allowed coder/format, delegate/external-resource policy, memory/disk/time/image-count limits, worker privileges, and a publication gate together. ImageMagick’s primary security-policy documentation distinguishes these controls. No ImageMagick instance or policy.xml is changed here. A subprocess timeout or successful pixel decode alone would not support a passed claim for complete processing isolation.

The publish gate needs completed records

Archive output consists of two validated public records; media output is a completed pixel list. Worker startup, a read header, or an opened member is not published success. The scene consequently separates work snapshots from Result-consumer snapshots. Archive-budget rejection expands nothing, while incomplete media records parsed dimensions without delivering pixels.

Missing archive/media evidence remains NOT-COMPUTED. Actual checks compare input sizes, advertised/observed member sizes, fixed output records, child return codes, and raster invariants with independent expectations. Own fixtures live in memory, leaving neither extracted temporary files nor installed decoder configuration. Readers can distinguish what actually ran from what remains an architecture requirement, making the boundary useful for both review and regression.

Read every scenario without motion

Archive budget

Format acceptance conditions were separated
The archive input limit is 1024; its two advertised member sizes are 3 and 5 bytes. Compressed input size and total expanded size are separate limits.
Processing profile
ZIP input: 226 bytes
Format and budget decision
Decision pending
Consumer output
Output not prepared
The negative branch profile was selected
The archive-budget record declares rejection for expanded-budget. The normal profile having expandedBudget=16 does not turn this different budget decision into normal acceptance.
Processing profile
ZIP input: 226 bytes
Format and budget decision
Reason: expanded-budget
Consumer output
Output remains closed
Rejection occurred at the processing boundary
The expected decision is REJECT. This branch keeps decompressedMembers=0 and expandedBytes=0; denial does not hide a completed extraction.
Processing profile
ZIP input: 226 bytes
Format and budget decision
REJECT
Consumer output
Members=0; bytes=0
Intermediate information did not become consumer data
Knowing member names does not mean application records are ready. The budget gate did not open, so this branch produces neither Tea nor Bread output.
Processing profile
ZIP input: 226 bytes
Format and budget decision
Processing did not proceed
Consumer output
No consumer data
The output boundary remained closed
output=null remains. Member names or a small input are insufficient to publish application records under this profile.
Processing profile
ZIP input: 226 bytes
Format and budget decision
Rejection known
Consumer output
Output=null
The control scope remained precise
This decision shows a budget policy, not safety of every archive feature. The normal branch converts only two approved members into memory records without disk extraction.
Processing profile
ZIP input: 226 bytes
Format and budget decision
Bounded format policy
Consumer output
No published output

Raster incomplete

Format acceptance conditions were separated
The media profile allows dimensions up to 2 × 2 and 64 input bytes. A header declaring 1 × 1 does not yet establish that all three required raster bytes exist.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
Decision pending
Consumer output
Output not prepared
The negative branch profile was selected
The media-incomplete record has readable dimensions but an inconsistent raster length. Dimension information and a completed pixel array are different evidence.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
Reason: raster-length
Consumer output
Output remains closed
Rejection occurred at the processing boundary
The expected decision is REJECT. dimensions=[1,1] is known while pixels=null remains; an incomplete raster is neither successful decoding nor an empty image.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
REJECT
Consumer output
Pixels=null
Intermediate information did not become consumer data
Dimensions read from the header only inform format evaluation. No image is delivered because renderable pixel content has not been validated.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
Decode was not accepted
Consumer output
No consumer data
The output boundary remained closed
pixels=null is preserved. Running a separate worker cannot make an incomplete raster acceptable; the format decision must pass before the output contract.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
Rejection known
Consumer output
No image delivery
The control scope remained precise
This decision shows raster checking for a narrow P6 profile. It establishes neither other decoder safety nor operating-system isolation guarantees.
Processing profile
P6 dimensions: 1 × 1
Format and budget decision
Bounded format policy
Consumer output
No published output

ASSUMPTION · BOUNDARY · CONTROL

A review asks which authority interprets the bytes

A processing review does not finish with an upload extension. After admission, which decoder, resource budget, and output contract are selected? Deriving filesystem paths from archive metadata or external delegates from media names opens another interpretation boundary. This example uses fixed selected sources/paths and actual work only on own ordinary bytes.

The ZIP header listing, decompressed-byte count, and published records are different facts. Budget=7 rejects with 0 work; second-member content failure performs work without publishing output. Calling both merely import failed would conceal where failure occurred. Review evidence needs actual output and consumer gates, without target discovery or vulnerability reproduction here.

Naming a worker does not invent a trust boundary

Different child/parent PIDs prove process separation. They do not establish an independently enforced memory, disk, network, or kernel-privilege boundary. Python -I does not provide those controls either. Isolation review needs separate evidence for enforcement, admitted format/delegate sets, and publication. One working sample cannot be generalized across decoder families.

The incomplete P6 case knows dimensions but has no pixels. A consumer must not use it as a completed image. Evidence for other source-format variants is absent; calling NOT-COMPUTED or out-of-profile states successful would create false confidence. The observations cover ordinary 14/13-byte inputs and a tiny fixed ZIP, without malicious media, decompression bombs, or sandbox-bypass examples.

Read every scenario without motion

Member failure

The member-processing record was opened
The partialMemberFailure record reports decompressedMembers=2. That count describes processed members, not accepted domain outputs.
Processing observation
Members=2
Evidence comparison
Output not reviewed
Review conclusion
Conclusion pending
The failure reason was separated from output
reason=member-content identifies an incomplete content check. Intermediate data prepared for one member is not acceptance of the whole archive.
Processing observation
Reason: member-content
Evidence comparison
No acceptance evidence
Review conclusion
Conclusion pending
The publication boundary was checked
The record has output=null. Counting two processed members as two published records would lose this important negative boundary.
Processing observation
Members=2
Evidence comparison
Output=null
Review conclusion
Publication not established
The normal acceptance record was compared
The normal archive record contains Tea and Bread records with expandedBytes=8. The negative record lacks that array, so the normal result is not copied into it.
Processing observation
Normal: 8 bytes
Evidence comparison
Failure: output=null
Review conclusion
Branch outcomes separate
The failure conclusion was kept narrow
Processing began but consumer output was not formed. This differs from budget rejection with zero processed members; one counter cannot explain both causes.
Processing observation
Members processed
Evidence comparison
Content check failed
Review conclusion
No consumer output
The necessary observation fields were selected
Review needs decision, reason, processed-member count and output together. A processing count alone cannot establish publication or successful decoding.
Processing observation
Count alone is insufficient
Evidence comparison
Output field required
Review conclusion
No success inference

Worker boundary

The worker description was read
The media worker is a separate Python process. A separate PID describes ordinary process-memory separation, not a complete OS sandbox guarantee.
Processing observation
Separate process
Evidence comparison
Policy not reviewed
Review conclusion
No sandbox conclusion
The accepted format was narrowed
This worker handles only a narrow P6 profile. Three bytes [15,118,110] in the normal 1 × 1 raster do not show execution of other coders or delegates.
Processing observation
P6: 1 × 1
Evidence comparison
Raster: 3 bytes
Review conclusion
Other coders unknown
Format and isolation evidence were separated
An accepted pixels array supports the format result. Enforced memory, disk, network and kernel boundaries require separate policy and enforcement observations.
Processing observation
Pixels validated
Evidence comparison
OS boundaries not observed
Review conclusion
Isolation unknown
The Python isolation flag was bounded
Python isolated mode constrains the interpreter environment. Reading it as operating-system resource isolation would merge different layers.
Processing observation
Interpreter environment
Evidence comparison
Not OS sandbox evidence
Review conclusion
Claim bounded
Unknown resource conditions were recorded
Without evidence for timeout, cancellation, child cleanup and resource policy, those outcomes remain unknown. Normal pixel output cannot fill these missing conditions.
Processing observation
Format result known
Evidence comparison
Resource evidence missing
Review conclusion
UNKNOWN: OS enforcement
The review conclusion retained its proper scope
Narrow format acceptance and separate-process observation are retained together without claiming full isolation. Consumer pixel data and worker permissions are different questions.
Processing observation
P6 acceptance known
Evidence comparison
Process separate
Review conclusion
No full sandbox evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Separate admission, work, and publication gates

Measure archive entry counts, compressed input, advertised expanded size, and actual emitted bytes separately. Validate the selected manifest before bounded reads and domain admission. Use application-owned names for stored output; this example uses memory-record projection. Adding general extraction would require separate path, permissions, and cleanup design.

For media, selected formats and dimension/output contracts meet the converter’s resource/privilege policy. Broad tools such as ImageMagick distinguish coder, delegate, memory, disk, time, and image-sequence controls. Runtime upgrades may alter defaults, requiring fresh observations of installed enforcement. This actual worker does not claim those tests; it establishes a limited selected P6 behavior.

Keep incomplete output away from consumers

Process exit or a parsed header alone is not success. Archives require every admitted text record, while media require the exact expected raster. Native checks compare null-output branches with independent results. A second-member failure publishes no earlier prepared record; raster-length failure delivers no pixels even when dimensions are known. Model state preserves this failure boundary with motion disabled.

Record work admission, operation counters, and publish decisions as separate ledger fields. Cleanup for worker errors, cancellations, and timeouts, as well as retry policies, require separate design. A successful decode does not establish those controls. Explicit source, format, and kernel-enforcement boundaries show which checks a runtime change requires again.

NOW APPLY IT TO THE CASE

Do format, budget and worker boundaries prove the same result?

The approved catalog archive and narrow P6 profile have different controls. Review does not equate intermediate counters with consumer output or OS isolation.

Read accepted, delivery and committed-effect records at their respective owners. Do not rename unknown caller outcome as business rollback.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas selected processing responsibility ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profiles": {
    "archive": {
      "wireBytes": 226,
      "inputLimit": 1024,
      "members": [
        "catalog.txt",
        "notes.txt"
      ],
      "advertisedMemberBytes": [
        3,
        5
      ],
      "expandedBudget": 16,
      "output": "application-owned memory records; no extraction"
    },
    "media": {
      "format": "selected minimal P6",
      "rawBytes": 14,
      "maxInputBytes": 64,
      "maxDimensions": [
        2,
        2
      ],
      "normalDimensions": [
        1,
        1
      ],
      "rasterBytes": 3,
      "worker": "own fixed separate Python process; no OS sandbox claim"
    }
  },
  "expected": {
    "archive": {
      "decision": "ACCEPT",
      "reason": "approved-records",
      "decompressedMembers": 2,
      "expandedBytes": 8,
      "output": [
        {
          "id": "record-1",
          "title": "Tea"
        },
        {
          "id": "record-2",
          "title": "Bread"
        }
      ]
    },
    "archive-budget": {
      "decision": "REJECT",
      "reason": "expanded-budget",
      "decompressedMembers": 0,
      "expandedBytes": 0,
      "output": null
    },
    "media": {
      "decision": "ACCEPT",
      "reason": "selected-p6",
      "dimensions": [
        1,
        1
      ],
      "pixels": [
        [
          15,
          118,
          110
        ]
      ]
    },
    "media-incomplete": {
      "decision": "REJECT",
      "reason": "raster-length",
      "pixels": null,
      "dimensions": [
        1,
        1
      ]
    }
  },
  "missing": {
    "decision": "NOT-COMPUTED",
    "output": null
  },
  "partialMemberFailure": {
    "decompressedMembers": 2,
    "output": null,
    "reason": "member-content"
  }
}

profiles: Selected format, size, and consumer contracts; not general decoders.
decompressedMembers / expandedBytes: Actual completed bounded work, distinct from advertised headers.
dimensions / pixels: Parsed dimensions do not establish delivery of a valid raster.
output: Publication admits only completed approved records/pixels.

Own memory ZIP and a fixed separate minimal-P6 worker; no filesystem extraction. No full codec, libnetpbm/ImageMagick, OS sandbox/resource/network isolation, arbitrary payload, or production-intake verification.

Two reality checks

Small uploads and successful parsers establish all processing safety.

Expanded bytes, format/dimensions/work, and consumer gates need separate policies.

A separate process or Python -I is a complete security sandbox.

Process/import separation differs from OS privilege/resource/network enforcement.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

P6 dimensions are [1,1], but the raster-length condition fails. Is the pixel result accepted?

Yes. Valid width/height guarantees the entire decoder result.
No. media-incomplete yields REJECT with pixels=null.

Read the explained answer

No. media-incomplete yields REJECT with pixels=null. — Known dimensions do not make the raster complete. This profile does not guess missing pixels to produce success.

Two members were decompressed, but member-content failed and output=null. Does that prove earlier records were published?

Selected lesson artifact fields; teaching example

profiles.archive.output: application-owned memory records; no extraction
partialMemberFailure: {"decompressedMembers":2,"output":null,"reason":"member-content"}
expected.archive.output: [{"id":"record-1","title":"Tea"},{"id":"record-2","title":"Bread"}]

No. This failure result releases no output.
Yes. Every decompressed member immediately becomes a public file.

Read the explained answer

No. This failure result releases no output. — decompressedMembers=2 is not success. Output uses application-owned memory records; no disk extraction or partial publication is shown.

Which different sizes do the archive input limit and expanded budget constrain? Why does the media worker’s separate process not establish a full OS sandbox?

Read the explained answer

The archive input limit bounds compressed input bytes; its expanded budget bounds member totals after expansion. Member content is checked separately. In the media flow, a fixed P6 worker uses a separate process and checks dimensions/raster; the archive is not assumed to run in that child. A separate process alone does not prove filesystem/network/capability isolation or kernel boundaries. Each profile must satisfy its own admission and consumer-output rules.

□ I separated wire/input limits from expanded-output limits.

□ I did not treat a separate process as a full OS sandbox or universal decoder safety.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Python — zipfileZipFile.infolist / ZipFile.open / ZipInfo.file_size · Decompression pitfalls; resources and interruption
OWASP — File Upload Cheat SheetFile Content Validation; media processing limitations · Upload and Download Limits; expanded-size considerations
Netpbm — PPM Format SpecificationTHE FORMAT; width/height/Maxval/raster · Minimal Subset; one image
ImageMagick — Security PolicySelecting the Right Security Policy for Your Environment · Security Policy Discussion; delegate/format/resource controls
Python — subprocesssubprocess.run; timeout/check/env · Security Considerations
Python — Command line and environment-I; Python isolated mode is import/environment behavior

YOUR NOTES / THIS BROWSER

Archives and media processing isolation

1. Core · Mechanism

Approved archive

Expanded budget

Complete raster

Incomplete raster

Upload admission is not processing permission

Compressed bytes, expanded bytes, and entry counts have different budgets

Member names do not become extraction destinations

Media bytes, dimensions, and rasters are distinct facts

Separate processes do not prove isolation

The publish gate needs completed records

2. Red · Trust & Impact

Archive budget

Raster incomplete

A review asks which authority interprets the bytes

Naming a worker does not invent a trust boundary

3. Blue · Secure development & defense

Member failure

Worker boundary

Separate admission, work, and publication gates

Keep incomplete output away from consumers

Do format, budget and worker boundaries prove the same result?

Two reality checks

P6 dimensions are [1,1], but the raster-length condition fails. Is the pixel result accepted?

Two members were decompressed, but member-content failed and output=null. Does that prove earlier records were published?

Which different sizes do the archive input limit and expanded budget constrain? Why does the media worker’s separate process not establish a full OS sandbox?

Sources and scope