1. iPhone 有什么理由禁止用户自行安装 app?
在目前来说,一个不越狱的手机,仅凭 app 声明索要的权限能作恶的程度被极大限制了
但苹果仍然禁止用户自行安装应用,必须只能通过 app store,当然这样给公司带来的极大的利润,但是不是有些不够极客?
苹果这样做除了为利润考虑,还有哪些原因?
在你所畅想的未来:
苹果是否会开放,允许非官方商店的应用安装
还是安卓会变为今天的苹果,禁止所有非官方商店的应用安装?
18 篇热帖
几年前看电影 《遗愿清单》后,断断续续记录了几条,今天突然想起来了。马上而立,一条还没有做过。
最近感觉 iOS 下的淘宝越来越难用了,进入店铺后 item 经常出现点击没反应的情况。不知道你们遇到过没有。
而且最近观察周围的人发现拼弟弟的使用频率越来越高了,阿里人要保持焦虑啊[狗头]
本人是做科学计算的,简单来说就是解几百万几千万的大型稀疏矩阵。计算的性质决定了 Cache 命中率不会高。实际使用中,CPU 几乎很难达到瓶颈,运行速度基本与系统总内存带宽成正比。
最近在用超算的时候发现一个非常棘手的问题:内存带宽抢不过那些炼丹的。例如一台双路服务器有 24 个核,实际分配是 22 个核心给 CPU 任务,2 个核心给 GPU 任务。然而炼丹的抢内存带宽效率奇高。假如那台服务器碰巧有人在炼丹,我的计算速度几乎会减半,也就是说我用 22 个核心抢占内存带宽的速度和炼丹的 2 个核心差不多。但是超算的“价格”是按 CPU 核心 x 时间计算的,我消耗了 22 份的资源却只得到了 12 份的性能,实在是不太公平。
我这里没有贬低炼丹的意思,GPU 计算本身没有问题,我只是想提升自己程序抢占内存带宽的能力,得到我付出的“价格”应得的性能。
亲戚推的也不好拒绝,这次相亲是表姐夫的表妹,是不是有点奇怪, 都是你好过去 ,你好过来, 然后没共同话题啊, 难受!!!
最近站内各种刷王伟,因为不想在主页看到相关关键词的主题,写了一个脚本,当然也可以屏蔽一些其他关键词主题
// ==UserScript==
// @name V2EX filter
// @include https://v2ex.com/*
// @include https://www.v2ex.com/*
// @require https://code.jquery.com/jquery-3.4.1.min.js
// ==/UserScript==
//屏蔽对包含关键字主题
$("a.topic-link:contains('王伟')").parent().parent().parent().parent().parent().parent().hide()
一个 28g 的资源,迅雷非会员提示排队次数用完了,云盘倒是秒存,但是下载的速度也只有 300k 。拿出封存已久的玩客云,顺利下载,速度有 3m 左右。好奇用 qb 尝试一下,我去!直接拉满带宽。
感觉玩客云是故意限速,迅雷是卡着让你交钱,qb 虽然平时并不稳,尤其是冷门资源根本下不动,但是能给多少就给多少。京东转了一圈: 拯救者 R7000:4800x+2060=7999 机械革命 4800x+3060=7799 (无货) 华硕天选 5800x+3060=8299 (无货)
颜值还是站拯救者,不过现在这个性价比... 现在买感觉坑,不过我的 3 代 i7+GT750 已经垂垂老矣了。 [叹气]还是太穷了
Touchpad 已有,magic mouse 难用不考虑。 罗技 M590 蓝牙连结又很不稳,经常卡死。
二线城市,年后的需求一个跟着一个,一眼望不到头,早上 8 点上班,每天都要加班都 10 点,最近半个月晚上睡不着。也吃不下去东西,感觉得了焦虑症了。。。一直在纠结要不要辞职,不辞职怕这种情况会一直延续,辞职的话又怕从一个坑跑到另一个坑里
假如一个产品包含 H5 端、小程序、APP 端三端。 小厂为了方便,肯定三端会有一些公用的接口,那么自定义协议之类的肯定不能用,还得用 http 协议
那么问题来了,https 通过本地抓包的方式,还是能解析你接口里面的内容。为了防止别人爬你数据,脱机请求你接口。API 的安全其实是非常重要的。对此 我有如下想法,不知道大家有无更好的 idea
首先分两步,h5 、小程序只允许比如微信授权登录的用户进行操作,接口可以不加密,但是用户的登录凭证不要设置太长。
第二步 APP 在用户启动的时候进行一种密钥交换算法,通过后端动态安全的下发密钥。可以参考 Diffie-Hellman 算法 第二步,APP 后续与服务端通信的核心接口全走 aes-256 之类的对称加密方式传 sign 值给服务端,为了防止别人能够重放攻击,可以考虑 APP 与服务端维持一个长链,动态推送时间戳之类的方式,保证每次就算请求参数一样,加密出的 sign 值也是不一样的。
但是问题来了,密钥交换的时候如果别人猜出你的交换算法,也有可能导致中间人攻击,所以可以考虑 APP 内置一个 rsa 的公钥(不知道有无更好的方案)。 当然 APP 需要把这些东西封装成.so 文件,然后 APP 包再用付费的方式加固。这样应该能拦住百分之 99 的脚本小子了。
最后再加上一些实时的行为风控。比如用户访问过于频繁 或者浏览的内容超过正常人的量,可以动态的弹出图形验证码之类的做校验