如何负责任的分享 Web 内容？

TL;DR

不要用 App 内置的分享到 XX 应用，总是选择复制链接。 （避免分享 “XX 小程序” 出去）
粘贴链接之前，小心地去除任何可能的追踪参数，既保护了你自己，又潜在的保护了将要点击你分享出去的链接的人。
除非那破网站有登录墙或 App 墙等各种阻碍正常 Web 浏览器访问的措施，否则不推荐发送截图或复制其中的内容。（如果还要担心有没有盲水印的话，那干脆就别发了。）
如果目标页面没有使用复杂的 JavaScript 功能，那么发送存档服务的链接也可。
在你（和/或你的受众）都信任替代前端服务的搭建者时，推荐通过发送替代前端替换后的链接来分享。

虽然我对最近谁被请去喝茶了没什么兴趣深究，但是其中一个可能的细节还是值得考究的，就是当事人可能是因为对外发送过带跟踪参数的某网站短链接导致暴露了在国内某服务上的身份，于是就有了下面这堆牢骚话。

追踪参数如何让你被真名识破？

当你使用 Bilibili 的分享功能复制链接的时候，你也许会复制到类似 https://b23.tv/.......
这样的短链接。假如你神经大条的把这个链接发出去，收到这个链接的会在若干次重定向之后打开那个视频，而你也可以通过 curl 一类的工具还原这个短链接实际指向的长链接地址：

$ curl -I https://b23.tv/GWDMJ5
HTTP/2 302&nbsp;
date: Sun, 15 Oct 2023 13:02:15 GMT
content-type: text/html; charset=utf-8
bili-trace-id: 513b2f0d4e652be2
location: https://www.bilibili.com/read/mobile/12266949?share_medium=iphone&share_plat=ios&share_source=COPY&share_tag=s_i&timestamp=1627216486&unique_k=GWDMJ5
x-bili-trace-id: 7cd64f96059509d9513b2f0d4e652be2
expires: Sun, 15 Oct 2023 13:02:14 GMT
cache-control: no-cache
x-cache-webcdn: BYPASS from blzone01

某些时候的短链接可能包含更多信息，例如：

$ curl -I https://b23.tv/iQkBqVn
HTTP/2 302&nbsp;
date: Sun, 15 Oct 2023 13:10:39 GMT
content-type: text/html; charset=utf-8
bili-trace-id: 13a35d5275652be4
location: https://www.bilibili.com/video/BV1D8411C78Q?buvid=XU4C87040D0715B95C554A348D4863CCC4C15&is_story_h5=false&mid=vRmF9iEoR%2BuQXWe2eXQRFg%3D%3D&p=1&plat_id=114&share_from=ugc&share_medium=android&share_plat=android&share_session_id=396a73f2-7a73-45fd-8295-e2695d68aee0&share_source=COPY&share_tag=s_i&timestamp=1696669731&unique_k=iQkBqVn&up_id=1380853338
x-bili-trace-id: 1c102794b8920b3f13a35d5275652be4
expires: Sun, 15 Oct 2023 13:10:38 GMT
cache-control: no-cache
x-cache-webcdn: BYPASS from blzone02

于是，问号之后的一大堆参数会在用户访问这个地址的过程中传递给服务器，服务器就可以通过这些参数知道例如这个用户来自什么平台（share_source，不过更通用的 UTM （Urchin Tracking Module）参数应该都是 utm_ 前缀的，例如 utm_source）、通过谁分享的链接打开的内容一类的各种信息。

如果硬要说这些追踪参数有什么积极意义的话，那就算是可以通过合适的追踪参数帮助产品经理和程序员分析各种渠道的性能表现、转化率等指标，并可以根据收集到的数据对特定渠道进行优化。（嘛，不做负优化做不错了吧 😅）

而对用户来说，追踪参数看不到一点点的好处，无外乎是又多卖了一些个人资料给各个大公司。以及因为这些参数都直接写在了请求里，别有用心的人就可以收集这些参数来达成各种各样的目的，例如跨平台识别用户、溯源分享者等等。

分享之前首先要有链接

介于强国 App 特色的不待见链接的环境，很多 App 都会在分享时“聪明”的帮你分享所谓的小程序链接。因为啥链接都没有，所以操作的空间说不定会比链接更大。
如果你在意你和你潜在受众的隐私，你就应该不要通过 App 内置的分享到 XX 应用的功能，而是选择复制链接。然而总会有意外情况。

有些应用根本就不提供复制链接的功能，那多半还会有包括登录墙等等的劣化网页浏览器用户体验的糟心操作，那大概也没什么分享的必要了。
QQ 等强国产 IM 还有贴（sha）心（bi）的“网址安全检测”机制，基本上会拦截不在它们“良民”名单里的绝大多数网址。如果不确定你的受众是否有足够的智力水平复制网址在浏览器里打开，那也不要费那么大劲了。

如何去除短链接的跟踪参数？

理论上，把问号之后的所有参数拿掉一定能够去除跟踪参数。但是不巧的是，有些问号后面的参数是有用处的，例如 YouTube （ https://www.youtube.com/watch?v=nC-bVtpIMd4 ）和 MediaWiki （ https://www.mediawiki.org/w/index.php?title=MediaWiki ，你经常在维基百科之类的 MediaWiki 网站见到的形如 wiki/MediaWiki 这样的链接是需要另外配置 URL 重写规则的）。因此要去除可能的跟踪参数时，有可能需要其它的工具帮忙。

Chrome 、FireFox 和 Microsoft Edge 可以安装Clear URLs扩展，这个扩展可以自动清理 URL 中的可能的跟踪参数，接下来只要复制浏览器上显示的 URL 就好了。
Android 上也有像 URL Check 之类的工具可以帮忙从分享（或剪贴板）中清理 URL，然后仔分享给其它应用。
iOS 上可以通过一些快捷指令操作来完成类似操作，例如我正在使用的这个。
- 我也是从别的地方抄来的，不过一时没找到来源 😂
- Mac 上的快捷指令 App 可能不能在复选框操作里不选择一个选项，这个时候大概可以选一个最短的绕过去？
  如果只是想去除某个服务短链接中的跟踪参数的话，也可以考虑某些独立的服务，例如 Nicholas Wang 搭建的 https://b23.wtf .

备选项：存档服务或替代前端

如果你要分享的内容不是视频一类的大型内容，网站的交互也不是那么依赖 JavaScript 的话，你也可以考虑先让 Internet Archive 或者 archive.today 一类的存档服务帮你先存档一份，再把存档后的链接发给你的接收对象。
此外，还有一些其它的自由软件爱好者为现有的服务开发的各种替代前端。例如 YouTube -> Invidious 、Twitter -> Nitter 等等。PrivacyTools 有维护一个各类流行网站的替代前端的列表，有需要的话可以加以利用。

Reference

已发布

2023年10月16日

分类

杂记

来自

Foo

标签：