Direct answer
A CSV file is text, but a spreadsheet may interpret some cell values as formulas when the user opens or imports it. RFC 4180 quoting protects the CSV field structure: commas, line breaks and double quotes are represented correctly. It does not declare that a cell is a literal string to every spreadsheet consumer. OWASP documents formula injection risks and notes that mitigation differs across consumers; it specifically warns that Excel can remove quoting or escape characters when a CSV is saved and reopened. Therefore, CSV correctness and spreadsheet execution safety are separate acceptance criteria. A local model, OCR stage or user-editable history can produce values beginning with formula-significant characters even without a malicious actor. OWASP highlights prefixes including equals, plus, minus, at sign and control characters; delimiters and quotes can also shift a dangerous substring into a new cell. Unicode full-width variants may matter in some locale environments. Treat every exported string as untrusted at this sink, including titles, names, summaries, identifiers and fields that the model has reformatted. A preview and user confirmation help them understand the file but do not make a spreadsheet interpret the cells as text. Do not silently mutate values merely to make a CSV appear safe. Prefixing an apostrophe or tab can change what downstream tools read; OWASP describes tab-based behavior observed for particular Excel usage while warning that it may differ elsewhere and that the tab remains in the data. Double-quoting and escaping embedded quotes are required for CSV structure but are not a universal defense against formulas. Never state that a single sanitizer, delimiter, extension change to .txt, or apostrophe prefix protects every spreadsheet, import workflow and later save/reopen cycle. Choose an export contract according to the user’s real destination. If a workbook is required, use a maintained writer that emits untrusted values as explicit string cells, then test the exact library and consumer versions. If CSV is mandatory, define the named application, version/build, operating system, locale/list separator, and whether the user opens the file directly or imports it through a wizard. For dangerous or untested values, the safe default can be to block that export, omit only after explicit review, or offer a non-spreadsheet data format; do not claim the fallback is safe if users later paste it into a spreadsheet. The export must also preserve provenance and user intent. Show which fields came from model output, source text, or user edits; let the user inspect literal values before exporting; and state if an output transformation changes a field. If the export path cannot preserve the exact value and avoid formula execution for its declared consumer, refuse or mark that mode unsupported rather than silently inserting characters. A locally generated file is an explicit data boundary even when inference stayed offline; audit the save/share destination separately and do not claim the file was uploaded or not uploaded without observing the actual path. Use harmless synthetic canaries only. A formula fixture such as =1+1 may be evaluated as 2; assert whether the named consumer keeps it as literal text or calculates it. Do not export real formula payloads or send test data to external tools. Include quotes, commas, separators, embedded CR/LF, leading spaces/control characters, formula-like prefixes and Unicode variants. Run each fixture through direct open, explicit import, save, close and reopen for the named spreadsheet version and locale. Then read the resulting cells back through a suitable test path and compare exact values, cell type or formula state, row/column boundaries, and any documented prefix transformation. Report only those combinations actually observed. ANDROID-PRIVACY-01 assigns data access and user control to the application, while PRIVACY-01 says on-device inference does not prove other app data paths are absent. These facts support careful export boundaries, not a CSV mitigation claim. This guide is a test method for spreadsheet-facing export, not a claim that Cove implements CSV export, that all spreadsheets behave alike, or that a pass in one consumer certifies another version.
A spreadsheet opens an exported translation as a formula
A user exports selected local history rows to CSV for review in a spreadsheet. One generated or copied field begins with a formula marker; normal CSV quoting keeps the row columns intact but may not stop the target application from interpreting the cell.
Decision
Treat row structure and cell interpretation as separate contracts, choose a tested consumer-specific typed-text path or refuse unsafe CSV values, and preserve the literal source for review.
Expected outcome
The user receives either an export proven for the declared consumer or a clear explanation that the requested spreadsheet mode is unsupported; no universal sanitization guarantee is implied.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Consumer version, locale and import path
- Harmless formula and quoting fixtures
- Exact values and formula state after save/reopen
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Declare the export’s actual consumer contract. Name whether the output is CSV or a workbook, the target spreadsheet and tested version, operating system, locale/list separator, and direct-open versus import flow. Keep CSV field grammar and spreadsheet cell interpretation as separate test questions.
- Inventory fields and preserve literal values. Trace source text, model output, and user edits into each exported column. Preview exact values and provenance; mark any transformation. Do not silently add an apostrophe, tab, quote, or other character that changes the data while presenting it as the original value.
- Build harmless formula and dialect fixtures. Use synthetic fixtures including a benign formula =1+1 that may evaluate to 2, plus/minus/at-sign prefixes, tabs, CR/LF, delimiter/quote breakout probes, leading spaces and full-width forms. Include commas, embedded quotes and newlines to validate RFC-style CSV structure independently of formula execution.
- Test the complete consumer lifecycle. For each declared consumer/build and locale, exercise direct open and the supported import wizard, inspect cells for literal text versus formulas, save, close and reopen, then compare exact values and row boundaries. A single initial preview is not evidence for save/reopen behavior.
- Select a tested safe mode or refuse. Prefer typed string cells in a workbook only when the chosen writer and target consumer are tested. If CSV is required, enable only the specifically tested path and disclose any data-changing prefix. Otherwise block or offer a separately reviewed non-spreadsheet export; do not call the fallback universally safe.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- CSV quoting is validated for commas, quotes and line breaks separately from whether the target spreadsheet evaluates a cell as a formula.
- The report names consumer version, locale and import path and includes save/reopen checks with harmless synthetic fixtures and exact value comparisons.
- No untested sanitizer, file extension, apostrophe or tab prefix is described as universal; any data mutation is visible and the default for unsupported cases is refusal or an explicitly chosen fallback.
- The preview identifies literal source/model/user-edited values and does not claim Cove currently implements CSV export or a tested spreadsheet defense.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| RFC 4180 CSV quoting | Quote fields containing delimiters, line breaks or double quotes and escape embedded quotes | Protects record/field parsing under the format rules; it does not make every spreadsheet treat the cell as text. |
| Typed string cells in a workbook | Write values with an explicit text cell type using a tested workbook writer | Can avoid CSV auto-detection for a declared consumer, but still requires library/version and import/open behavior tests. |
| Prefix-based CSV mitigation | Add a tab or apostrophe before a formula-like value | May alter data and consumer behavior; OWASP documents Excel-specific observations and warns about save/reopen and cross-consumer differences. |
| Refuse unsupported spreadsheet export | Block risky CSV values or offer a reviewed alternate format | Preserves an honest boundary when target behavior is untested; the alternate format still needs its own consumer and privacy checks. |
Failure patterns to prevent
- Treating CSV quoting as formula safety
- Claiming a universal sanitizer or extension fix
- Silently changing literal data
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- Android privacy and security
- OWASP — CSV Injection
- IETF — RFC 4180 CSV format
- Microsoft Support — Import or export text and CSV files
- Microsoft Support — Text Import Wizard
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Do double quotes around a CSV cell prevent formula execution?
No. RFC-style double quoting keeps delimiters and line breaks inside a field. A spreadsheet may still interpret the resulting cell value as a formula when the user opens or imports the file.
Can one apostrophe or tab prefix make every CSV safe?
No. OWASP documents consumer-specific behavior and warns that Excel may remove quoting or escapes after save and reopen. Prefixes can also change the underlying value, so test the exact consumer and disclose transformations.
Is changing the extension from CSV to TXT a security fix?
Not by itself. A different extension does not define how the receiving spreadsheet imports cell values. Test the actual import workflow or refuse a mode whose behavior is not established.
Should I test with real model output or live payloads?
No. A harmless test formula =1+1 may calculate to 2; compare literal-text and evaluated-cell behavior. Keep tests local and never export real formula payloads or send user content to external consumers.