分享链接暴露账号
前几天刷到一篇帖子说小红书分享的链接里带有一个"appuid"的参数，就是分享人自己的账号id，给朋友同事分享笔记会暴露自己的账号，很多人对此并不知情且非常介意
很早就知道网易云分享歌曲的链接里带有uid，可以找到网易云的主页，如果绑定了微博默认会显示出来，这样就能从朋友圈一首歌找到微博
还有哪些应用分享行为带有用户id？
花了一会功夫把应用市场比较热门的app下载试用了一遍，发现其实还有一部分应用存在疏漏
比如 小红书、微博、网易云音乐、QQ音乐、全民K歌、喜马拉雅、雪球、Keep、 汽水音乐、百度、酷安、小宇宙、知识星球、知乎、哔哩哔哩、即刻等
（除此之外，还有某些app分享中带有用户id，但其产品没有web版，无法方便的从id访问用户主页）
最近正在学习前端开发，于是使用 modernjs + react + arco + tailwindcss 做了一个小页面，从分享链接快速找到分享人账号
输入分享链接即可查到账号名称
为什么会带有用户id？
此类应用大多带有社交属性，大数据为了猜测"你可能认识的人"，给你推荐关注列表，或者"猜你喜欢"给你推荐周围人正在看的内容
以此切中你的喜好，在应用里停留更多时长，消费更多内容
当然也包括广告，完善的用户画像能推送精准广告，提高转化率，广告主也会更喜欢投放广告了
早在PC时代，就有此类utm技术在使用，为了跟踪网站流量来源，在url后面额外增加一个utm_source参数，或者论坛邀请链接、返利链接，带有一个ref参数等等
分享链接可以反查账号能算隐私问题吗？
国内的个人信息保护法、网络安全法、民法典应该有个人信息或隐私保护相关的定义和规定，此场景可能不在法规或司法解释明确涵盖范围内
用户分享动作意图是分享内容本身，如果分享链接可反查分享人账号，会产生用户预期结果以外的副作用
在含有社交属性的平台，用户会有"不愿为他人知晓的信息"，而改变自身的社交行为，有一部分用户表达出不愿意他人知道真实身份与网络身份的关系
某些应用分享后页面直接显示用户名，不熟悉技术的用户起码有途径知情，主动避免分享
如何既要大数据关系又要保护用户隐私？
对厂商来说，"把功能砍了"也许是最简单的不泄露账号的办法，但追踪用户关系本身是正常的商业行为，也能切实提升服务质量，此外可能还有业务之外的意义
某应用近几天在注意到用户反应后，把明文uid替换成一串乱码，经过简单对比，发现算法类似于凯撒变换，属于非常容易就能转回明文uid的逻辑
厂商能注意到并且投入资源整改值得鼓励，即使最简单的变换提高一点门槛也能拦住绝大多数普通用户，在安全领域流传一句话叫没有绝对的安全防御只是提高攻击成本，用什么样的算法取得什么样的效果本身是一种正常的业务取舍决策
含有分享人账号身份的公开链接，只有厂商自己能关联到账号的流程：
在上面的过程中，用户分享行为要满足，含有身份信息的链接是公开的，关键在于只能由厂商自己关联到具体账号
uid编码
身份信息标识如果使用明文uid、位移变换、base64等可逆的简单编码算法，则毫无秘密可言，谁都可以做到第3点
md5
某应用使用md5(uid)算法生成用户身份标识，uid是纯数字形式的，各种md5彩虹表都会收录纯数字与md5值的对应关系，因此也是不可靠的办法
token
还有一些应用，采用较为复杂的办法，分享时向服务端请求生成一个share_token，服务端记录uid↔share_token的对应关系，此信息不公开，分享链接中公开的是share_token，外界无法使用token查询uid，唯一的问题是需要额外存储数据
aes
某应用使用aes算法和密钥加密用户uid，然而加密逻辑是放在客户端进行的，key也存储在客户端，约等于公开信息，不符合"只有厂商可以关联"
多id
某蓝色应用，有多套用户身份id，业务逻辑使用一种，分享中使用另一套，分享链接中取得的身份标识无法对应到账号主页的id。有个小小的问题，同一个账号每次分享中带有的身份标识都是相同的，虽然不能直接知道是谁分享的，但可以知道这些链接都是由同一个用户分享的
非对称算法
aes的方案已经很不错了，客户端可以自主生成不需要服务端运算，问题是key的保密程度，如果所有用户都使用同一个key，又是在客户端加密，可逆是必然的
想要既不用额外存储数据又能不泄露账号，可以使用非对称加密算法，如ECC、ElGamal、RSA、SM2、rabin 等，美中不足的是密文可能会长一些