“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Chrome 用户代理冻结背后的隐私权衡与 Google 的跟踪争议
Google 通过 Chrome 安装 ID 跟踪个体用户，引发用户代理冻结提案的隐私争议。
本文基于 Hacker News 上的一则热门讨论，深入剖析了 Google Chrome 提出的 User-Agent（用户代理）字符串冻结与 Client Hints 机制背后的技术细节、隐私考量及社区争议。原文链接指向 W3C TAG 的 GitHub issue #467，其中 Google 工程师 Yoav Weiss 详细介绍了该提案，而 HN 评论则尖锐指出 Google 可能借此增强对个体用户的跟踪能力。
背景：User-Agent 字符串的隐私问题
User-Agent（UA）字符串是 HTTP 请求头中的一段文本，用于标识浏览器类型、版本、操作系统及设备信息。长期以来，服务器和网站依赖 UA 进行内容协商（如针对移动设备返回响应式页面）。然而，UA 字符串包含大量高熵信息，如精确的浏览器版本、操作系统版本、设备型号等，这些信息组合起来可形成强大的被动指纹，即使用户未主动提供任何数据，网站也能通过 UA 唯一识别用户，从而跨站点跟踪。
提案核心：UA 冻结与 Client Hints
2020 年，Google Chrome 提出对 UA 字符串进行部分冻结，并引入 Client Hints（UA-CH）作为替换机制。核心内容包括：
- UA 字符串冻结：
User-Agent请求头将仅保留浏览器的主版本号（如 Chrome/83），并移除平台和设备的详细信息。navigator.userAgent等 Web API 同样被冻结，以减少默认发送的被动指纹数据。 - 默认发送低熵 Client Hints：浏览器默认在请求中加入
Sec-CH-UA（浏览器品牌和主版本）和Sec-CH-UA-Mobile（是否为移动设备）两个头部。这两个头部信息量低，隐私风险较小，可满足多数内容协商场景。 - 高熵信息需显式协商：若站点需要更详细的设备信息（如平台、架构、型号），必须通过 Client Hints 的协商机制显式请求。这些高熵信息（如设备型号）通过异步 Promise 返回，允许浏览器在授信前进行隐私评估。
- GREASE 机制：为确保 UA 字符串不会被滥用，
Sec-CH-UA被定义为集合，并可能注入随机干扰值，防止站点依赖特定品牌或版本格式进行指纹识别。
此提案的时间线：计划在 Chrome M83（2020 年 6 月）开始冻结 UA，M85（2020 年 9 月）实现跨平台统一。该工作由 WICG 负责，Google 主导推进。
争议焦点：Chrome 安装 ID 与用户跟踪
HN 评论区的核心批评指向：Google 在减少被动跟踪的同时，内部却通过 Chrome 安装 ID（installation ID）跟踪每个独立用户。该 ID 与浏览器安装绑定，可识别同一浏览器的不同用户，从而使 Google 能够在服务器端将请求关联到个体，甚至跨越不同网域。这种“中心化”跟踪与提案声称的隐私改进形成鲜明对比，被指责为“自己砍掉别人的指纹，却保留自己的后门”。
评论者指出，Google 的动机并非真正保护用户隐私，而是巩固其在广告和流量分析中的主导地位。通过冻结 UA，Google 可以削弱第三方对 UA 的依赖，然后以 Client Hints 为杠杆，将信息获取的主动权收拢到自家浏览器和服务端。同时，Chrome 安装 ID 的存在表明 Google 依然有能力对用户进行持久化标识，而第三方则失去了 UA 这个公开且统一的指纹源。
技术细节与隐私权衡
UA 冻结的动机
UA 字符串的高熵特性使其成为跨站跟踪的理想载体。例如，User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36 中，Windows 版本、Chrome 完整版本号等组合可提供约 18 位信息。如果与其他指纹（如 Canvas、WebGL）结合，可唯一标识用户。冻结 UA 可显著降低被动指纹识别的信噪比。
Client Hints 的工作方式
在提案中，服务器通过 Accept-CH 响应头声明想要哪些高熵客户端提示，如 Accept-CH: UA-Platform, UA-Model。浏览器根据请求决定是否提供。默认发送的 Sec-CH-UA 遵循以下格式：
http
Sec-CH-UA: "Google Chrome";v="83", "Chromium";v="83", ";Not"Brand"";v="99"
其中品牌列表可能包含类似 "Not"Brand 的占位符，实际上通过 GREASE 机制随机插入，防止站点基于品牌白名单构建指纹。
低熵 vs 高熵的信息释放
提案的核心权衡是：低熵信息（如浏览器品牌、是否移动）默认公开，因为不足以唯一标识用户；高熵信息（如精确型号、架构）仅在站点证明需要时提供，且浏览器可异步处理，以便在用户可能知情的情况下决定是否放行。然而，这种设计并不断言完全阻止跟踪，而是试图平衡功能与隐私。
社区反应与后续进展
TAG 审阅者（包括 dbaron、hadleybeeman 等）在 issue 中提出了若干关闭建议，但等待共识。HN 评论普遍持怀疑态度，许多用户认为 Google 的隐私叙事是公关措辞，实则借标准化之名行垄断之实。有评论指出，Chrome 安装 ID 并非新事物，它常被用于安全防滥用与服务个性化，但 Google 从未公开其生命周期和用途，也未告知普通用户如何选择退出。
此外，有技术专家指出，UA 冻结可能让小型网站更难做设备适配，因为它们依赖于 UA 中丰富的型号信息，而 Client Hints 的协商机制增加了服务器实现复杂度，且需要额外往返请求（或使用早期提示），这对性能有负面影响。同时，非 Chrome 浏览器（如 Firefox、Safari）并未完全跟进实现 UA-CH，可能导致兼容性碎片化，使得网站在 Chrome 上获得的信息减少，但非 Chrome 浏览器仍然暴露完整 UA，反而加剧跨浏览器的不一致性。
结论与启示
Google 的 UA 冻结提案在技术上旨在减少被动指纹，但它的推进方式却暴露了中心化平台的双重标准：一边通过标准化削弱第三方可用的信号，一边依靠私有安装 ID 维持对用户的独特标识。这篇讨论提醒我们，任何隐私改进都需要审视其背后权力结构，否则可能成为科技巨头巩固生态的工具。对于 Web 开发者，理解 UA 与 Client Hints 的演变有助于更合理地设计隐私友好且功能完备的网站。
原文链接：GitHub Issue #467 评论