本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Be Aware of What’s in Your Logs

Be Aware of What’s in Your Logs Published on October 24, 2026

注意日志中的内容（发布于 2026 年 10 月 24 日）

There is something I wish more people understood about bug reports, diagnostic information, and the apparently innocent act of attaching a log file to a support request, and it is this: your logs may contain things you really, really do not want anyone else reading. I’m writing this because of a bug report I received recently, which came with a log file containing information I did not need to see, did not ask to see, and would have been perfectly happy going the rest of my life without ever seeing.

我希望更多人能了解关于错误报告、诊断信息以及在支持请求中附加日志文件这一看似无害的行为，那就是：你的日志可能包含你非常、非常不希望被他人读取的内容。我写这篇文章是因为最近收到的一份错误报告，其中附带的日志文件包含了我不需要看到、未曾要求查看，且即便终生不见也完全没关系的信息。

I’m not going to identify the person who sent it, describe what was in it, or otherwise turn a perfectly understandable mistake into a public spectacle, because doing that to someone who was trying to help me fix my own software would be a spectacularly shitty thing to do. But the incident highlights something worth talking about, because I suspect an awful lot of people have absolutely no idea what they’re handing over when they tick that little box labelled “Send logs,” and the software they’re using is rarely in any hurry to tell them.

我不会指名道姓，也不会描述其中的内容，更不会将一个完全可以理解的错误变成公开的闹剧，因为对于一个试图帮助我修复软件的人这样做，是非常糟糕的行为。但这件事凸显了一个值得讨论的问题，因为我怀疑很多人在勾选那个标有“发送日志”的小方框时，根本不知道自己交出了什么，而他们使用的软件也鲜少会主动告知。

A Log File Is Not Necessarily Just a Log File

日志文件不一定仅仅是日志文件

When most people think of logs, they imagine a wall of boring technical gibberish: timestamps, error messages, stack traces, the occasional complaint about a missing file or something failing to initialise. Logs do contain those things. They can also contain an astonishing amount of information about what you were actually doing when the problem occurred, and depending on the application, its logging configuration, and the nature of the problem, that might include: Text displayed on your screen. Messages you sent or received. Usernames, email addresses, and account identifiers. File paths containing your real name or other identifying details. URLs, including query parameters and authentication tokens. The names of documents you had open. Clipboard contents. Information about other applications and services. Internal application state that was never meant for public consumption.

当大多数人想到日志时，他们会想象出一堆枯燥的技术乱码：时间戳、错误消息、堆栈跟踪，以及偶尔关于文件丢失或初始化失败的抱怨。日志确实包含这些内容。但它们也可能包含大量关于问题发生时你实际操作的惊人信息。根据应用程序、日志配置和问题性质的不同，这些信息可能包括：屏幕上显示的文本；你发送或接收的消息；用户名、电子邮件地址和账户标识符；包含你真实姓名或其他识别信息的路径；URL（包括查询参数和身份验证令牌）；你打开的文档名称；剪贴板内容；关于其他应用程序和服务的信息；以及从未打算公开的应用程序内部状态。

Some applications log very little. Others log absolutely fucking everything, particularly once debugging is switched on, and you generally cannot tell which kind you’re dealing with from the size of the file or the name of the feature. A file called debug.log sounds harmless enough, and that tells you precisely nothing about whether it is. A log is a record of whatever an application considered relevant at a particular moment, and what an application considers relevant and what you consider private are two entirely different things. The computer has no idea that the conversation you were having was personal, that the document you had open was confidential, or that the text on your screen was something you’d rather not share with a stranger on the internet. It knows that something happened and that somebody told it to write that something down, so it did.

有些应用程序记录的内容很少。而另一些则会记录所有东西，尤其是在开启调试模式后。你通常无法通过文件大小或功能名称来判断你面对的是哪一种。名为 debug.log 的文件听起来无害，但这并不能说明它是否真的无害。日志是应用程序在特定时刻认为相关内容的记录，而应用程序认为的相关内容与你认为的隐私完全是两码事。计算机不知道你进行的对话是私人的，不知道你打开的文档是机密的，也不知道屏幕上的文本是你不想与互联网上的陌生人分享的。它只知道发生了某事，且有人让它记录下来，于是它就照做了。

“Logs Can Contain Text Displayed on Screen”

“日志可能包含屏幕上显示的文本”

I work on a screen reader, and like all software it occasionally misbehaves, which means I depend on people telling me when it does. The problem report form includes an option to send logs. That option is off by default, and when you get to it, the form warns you that logs can contain text displayed on screen. That warning is not decoration, and it’s not there to cover my arse; it’s there because I want people to understand what they might be about to send me.

我从事屏幕阅读器开发工作，像所有软件一样，它偶尔也会出错，这意味着我依赖用户在出错时告知我。问题报告表单包含一个发送日志的选项。该选项默认关闭，当你使用它时，表单会警告你日志可能包含屏幕上显示的文本。这个警告不是装饰，也不是为了推卸责任；而是因为我希望人们明白他们可能即将发送给我的内容。

A screen reader is in a particularly awkward position when it comes to privacy, because its entire job is to take whatever other applications put in front of you and make it accessible, which means it can encounter practically anything: your email, your private messages, your bank account, your medical records, your work documents, whatever happens to be on the screen at the time. When something goes wrong, diagnostic logging may well capture some of that, not because I’m secretly interested in what you get up to on your phone, but because the text a screen reader encountered is often directly relevant to why it behaved incorrectly. If it read something it shouldn’t have, skipped something it should have read, or mangled a particular control, knowing what it was looking at can be the difference between fixing the bug and staring blankly at a stack trace.

在隐私方面，屏幕阅读器处于一个特别尴尬的位置，因为它的全部工作就是获取其他应用程序呈现给你的任何内容并使其可访问，这意味着它几乎可以接触到任何东西：你的电子邮件、私人消息、银行账户、医疗记录、工作文档，以及当时屏幕上显示的任何内容。当出现问题时，诊断日志很可能会捕获其中的一部分，这并不是因为我私下对你在手机上的活动感兴趣，而是因为屏幕阅读器遇到的文本往往与它行为异常的原因直接相关。如果它读取了不该读取的内容、跳过了该读取的内容，或者损坏了某个特定控件，那么了解它当时在“看”什么，往往是修复错误与对着堆栈跟踪发呆之间的关键区别。

Useful, though, is not the same as harmless, and it certainly doesn’t mean I need to know everything else you happened to be doing that day. So when a form tells you that logs can contain text on screen, I’d like you to adopt one very simple rule: can means does. It doesn’t matter if you know the application, if you’ve read the source, or if you’re fairly confident the particular logging mode you used doesn’t capture anything sensitive; treat it as though it does. This is exactly the principle behind treating every firearm as loaded. You don’t point a gun at someone because you’re pretty sure it’s empty, and you don’t assume it’s safe because you remember unloading it earlier; you follow the same precautions every single time, because being wrong costs a great deal more than being careful.

然而，有用并不等同于无害，这当然也不意味着我需要知道你那天碰巧做的所有其他事情。因此，当表单告诉你日志可能包含屏幕文本时，我希望你采用一个非常简单的规则：可能意味着就是。无论你是否了解该应用程序，是否阅读过源代码，或者是否相当确信你使用的特定日志模式不会捕获任何敏感信息，都请将其视为已经捕获了。这正是对待每一把枪都应视为已装弹的原则。你不会因为确信枪是空的就用它指着别人，也不会因为记得之前卸过弹就认为它是安全的；你每次都会遵循同样的预防措施，因为犯错的代价远高于谨慎行事。

Obviously, accidentally sharing a private conversation is not equivalent to accidentally shooting someone, and I’m not pretending the stakes are the same. The point is that a safety habit is only worth anything if it doesn’t depend on your confidence that nothing can go wrong. You shouldn’t have to remember whether one version logs screen text under one configuration but not another, or which debug options you happened to leave on last Tuesday. Assume it captured everything it warned you it might, and then decide whether you’re comfortable sharing that.

显然，意外分享私人对话不等同于意外枪击他人，我并不是在假装两者的利害关系相同。重点在于，只有当安全习惯不依赖于你对“不会出错”的自信时，它才有价值。你不应该去记忆某个版本在某种配置下是否记录了屏幕文本，或者上周二你碰巧开启了哪些调试选项。假设它捕获了所有警告中提到的内容，然后决定你是否愿意分享这些信息。

Not Everyone Can Read Through Thousands of Lines

并非每个人都能读完数千行内容

The standard advice at this point is “just read the logs before you send them,” which sounds eminently reasonable right up until you think about it for more than a few seconds. Some log files run to tens of thousands of lines. Some contain binary data, encoded blobs, or structures that are meanin

此时的标准建议是“发送前读一遍日志”，这听起来非常合理，直到你深入思考几秒钟。有些日志文件长达数万行。有些包含二进制数据、编码后的数据块或结构，这些内容意味着……