有个思路不知是否可行
客户端(网页)需要运行一个耗时耗内存耗 cpu 的运算,得出的结果同刷屏结果一同 post 给服务器,服务器验证该结果符合某项特征(或预先算好并对应加载页面时的 request 或 openid 《微信》),符合特征则正常投票,不符合则发回客户端重新计算,直到计算正确为止。
这就要求该运算对非刷票用户来说没有影响,对刷票公司来说,则会耗尽对方的机器资源
以上是我的想法,不知道是否可行,如果有 V 友有更好的想法,欢迎提出来一起讨论。
另外,虽然有想法,但却不知道如何实现
1
fcicq 2016-06-03 23:07:17 +08:00
hashcash 嘛. 发展到极致就是要求付费投票, 因为计算能力或者电费也是钱.
|
2
ctsed 2016-06-03 23:56:09 +08:00
ty 以前想到过
|
3
gdtv 2016-06-04 00:04:31 +08:00
没有什么是钱不能解决的
|
4
just4test 2016-06-04 00:10:29 +08:00
这是拿你自己算力和攻击者的算力对烧啊。
|
5
just4test 2016-06-04 00:15:34 +08:00 1
我觉得可以不实时显示票数,这样刷票者就不能真正确定刷票是否有效。然后每过一个长周期结算,并排除所有可疑的投票。
最好还是付费投票,短信一块钱一条。想刷就刷呗。 |
6
peter999 2016-06-04 00:17:59 +08:00
可以利用凌晨的闲时资源,先算好大量结果存入队列,投票的时候再发给前端。
|
7
soland 2016-06-04 00:20:25 +08:00
是个好想法。
不同于通常的付费投票或是算力对烧。 可以不对等加密,使客户端的计算量远远大于。 |
8
shiny 2016-06-04 00:21:53 +08:00
如果刷票的经济利益大于计算开销,还是防不住的。
|
9
kkgogo 2016-06-04 00:26:52 +08:00
别着急,也许有两年这些就不是问题了,比如读取芝麻信用……
|
10
billlee 2016-06-04 00:30:25 +08:00 1
@just4test 双方付出的算力不一样,一般是要求请求方通过附加一个数,使得算出的 hash 符合指定特征(比如低 n 位全为 0 )。这样请求方要暴力尝试约 2^(n-1) 次 hash, 验证方只要算一次 hash 就可以了。
|
11
XianZaiZhuCe 2016-06-04 04:27:56 +08:00
@just4test 不实时显示票数 + 1
|
12
lecher 2016-06-04 05:15:10 +08:00 via Android 1
没有考虑过用户体验吗,一个普通用户投次票还要计算一段时间,活动流失率高了谁背锅。不是什么网站都有 12306 的用户刚需。
在对抗刷票这个事情上面,增加刷票成本确实是最合适的办法,这个方法在单次投票期望收益低于一毛钱的时候可以对抗。 通常单机 http 代理池做刷量的是一分钱一个的刷票。 到一毛一次的期望收益,就可以上虚拟机多开脚本批量刷了。 到一块钱一次的期望收益,投票抽奖之类的奖品,就等着被真机批量刷吧。 我知道像几块钱一次的应用活跃度刷量,淘宝刷单之类的。你要求一个手动操作流程耗时十分钟都有一票人不停刷。 只要收益足够,上僵尸网络也有人玩得起的。 类似的点子我记得 v2 有人的博客做过这样的计算,不过出发点是做防刷的,有效肯定是有效,浏览器的 js 那个渣性能,拖垮客户端都没问题。但是 js 是没法混淆代码的,除非期望收益低,不然把 js 代码一扒,转成 c 写的计算,照样刷你的接口。 |
13
ctsed 2016-06-07 12:13:38 +08:00
|