关注

网页版抽奖小助手思路:

打开小助手页面,有输入框可以输入发起抽奖的实例地址;

点击授权,去该实例验证一下身份;

回来之后小助手页面出现抽奖设置选项,比如抽奖活动介绍,奖品是什么,参与的条件是什么(转发?回复?点星星?),中奖人个数,以及活动截止时间,可以附图;

确认后,由小助手自动发布抽奖嘟文。并从发布起,开始记录参与抽奖的嘟友 ID,到上一步设置的活动截止时间,自动发布一条嘟文宣布并艾特随机抽取的中奖者。

---

逻辑好像……十分简单,由小助手(以嘟友的身份)来发布抽奖嘟文,就可以实时记录所有参与者,不像用脚本在最后截止时去获取数据那样有漏掉参与者的风险。

不过为了一个并不常用的功能专门去跑个获取推送通知的服务……似乎有点浪费资源啊。

举个简单的例子来「完善」第三方抽奖工具:

首先,把每个参与者的数字 id 加起来得到一个数字。验证方式是在web界面找到参与者的名单,手动去查看每个参与者的页面源代码找出 ID,手动加一下。

第二步,按参与顺序列出所有参与者,从头开始点算,一直数到上一步的那个数字为止。验证方式也是可以在 web 界面检查这个顺序是否属实。

工具只是做了一些机械劳动,把所有数字加好、把所有人员列好,把该数的数字数完……

这样就一定程度上排除了第三方「作恶」的可能性。

显示全部对话

@dimlau
>由小助手(以嘟友的身份)来发布抽奖嘟文,就可以实时记录所有参与者

除非本地跑一个daemon 进程,否则是无法做到这一点的。
而且由于API的限制,最终要么 /api/v1/notifications 定期轮询获得数据,也可以从 /api/v1/streaming/ 用 WebSocks 获得,但是 WebSocks 可靠性不能保证,最后还是要走一遍 /api/v1/notifications 验证一下数据。

@bgme 嗯,是打算用WS来着,总之它是从起始点开始记录。如果自己发嘟之后再去获取记录,时间差保不齐就漏掉了几个人。

@dimlau
>如果自己发嘟之后再去获取记录,时间差保不齐就漏掉了几个人。
写一个停止条件判断就可以了。

@bgme 即便还是用notifications那个API,也更方便点,确定了起始点,就感觉更稳健一点,不用像之前我们的脚本那样估算或者故意多去fetch十几二十次😂

@bgme 不过总之,为了它还要去搞个授权,可能不是太舒服。

甚至似乎还有义务告知使用工具的人,用完之后去授权应用页面取消授权,之类的。

@dimlau
把之前的我写的脚本升级为2.0版就OK了。

@bgme 但是,开奖时间点上使用脚本,还是不能像全程有工具自动进行那样,做到让参与者信任开奖者没有进行多次操作选了自己满意的一次来公布。

@dimlau
这个简单,可以通过 x-request-id、x-ratelimit 来保证。

@dimlau
而且你的开奖工具就靠谱了?
也许更不靠谱。

@bgme 从参与者角度来说,如果开奖者,在一个第三方的工具里设定了定时操作。到时间之后自动发布中奖人名单。

这个相对来说是更可信的。相对是指相对于后者:

开奖者自己确定开奖时间,自己在私下里用工具生成结果,自己把结果公布出来。

———

这个靠谱不是指随机性的靠谱,不是指技术层面的靠谱。而是,游戏规则的完成度上的靠谱。

我们都知道开奖者不欠参与者什么,即便是说我自己掐指一算感觉想把礼品送给第七个参与者,这也完全没问题。

但是如果想把它做成一个「活动」、「游戏」,还是尽量各司其职比较规范。

——

开奖者在自己本地用技术手段来证实自己的操作是公正的,当然有方法,但是,考虑到她的心情,自己发个礼物还要费心去自证所谓公正……偏离了「想搞个小游戏活跃一下气氛」的初衷。

不管什么工具,最终还是要靠人的良心。bot 所有者或黑掉了 bot 的人都可以作弊。

我常去的几个论坛流行用 random.org 开奖,对金额不大、少数人参加的抽奖活动够用了。
@dimlau @bgme

@dimlau
第三方抽奖程序**存在本身就是最大的不靠谱**,而且你所描述的第三方抽奖程序**存在极大的安全隐患**。

千说万说,最终的目的是为了保证抽奖参与者获奖概率相同的情况下,随机产生一个中奖者。

而你的第三方程序,相比起公开可验的开源脚本,你的第三方程序无法被大家公开检查。
那么从恶意的角度上来讲,如果你看某位嘟友不顺眼,你完全可以在程序里设置黑名单,让这位嘟友永远不会成为幸运者。而且更妙的是,由于你的程序运行在你的服务器上,大家无法检查你的程序是否公正。
你可以承诺你的程序是公正的,但是你无法证明你的承诺,你的承诺是不可信的。
如果你对新浪抽奖助手黑名单的事件[1]还有印像,你应当明白第三方抽奖助手是多么不靠谱的事。
再重复一次:第三方抽奖助手本身就是最大的不靠谱。

而且,你所想要实现的抽奖助手,最少要获取 read:accounts、read:notifications、read:statuses、write:statuses 四种权限。而且为了实现你所希望的效果,token必须存储于你的服务器中,这就带来了潜在的安全隐患。
如果你是恶意的,利用权限,可以干出不少事情。

[1] zhihu.com/question/278018820/a

@bgme

1、此处妳举的例子不太恰当。虽然数字上,发起方是一、参与方是二,似乎微博是三,但是其实微博平台在整个抽奖活动中是利益相关的,比如抽锦鲤什么的,会成为社会话题,微博属于受益方。更别提它本身就着力去「运营」抽奖活动,因此说他是第三方,在此处拿来类比就有点牵强;Mastodon 里搞抽奖活动,不管活动热度还是运营成效, 都是分摊到了不同的实例,工具本身不会成为收益方。

2、「第三方存在本身是最大的不靠谱」,这个结论也太武断。抽奖工具会采用开源形式、使用mastodon公开的API接口来开发。说它是安全隐患——如果不是针对我个人的话——那么这个隐患也同时包含在市面上所有的mastodon客户端中。抽奖工具只需要读写两三个权限。而客户端除此之外还需要其他几乎所有读写权限,包括妳提到的 Token 存储,包括推送消息,包括每一条嘟文甚至私信的读写、以及账户关系管理等……

3、我在前面的嘟文中已经给出了我对抽奖活动的看法:它首先是娱乐活动。事实上我们对妳所说的「获奖者概率相同」与否,都不那么在意。如果设置一个抽奖小游戏,回复某条嘟文的第五位嘟友获得奖品,概率相同吗?我们压根没法保证每位参与的嘟友都是时间空闲的……再举个例子说微信红包的随机金额,怎么证明它是随机的?

但是真的有人会有人抗议这种机械、刻板的概率问题吗?当我们在说抽奖活动的时候,更多的是说它作为娱乐活动的属性。而不是要进行绝对公平地重新分配全世界的财产。

其实这有点类似司法程序,我们当然希望得到绝对的公正,但是现实世界,绝对的实体公正是不存在的。

所以再次反对妳的「第三方存在本身就是最大的不靠谱」这个观点,第三方正是我们追求公正的途径,它是「程序正义」必不可少的一个环节。

作为游戏来说,自己设置奖品,自己公布结果,不管妳得出结果的演算过程如何缜密,都不如由第三方随手拨一下算盘得出结果来得更程序正义。

何况,想象一下,哪位嘟友如果想活跃气氛搞个小抽奖都要先使出浑身解数证明自己是公正的……

即便当事者自己不感觉心寒,旁观者大概也会觉得这个社会已经没救了。

我们可以用不断讨论、改进的方式,来避免甚至消除所谓程序隐患。但是,因为第三方也可能不完美就全盘否定它,似乎不是一个好的解决方案。

@dimlau
1、微博抽奖助手是不是第三方?
>但是其实微博平台在整个抽奖活动中是利益相关的,比如抽锦鲤什么的,会成为社会话题,微博属于受益方。

第三方:指两个相互联系的主体之外的某个客体,叫作第三方。第三方可以是和两个主体有联系, 也可以是独立于两个主体之外的内容。
从定义上来说,微博抽奖助手毫无疑问是第三方,而且微博抽奖助手即使是盈利性质的,也不会改变其第三方工具性质。

为什么早期还有企业使用自己的抽奖工具,后来就全是微博抽奖助手了呢?还不是微博把这些不用微博抽奖助手的抽奖全夹了的原因吗?

2、服务器究竟为谁服务?
请注意我原文中的这句话:『token必须存储于你的服务器中』。
你使用 Mastodon 第三方客户端,比如说 Tusky, Oauth认证之后返回的 Token 到底是存放于哪呢?是在你手机本地存储中,还是在 Tusky 开发者的服务器中?

3、如无必要勿增实体,而且使用设计良好的脚本,可以在保证安全性、公平性、有效性的前提下,同时保证易用性。

@bgme

昨天我说这个词的时候混淆了「第三方软件」的那个第三方含义,脑子里想着它属于「平台原生软件」…不过微博自己的抽奖工具是否第三方这个问题,我还是觉得利益强相关不能算作第三方。理论上那些大型抽奖活动微博都是主办方之一。

服务器存储token这一节内容。因为语境使 web 应用,所以我是说 第三方 web 客户端同样是用 Oauth 授权方式来登录的。

「如非必要勿增实体」我是赞同的,但是哪些是「非必要」还是需要斟酌的。就像在mastodon里发生的很多其他事一样,我觉得对隐私和安全负责的「权力」应该教给&交给使用者,屏蔽、静音以及管理应用授权,这些技能每个人都可以学会,使用工具时给出相应授权,用完再及时取消,大概会是个好习惯。

我们不能一边假设每个人都可以熟练使用浏览器的开发者工具执行调试代码,一边又假设使用者没有足够的能力和意识保护自己。

而如果人们可以自己管理好自己的授权,则从更集中、广泛的层面去管理、限制、抵制第三方工具,就成了另一种「非必要」。

不过我原本也是出于学习目的找点练手的小项目,思考了一番后感觉mastodon抽奖工具的需求不大,一色いろは 给出的 random.org 似乎已经足以覆盖绝大部分场景。所以,暂时不再考虑这个东西了。

登录以加入对话
TzCafe

一个畅所欲言的网上咖啡馆,欢迎在这里交流,就像在现实中的咖啡馆里那样。