V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sillydaddy  ›  全部回复第 73 页 / 共 95 页
回复总数  1893
1 ... 69  70  71  72  73  74  75  76  77  78 ... 95  
2021-04-28 12:50:28 +08:00
回复了 eachin 创建的主题 程序员 有没有办法防止 app 内资源被提取呢?
水印的形态不只是图像!!还记得阿里截图员工被查出来的事情吗?

既然试卷的内容、字帖的内容都是你能控制的,为什么不在试卷内容中加入“文字指纹”呢?给每个用户分发的都是带有不同指纹的试卷。甚至如果可以的话,每套试卷中的题目都作一些细微的变形。比如数学试卷中的方程系数、语文试卷的词组选择。

试卷是分期发放、一次交费,然后抄袭一次,永久封号!!钱款不退,甚至倒赔!!
@235777178
也不是抬杠,你看下 2 楼的回复,再结合下面 2 个链接,1 个链接是 7 年前的,1 个链接是 2 年前的:
15 款优秀原型产品 ( http://www.woshipm.com/rp/64741.html )
9 款原型工具 ( http://www.chanpin100.com/article/109790 )

现在都流行微交互了 ( https://www.uisdc.com/micro-interactions-why-when-how )
新的原型工具能更流行,肯定是有需求在推动着的吧。
@235777178 分阶段是肯定的。不过,我想要的原型工具,要能应对原型设计的各个阶段。。所以就需要去分析一个原型工具到底是什么,把它的构成要素抽象出来,看看市面上的工具是不是符合,各个工具的侧重点在哪儿。
2021-04-26 13:28:20 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@DeutschXP #33 这个问题不在“不应该靠技术解决”的范围内吧
@lance6716 #35 不清楚安全多方计算能不能做到。在这个例子里,多方要计算的目标是什么呢?
2021-04-25 17:12:30 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@murmur #28
你从哪儿看出来我要解决整个“链条”的问题了? 你说的跟这个主题讨论的根本不在一个范畴。
2021-04-25 16:39:13 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@weimao #25
我用数据验证了一下你在#15 的方法,看系统如果故意随机漏掉用户的订单,会有多大的概率被发现。

如果将“间谍账号”生成的“间谍订单”的数量固定为 50 个,而系统要故意漏掉总订单数量的 10%,那么
- 实际 100 个订单,其中 50 个“间谍订单”,故意漏掉 10 个订单,不被发现的概率 < (50/100)^10=0.0009
- 实际 1000 个订单,其中 50 个“间谍订单”,故意漏掉 100 个订单,不被发现的概率 < (50/1000)^100=0.00592
- 实际 10000 个订单,其中 50 个“间谍订单”,故意漏掉 1000 个订单,不被发现的概率 < (50/10000)^1000=0.00665
- 实际 100000 个订单,其中 50 个“间谍订单”,故意漏掉 10000 个订单,不被发现的概率 < (50/100000)^10000=0.00673

所以,只要安排 50 个间谍订单,如果系统故意漏掉了 10%的订单,就能被以 99%以上的概率被发现。也就是说,如果大股东想通过故意漏掉 10%的订单来增加自己的收益(大概提高 11%的收益),那么其他股东发现其作弊的概率高达 99%以上。
这种随机插入“间谍订单”的方法,配合你说的哈希值编号,可以很容易发现大股东的作弊。

你说的 merkel tree 的方法,我再消化一下。
2021-04-25 16:15:18 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@q197 #23
对对,我想的一种方法就是这个,哈哈,前端的代码是可以审查的。。不过应该需要配合一定的加密签名、然后用户要支持匿名,否则服务器可以针对不同的登录用户提供“差别前端代码”,你懂的。用户匿名的方法,其实可以用“授权下的匿名”( /t/771869 ) 这种。
2021-04-25 16:11:43 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@libook #21 >“暂时没有办法能 100%保证买家一定是通过统一的渠道交易的” , “运营股东完全可以开 2 个支付渠道,一个上链,另一个不上链,结算的时候只用链上数据结算,最终还是可以贪掉不上链的部分”

我考虑的都是前端都是公开的情形,可以对前端的代码进行审计。如果交易渠道可以有多个的话,那么这些渠道应该是公开可查的吧。如果是通过针对特定的用户提供“秘密的”交易渠道,那仅仅对前端做检查就不管用了。

不过,正像#10 楼提到的,这种应该用税务审计之类的就可以了吧。
2021-04-25 14:36:33 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@rain2meng #13
@Veneris #14
用区块链+合约+代币,应该可以解决,就是感觉是牛刀小用了。另外还得考虑代币的价值有波动吧,结算的时候。

@weimao #15
仔细想了下,这个思路还是有漏洞。比如大股东以一定的概率,漏掉订单。然后把其他没有漏掉的单子,排列拼接起来,生成你说的一系列哈希。这种漏单能否被发现,就看小股东伪装用户下的订单数量了。具体的概率计算应该类似于“生日问题”
( https://zh.wikipedia.org/zh-hans/%E7%94%9F%E6%97%A5%E5%95%8F%E9%A1%8C )
2021-04-25 12:52:42 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@westoy
哎,真实的需求是这样的:

某人要制作一个收费的订阅,用户付月费或年费来订阅其信息。然后这个人可以接受别人的投稿,然后按照约定的比例拿到订阅费。并且自己拿到的订阅费是可以独立验证的,没有被那个人侵吞。

所以,哪里不是正经业务流程了?非要我说实话才行啊。
2021-04-25 12:30:24 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@Vegetable #7 订单是可以被后台篡改的
@wy315700 #8 学习了,研发可以控制代码,发行可以控制收入。不过主题里的大股东既控制收入又控制代码。
2021-04-25 11:15:48 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@murmur 查库存这个确实是一个方向。不过如果卖的是可以拷贝的软件之类呢? 软件的库存不像实物商品,要想各个股东就商品的库存数量认识达成一致,还是需要密码学来处理。
2021-04-25 11:06:23 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
@summic
可以看一下主题里提到的“授权下的匿名”,感叹一下密码学的应用可以达到怎样的高度。
怎么会是伪需求呢?
2021-04-25 11:01:53 +08:00
回复了 sillydaddy 创建的主题 奇思妙想 能不能应用密码学,解决订单操纵,实现收益分摊?
“各个股东可以验证这一点几乎 100%成立”
这里“几乎 100%”的含义,类似零知识证明里面的“证明了命题以接近 100%的概率成立”。
2021-04-22 19:44:55 +08:00
回复了 sillydaddy 创建的主题 MacBook Pro m1 mba 的白色文字太刺(亮)眼
@wipbssldo
去线下店对比了一下,应该是机器屏幕的问题,或者是哪里配置的有问题,店里的机器没有问题。不过确实找不到哪里的配置有问题,因为之前用的默认配置就有问题。
2021-04-22 18:24:40 +08:00
回复了 sillydaddy 创建的主题 MacBook Pro m1 mba 的白色文字太刺(亮)眼
@SorryChen 重影和光晕,应该是眼睛散光吧。我没有这种情况,我说的“光晕”在附言里面解释了,就是文字显得比周围格外的亮。
2021-04-22 18:22:52 +08:00
回复了 sillydaddy 创建的主题 MacBook Pro m1 mba 的白色文字太刺(亮)眼
@wipbssldo
不只是 VSCode 的问题啊,整个系统、还有所有其他软件都是这样。
2021-04-22 17:44:16 +08:00
回复了 sillydaddy 创建的主题 MacBook Pro m1 mba 的白色文字太刺(亮)眼
@lostberryzz
你说的这个不是主要的问题。问题跟具体的“主题”没关系,是这台笔记本整个表现就是那样——白天虽然问题没暗光条件那么严重,但相比其他的显示器,仍然让人不舒服。
@no1xsyzy
对,就是切断“使用记录”与“注册记录”的联系。

比如 10000 个用户注册并使用服务,服务提供方知道这 10000 个注册用户的注册信息(包括付款信息),也知道这 10000 个用户各自的使用过程信息(比如浏览记录)。但没办法建立注册信息与使用过程信息的一对一关系。

如果主题中的第 3 条成立,那么服务提供方可以把用户准确地区分为 10000 个,各自画像,但画像信息与注册信息是解除关联的。如果主题中的第 3 条不成立,也就是说服务方无法确定用户由同一个授权码生成的不同登录码实际上是同一个授权码生成的,那么服务方甚至都不能确定这 10000 个用户画像。
1 ... 69  70  71  72  73  74  75  76  77  78 ... 95  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1098 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 18:22 · PVG 02:22 · LAX 10:22 · JFK 13:22
Developed with CodeLauncher
♥ Do have faith in what you're doing.