你分享的链接泄露隐私了吗？ - 迅博思语资讯移动站

你分享的链接泄露隐私了吗？

2024-10-31 23:51

前几天刷到一篇帖子说小红书分享的链接里带有一个“appuid”的参数，就是分享人自己的账号id，给朋友同事分享笔记会暴露自己的账号，很多人对此并不知情且非常介意

你分享的链接泄露隐私了吗？

很早就知道网易云分享歌曲的链接里带有uid，可以找到网易云的主页，如果绑定了微博默认会显示出来，这样就能从朋友圈一首歌找到微博

花了一会功夫把应用市场比较热门的app下载试用了一遍，发现其实还有一部分应用存在疏漏

比如等

（除此之外，还有某些app分享中带有用户id，但其产品没有web版，无法方便的从id访问用户主页）

最近正在学习前端开发，于是使用 modernjs + react + arco + tailwindcss 做了一个小页面，从分享链接快速找到分享人账号

uid.ejfkdev.com

输入分享链接即可查到账号名称

此类应用大多带有社交属性，大数据为了猜测“你可能认识的人”，给你推荐关注列表，或者“猜你喜欢”给你推荐周围人正在看的内容

以此切中你的喜好，在应用里停留更多时长，消费更多内容

当然也包括广告，完善的用户画像能推送精准广告，提高转化率，广告主也会更喜欢投放广告了

早在PC时代，就有此类utm技术在使用，为了跟踪网站流量来源，在url后面额外增加一个utm_source参数，或者论坛邀请链接、返利链接，带有一个ref参数等等

国内的个人信息保护法、网络安全法、民法典应该有个人信息或隐私保护相关的定义和规定，此场景可能不在法规或司法解释明确涵盖范围内

用户分享动作意图是分享内容本身，如果分享链接可反查分享人账号，会产生用户预期结果以外的副作用

在含有社交属性的平台，用户会有“不愿为他人知晓的信息”，而改变自身的社交行为，有一部分用户表达出不愿意他人知道真实身份与网络身份的关系

某些应用分享后页面直接显示用户名，不熟悉技术的用户起码有途径知情，主动避免分享

对厂商来说，“把功能砍了”也许是最简单的不泄露账号的办法，但追踪用户关系本身是正常的商业行为，也能切实提升服务质量，此外可能还有业务之外的意义

某应用近几天在注意到用户反应后，把明文uid替换成一串乱码，经过简单对比，发现算法类似于凯撒变换，属于非常容易就能转回明文uid的逻辑

厂商能注意到并且投入资源整改值得鼓励，即使最简单的变换提高一点门槛也能拦住绝大多数普通用户，在安全领域流传一句话叫没有绝对的安全防御只是提高攻击成本，用什么样的算法取得什么样的效果本身是一种正常的业务取舍决策

含有分享人账号身份的公开链接，只有厂商自己能关联到账号的流程：

在上面的过程中，用户分享行为要满足，含有身份信息的链接是公开的，关键在于只能由厂商自己关联到具体账号

身份信息标识如果使用明文uid、位移变换、base64等可逆的简单编码算法，则毫无秘密可言，谁都可以做到第3点

某应用使用md5(uid)算法生成用户身份标识，uid是纯数字形式的，各种md5彩虹表都会收录纯数字与md5值的对应关系，因此也是不可靠的办法

还有一些应用，采用较为复杂的办法，分享时向服务端请求生成一个share_token，服务端记录uid↔share_token的对应关系，此信息不公开，分享链接中公开的是share_token，外界无法使用token查询uid，唯一的问题是需要额外存储数据

某应用使用aes算法和密钥加密用户uid，然而加密逻辑是放在客户端进行的，key也存储在客户端，约等于公开信息，不符合“只有厂商可以关联”

某蓝色应用，有多套用户身份id，业务逻辑使用一种，分享中使用另一套，分享链接中取得的身份标识无法对应到账号主页的id。有个小小的问题，同一个账号每次分享中带有的身份标识都是相同的，虽然不能直接知道是谁分享的，但可以知道这些链接都是由同一个用户分享的