【RFC-056】 给用户赞数、葱数添加一个小的随机值
变更内容：给用户数据（赞数、游戏币）在服务器端添加一个nounce，值为-3到3之间的随机整数。不改变数据库数值，也不在前端做处理。
变更理由：现在有用户通过点赞之后葱数的变化推测匿名用户身份，使得匿名功能名存实亡。
讨论时间：截止到2019年5月4日。
变更理由：现在有用户通过点赞之后葱数的变化推测匿名用户身份，使得匿名功能名存实亡。
讨论时间：截止到2019年5月4日。
90 个评论
点赞倒扣葱？葱明
感觉品葱的匿名功能本身就没多大意义, 因为帐号注册时就是匿名的不需要提交个人信息. 而且无限注册小号. 只要不在帐号里故意暴露个人信息, 品葱帐号本身就是匿名的.
仍然可以通过多次请求，计算平均数的方法得到相当准确的真实数值。
但是可以留下浏览指纹，再说了，本站社工人才济济，人肉帖每天变着花样的发，你还是图样。
确实是个匿名身份，只要id和现实身份没有联系的话就是。
不过有些人在虚拟世界里会在乎这个虚拟世界的身份的
不过有些人在虚拟世界里会在乎这个虚拟世界的身份的
改成一段时间之后再更新公开赞数比较好，随机数值没有意义，只要有变化多线程很快就查出来了，但延迟更新意义很大。只有被踩/赞的匿名用户本人可以实时看到自己的赞踩数，其他用户需要等待最长24小时才能看到变化，完美解决查匿名bug
回复楼上匿名的:
第一, 你可以了解一下Tor
第二, 你可以无限注册小号.
我不喜欢品葱匿名功能主要就是因为匿名的用户无法回复, 交流很不方便.
第一, 你可以了解一下Tor
第二, 你可以无限注册小号.
我不喜欢品葱匿名功能主要就是因为匿名的用户无法回复, 交流很不方便.
那匿名状态下回答文章被点赞无法获得葱币不可以吗
随机数值只要看变化还是可以查出来，多线程查5000用户只需要1秒，查到在你点赞之后变化的用户立刻依次尝试筛选特定用户，即可查到匿名究竟是谁。随机时间后更新赞踩可以有效解决这个问题
不觉得, 我以前就是你说的"长期活跃用户", 现在一个号用一段时间就废除一个换下一个, 还不是照样能讨论,嘿嘿嘿
取决于你随机数分布的方差，但注册n个小号大于你的variance我点n次赞超过你的variance就可以查到
其实如果每次点赞只增加0.5这么来算，但是显示都是整数，也是可以，只不过这样大家又要抱怨葱数太少了
我只要知道你的最大值和最小值的差就可以了，根本不需要知道你的distribution，这个只要多访问就能找到，比如你最小减30最大加40，差是70，我注册70个小号就能查出来，小号目前点赞没有权限，没有任何需要有高级账号的必要
200线程遍历5000用户亲测只要1秒钟，100个用户点赞也只要1秒，然后取消全部赞，3秒内完成。即使被发现后台也没有点赞记录，毫无笋丝，况且点赞的都是小号
现在只要注册就能点赞，有什么养小号的必要吗？
这个代码很简单，我1小时内python就能写完开源，让支字头贡献一下他的小号就可以做个在线查匿名，毫无难度可言
而且你的随机数太大了会对用户造成困扰，随机加减太大数会导致用户体验下降，而小范围浮动又可以几个小号查出来，所以最好的办法还是延迟显示
声望、赞同、游戏币之间究竟有没有直接的转换关系，究竟哪个是直接用户该用户在网站用户群体中的定位。
如果只有声望，而赞同、游戏币和声望之间采用具有修约的转换（比如20赞同转换1声望）甚至是更加复杂具有更多其他变量的转换，那么只要设置成仅声望对外可见就可以了。
如果只有声望，而赞同、游戏币和声望之间采用具有修约的转换（比如20赞同转换1声望）甚至是更加复杂具有更多其他变量的转换，那么只要设置成仅声望对外可见就可以了。
没有转换，全部都是分开的，所以没法只显示一个。我提出的延迟显示应该是最好的，给用户本人当场显示赞踩变化，给其他人一个随机时间后显示赞踩变化，这样便没有任何办法可以查到，因为每次点赞的显示时间都不一样，除非能遍历本站所有赞踩变化实时记录，然后多个小号同时点赞用来fit Poisson process，但难度太大
赞同数我认为有公开必要，因为威望目前是只有管理员点赞才会增加，所以并不能体现一个用户真正的水平。即使仅显示威望，管理员用户一样可以查看匿名，随机加减也挡不住@BE4 这类有多个管理员小号的用户
先随机后修约，先随机目的是避免泄露修约边界，如果后随机那么攻击方可以直接砍掉随机数。
可以先把用户数据的被动变化放入缓冲区，等到缓冲区的记录达到一定数量后再批量结算。
我只要有足够多的小号就可以测定。10个小号不够威望的平均变化我用20个，30个，直到我知道n个小号可以造成威望变化之后我就用这n个小号就能查出来，每次查之前都计算一下需要小号的数量就好了，支字头小号应该有几百个，你怎么约都约不过他
这就是我想要的，外加一个随机时间，不然我一次性点一个buffer size的赞一样可以查出来，但是小二死活不同意，十分奇妙深刻，这个办法比约分就多一个数据表，我实在不明白为什么不采用
没有任何区别，因为我只需要测试需要小号的数量即可。比如说，5个小号点赞的平均值是E1，10个小号点赞的平均值是E2，如果10个小号不够，那么E1≈E2，如此反复直到找到一个n然后平均值发生变化，你的再怎么随机也挡不住大数定理
赞同，注册只是为了沟通方便。没必要另搞匿名发言，尽力维护更没意义。
这种最简单的Monte Carlo就能解决的问题，有什么难猜的可能吗？（半恼）
新加一个表，不需要改
修约是把数从“数值”改变为“数量级”，由此对该数的分析就从“计算”和“比较”改变为了“统计”，这就已经是很大的门槛了。
另外随机的先后还是有一点区别的，比如修约20随机3，先随机就是数值119转换成100或120，而后随机那么数值119转换成117-123，这个随机很容易就能被砍掉变成120。
当然如果随机占到修约的一半以上那么先随机后随机就无所谓了。
另外随机的先后还是有一点区别的，比如修约20随机3，先随机就是数值119转换成100或120，而后随机那么数值119转换成117-123，这个随机很容易就能被砍掉变成120。
当然如果随机占到修约的一半以上那么先随机后随机就无所谓了。
I think it’s better to discuss this matter in English, I’m bad at communicating for academic related stuff in Chinese. I was saying the difference was not that much because I don’t need to know your exact rule for approximations and generations of the random numbers. I only need to know the number of likes needed to result in a significance change in anything you display beyond the stochastic fluctuations. This can be done very easily by grid search and Monte Carlo method, as mentioned above.
I just need to know the range of your fluctuations by repeatedly requesting the number, then I set an array, say {5,10,20,30,50}, which are number of accounts ready to like the anonymous comment. If 5 accounts doesn’t make a change in the number beyond the range, I try 10 accounts. If 10 doesn’t work, I’ll try 20, and so on. As long as I have enough accounts to like, I will eventually know the number of accounts needed to make a significant change over the range you set, regardless of your rules.
随机时间更新，没办法发现
你可以设置成至少24小时后才显示，在24小时后加一个随机延迟，如果这个人24小时内不上线查看至少有管理员查看，直接帮他清空赞数就好了，然后封了所有点赞的号，他1M号直接废掉，换个高级点的验证码能累死他
10个号不一定有用，因为有活跃用户一天收到的赞超过10个，你10个号也没用，账号数量必须大于一个用户一天能获得的最大赞数，如果你设置延迟最低24小时
结果还不是要有人定期看着嘛……
而且不是延迟多久的问题，而是延迟的范围要远大于点拇指的数量，否则就是生日漏洞。
比如攻击者间隔60s检查一次，24h一共才1440个60s，根本不够，而如果延迟再放长那对正常用户的体验就太差了。
而且不是延迟多久的问题，而是延迟的范围要远大于点拇指的数量，否则就是生日漏洞。
比如攻击者间隔60s检查一次，24h一共才1440个60s，根本不够，而如果延迟再放长那对正常用户的体验就太差了。
这个办法需要时间，其次需要计算用户最大得赞量，其实是门槛很高的，不如两个办法结合，随机显示+随机延迟更新，应该就没有办法了，因为你不能立刻得出需要的小号数量，因此需要尝试很多小号，一瞬暴露自己所有小号
不是回答，是一个用户一天累计收到的赞的数量，我认为minwooilbo一类的人抖机灵一天能抖出来10个
呜呜呜～我才知道小二是男生，但我依然爱小二，做我的好朋友吧
https://www.pincong.rocks/question/3753
fpkqletybscal
新注册用户
> 现在有用户通过点赞之后葱数的变化推测匿名用户身份，使得匿名功能名存实亡。
个人认为品葱的"匿名"功能在品葱这种敏感环境下本身就是鸡肋, 因为匿名只是在前台, 后台还是能关联.
想想共匪实名制的"前台自愿, 后台强制".
真正的匿名就是要允许不注册不登录的游客发帖.
个人认为品葱的"匿名"功能在品葱这种敏感环境下本身就是鸡肋, 因为匿名只是在前台, 后台还是能关联.
想想共匪实名制的"前台自愿, 后台强制".
真正的匿名就是要允许不注册不登录的游客发帖.
可以整合个64chan进来，无需注册随便发帖，不做任何管理，用户可以自己选择显示/不显示64chan的内容，默认不显示
可以整合个128chan进来，无需联网自动发帖，不做任何管理，用户可以自己选择发还是不发贴，默认发帖。
不整合进来就没人用的
不联网进来就没人用的
fpkqletybscal
新注册用户
可以参考"编程随想"博客评论区. 允许游客发言, 评论区有垃圾也有干货
我看误差很大，那些所谓用脚本点赞判断匿名用户的跟乱猜差不多，他们在放烟雾弹而已。那个支字头和小站那边来的开始一口咬定我就是KP2020，我就是那个发帖的楼主，其实他们是搜索到KP2020用过我在某几个问题下的答案，直到170多楼PonnyMa自爆家门他们才恍然大悟。你可以注册几个小号去那个帖子点赞看看是不是我发的。
wwemywznuyc
新注册用户
目前的匿名功能在"品葱"本身安全有保证可信的情况下, 问题是品葱有把握自己不被各种形式的控制?比如品葱服务器上的内部数据库和日志被御用骇客入侵读取, 品葱某天时运不济像旧品葱一样被查水表甚至被接管控制. 应该采取一些方法避免"品葱"这个单点风险, 不仅只是公开数据保证品葱数据信息的延续, 同时也要想办法保证即使自身被(暗中或直接)控制也无法fingerprint用户.
点赞导致匿名功能如同虚设的根本原因在于账号系统，这也是品葱为何能区别于匿名版。账号，account，accountability，既然匿名了就是不想让这个账号为这个匿名发言负责，所以匿名得到的赞或踩为什么要计入大号呢？
我觉得品葱应该实现商业化，引进一些广告，收入用来开发更牛逼的功能，以及聘请专业的程序团队，开发手机APP等，最后上市，然后雇佣军队，暗杀共匪，扶持新的反对力量，最后建立大品葱共和国，实行联邦制，民主制。
小号也不受惩罚，还是注册成本太低，封了再注册一个只要3秒钟
baigz
新注册用户
可以考虑只有高分用户才能匿名并且高分用户匿名时被踩被赞不计入其帐号
DOOM_Slayer已经说了：因为帐号注册时就是匿名的不需要提交个人信息. 而且无限注册小号。
所以按你的逻辑，就算不使用匿名功能，一样可以使大号免受惩罚，一样垃圾信息满天飞。
可以考虑积分兑换匿名券，一张可以匿名发言一次，可预先兑换，不用担心攻击者事后观察积分变化。
所以按你的逻辑，就算不使用匿名功能，一样可以使大号免受惩罚，一样垃圾信息满天飞。
可以考虑积分兑换匿名券，一张可以匿名发言一次，可预先兑换，不用担心攻击者事后观察积分变化。
ficbtzr
新注册用户
现在也仍然只是后者(新注册用户不能匿名), 另外可以考虑匿名时的踩赞数值单独的作为一个变量只计入后台并且只用于后台的权限判断之类, 不以任何形式直接公布.
