昨天论坛里同时出现了我和其他几位开发者的关于突然读写剪贴板需要用户单次授权的问题:
监测剪贴板 一直弹出授权 点击确认 和取消后, 都会提出内容已复制
我们几位应该都是在首页onShow时使用了剪贴板内容,导致用户进入小程序就可以看到自己剪贴板的内容。并反复弹窗,这个对用户体验的伤害是灾难级别的。
昨天提交了临时屏蔽代码之后待审核,晚上团队对这个问题进行了激烈的讨论,最后决定彻底放弃对剪贴板实现页面routing的功能。这也让大家不需要等待这件事后续的调整结果了。
昨天在论坛里情绪激动,过了一夜之后平和点,但这里有一些对小程序团队,尤其是产品团队一些不得不说的话。
API的变更是否需要提前知会?
对于影响下游研发、整体生态用户体验的上线,是否应该有一个健全的知会和上线流程? 这次上线如果能先mp后台挂通知,然后文档先上线,再推基础库更新,这件事完全可以避免。我的观点里这个顺序应该是一个严格的流程,而到目前为止线上文档、开发者工具中仍然完全没有体现此次API体验变更的任何信息。我们小程序的客户也是微信的客户,现在大面积客户体验受影响是不争事实,这个在腾讯研发中算不算一个生产事故?
剪贴板到底需要不需要授权?
这完全属于讨论。我的个人观点是不需要;
一直非常支持也理解微信小程序在获取用户信息,本机电话,地理位置等等等等一系列用户隐私保护上做的设计,也一直觉得恰到好处。当然,监听并收集用户剪贴板里的内容到底有没有侵犯隐私的可能,这自然是肯定的。但这个可能性有多大? 第一剪贴板和输入法不同,不是一个连贯连续的数据采集过程;剪贴板数据偶发性和随机性特别大,所以从采集的数据规模,提炼转化的投入产出来说,都不是一个值得去实践的侵犯方案,在小程序的准入、审核门槛下风险更小。对于读写剪贴板都需要单次授权,我个人觉得是得不偿失的。到目前为止,个人还不知道任何OS、平台在剪贴板的使用上采用这样单次授权的先例,这意味着碰到剪贴板操作授权对于用户来说,都是一个全新的安全体验,这里需要付出额外的思考成本是巨大的。而应用如果只是在某种场景下使用到剪贴板,但又不得不在入口处进行检查(如手机淘宝使用淘口令)这样的授权体验会让用户怎么想?本来是非常innocent的事,反而显得非常malicious。我觉得在这点上强化用户授权行为是没有必要的,消除evil是好的,但不能成一个witch hunt。
即使授权,需要在弹窗里显示剪贴板内容么?
个人对这个设计也不理解。昨晚团队最终决定彻底割舍功能的原因,并不是完全因为有一个弹窗的干扰,而是因为这个弹窗会展示剪贴板的内容!我不知道产品经理自己是否实际体验过,这是有多么惊悚!现在大多数的移动设备都是不会关机的,而剪贴行为是一个偶尔发生的行为,但剪贴的内容往往比较重要且隐私,可能是一段领导需要传达的对话,可能是自己或者亲人或者客户的一个银行转账卡号,可能是懒得打字直接从哪复制,粘贴进入搜索引擎的一个搜索关键词。。。但这些信息都非常personal,往往复制和粘贴之间时间非常短,但粘贴之后,用户对于这段信息的期待是什么?就是除非我再粘贴,这东西就不应该再出现了,起码这个是从剪贴板被发明起就没有变化过的体验。但我们也不应该忘记,复制进入剪贴板行为是个偶发行为,剪贴板里的内容大多都是几个小时前、甚至几天前的内容;至少现在剪贴板还没有expire和判断时长的可能,所以请考虑这个场景: 我打开一个小程序给我朋友看某个有意思的页面,结果打开这个小程序时,跳出来了一个对话框,里面是我三天前复制粘贴进百度搜索的某个药品名称。。。。这是一个在任何情况下都不可被接受的场景。把这个问题换一个问法,微信小程序的产品经理,当您要求小程序只有用户授权才能操作剪贴板的时候,用户有授权微信展示他剪贴板内容在屏幕上过么?甚至在授权本机号码我们都会加几个****,PC上退出photoshop会提示“剪贴板里还有大量数据……”而不是把内容画在屏幕上, 为什么在这里展示剪贴板内容时候如此激进?难道都不是隐私内容么?这个内容足够隐私到小程序必须获取权限来获得机器判断的可能,但不隐私到可以暴露在屏幕上每次进入小程序都展示一次。。。。这是如何的自相矛盾。
即使授权,需要每次使用都弹窗么?
这点其他帖子也提到了,原因显而易见。一般需要读取剪贴板的应用场景基本都是在逻辑主干上判断是否剪贴板里是一个特定会影响应用行为的数据。这个必须读了才知道,可能产品经理是想这个判断权放到用户手里,自己看看这个数据要不要给小程序读取?但这个现实么?另外每次都让用户判断的成本有多大?另外一些场景里,剪贴板内容可能也是由应用写入,用户理解不了,还是微信就是想消灭掉应用中使用剪贴板通信的可能?既然如此何必开放这个API?
我们作为小程序研发者,公司可能整个业务都放在上面(以我们为例,我们没有h5,没有app,小程序是我们唯一的端) 几十个弟兄上上下下青春和财务都依赖微信生态,我们初心也简单,第一信任腾讯,第二相信小程序是解决我们业务场景的最佳不二选择,所以才这样没有backup的上。过往也会碰到各种bug和变动,但这一次,说实话伤害到了信任。这次提的4个问题,第1个问题,就跟昨天帖子里说的那样,这样不对,我们认为贵团队应该我们一个必要的说法。大家都是做研发,文档准确的重要性不言而喻不可儿戏。 第2,3,4问题,是我们坚持认为这个设计是一个错误,从我们狭隘的见识中,还看不到合理化解释的任何可能。这两点,真的只能说很遗憾。
api这个更新不通知,文档有问题没变化,这个真是太坑了。我这就有一个例子,趁着官方在搭车就想问下官方。这里的文档不改是想留着以后支持呢,还是忘记改了呢。
https://developers.weixin.qq.com/blogdetail?action=get_post_info&lang=zh_CN&token=626128128&docid=00004ad5db82c002c5463c8cc56000
扎心了老铁
支持下 走心了老铁
那好吧,历史遗留问题就算了
@这都申请了 关于require的问题,这个第一个版本就不支持了,确实是设计上的问题导致的历史包袱,即使修复了也存在版本兼容的问题,导致现在挺难更改了。这个我们也有关注到,也希望能够尽快解决,感谢你的反馈!
顶你
那我就反馈一个,这个问题到底是不是bug呢?还是说就是这么规定的不会改了? @Pipin小平
这次的更新因为没有提前告知开发者,给各位带来了困扰,在这里我代表小程序团队向各位热心的开发者表示深深的歉意,我们日后会完善更新流程。同时感谢您真诚的建议,这对我们来说是非常真实、有价值的用户反馈,我们会综合各位开发者的建议,尽快改善产品设计上的不足。再次感谢各位的积极参与和贡献,请各位开发者放心,我们做的一切都是为了让小程序生态变得更好,正因为目前还存在很多问题,也欢迎大家在我们的社区反馈问题,我们会阅读每一条反馈,并尽我们所能的去解决问题。谢谢!
社区中的工作人员总有态度不端正的,明明一个问题提供了相关必要的信息,比如微信版本号,系统及版本的什么的,还是一上来就问微信版本号,系统,再加代码片段....就很奇怪,难道是机器人在自动回复吗?就不能先看我们提出的问题吗?
更可怕的是:如果相关问题无法或者没必要提供代码片段,那么这个没提供代码片段的问题就会被置之不理了....这明明是一种推辞的做法
小程序团队上点心啊,别划了
mark,保持关注