V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
这是一个专门讨论 idea 的地方。

每个人的时间,资源是有限的,有的时候你或许能够想到很多 idea,但是由于现实的限制,却并不是所有的 idea 都能够成为现实。

那这个时候,不妨可以把那些 idea 分享出来,启发别人。
agagega
V2EX  ›  奇思妙想

App 会不会收集那些不愿意给权限的用户,然后在其他方面区别对待?

  •  
  •   agagega · 2019-08-10 13:58:26 +08:00 · 3536 次点击
    这是一个创建于 1939 天前的主题,其中的信息可能已经有所发展或是发生改变。
    11 条回复    2019-08-12 10:59:26 +08:00
    Atsushi
        1
    Atsushi  
       2019-08-10 16:07:31 +08:00 via Android
    那就上个插件随机返回
    cjpjxjx
        2
    cjpjxjx  
       2019-08-10 16:39:24 +08:00
    不是直接拒绝服务吗
    agagega
        3
    agagega  
    OP
       2019-08-10 20:04:07 +08:00
    @cjpjxjx iOS 上的 App 多数不会这样,但也见过不给通讯录权限不让用的
    laozhoubuluo
        4
    laozhoubuluo  
       2019-08-10 22:08:24 +08:00   ❤️ 2
    所以一直希望 Android 添加虚拟权限的选项。
    比如阻止获取 IMEI,应用就拿到一个随机的,和应用相关的 IMEI。
    比如阻止获取短信,应用就拿到一个空的收件箱。
    比如阻止获取通讯录,应用就拿到一个空的通讯录。
    比如阻止获取照相 /录像权限,应用获取的摄像头就是一个静态视频提示。
    advocadowater
        5
    advocadowater  
       2019-08-10 22:23:40 +08:00 via Android
    还是高德直接,不给电话权限 app 就进不去
    azh7138m
        6
    azh7138m  
       2019-08-10 22:31:47 +08:00 via Android
    @laozhoubuluo 如果是 target Q 的话,IMEI 是拿不到的,不过 play 上的应用到 target Q 估计还得两年,目前还是得 root 后用 app ops 来阻止
    honeycomb
        7
    honeycomb  
       2019-08-11 11:38:45 +08:00 via Android
    @laozhoubuluo

    就 IMEI 来说,从 Android Q 开始谁都拿不到 IMEI 了(排除系统 priv 目录,以及少数个例,如拥有 sim 卡密钥签名的运营商软件,profile manager 应用),拿到电话权限也看不到 IMEI。

    至于一般意义上的返回随机数,dianne hackborn (这人是 Android 组的老员工,Android 的权限机制是她管的,最近在 reddit 的一次 ask me about everything 活动)的意思是,开发者最终总是能察觉到返回了的是随机内容 /空内容,所以它们不愿意做这件事。

    类似的,他们不愿意把 appops 暴露出来给一般用户使用也因为 appops 晦涩难懂。

    目前的 workaround 基本上可以覆盖绝大多数的场景了,appops 对付强要权限的,magisk+storage redirect 对付强要 storage 权限的。这样的话除了美团这种以外都能治。
    laozhoubuluo
        8
    laozhoubuluo  
       2019-08-11 14:14:34 +08:00
    @azh7138m
    @honeycomb

    IMEI 之前没了解到,这次了解了,感谢各位告知。

    另外我一直想说,target api (以下简称 ta )的向后兼容是很失败的。
    Google 角度:ta 不够高,因此我要按老版本逻辑提供服务,应用程序需要这个数据我就要求用户给,不给我就返回阻止,应用程序自己退出跟我没关系,反正是开发商写的 exit。
    我的角度:ta 不够高,至少要把决策权完全交给我,由我来决策操作系统应该如何告诉应用程序,是按照老版本逻辑返回阻止,还是在读取时返回一个空的 /随机的内容,在写入时提示我是写到沙箱还是写到真正通讯录,而不是说因为 ta 过低,我就必须全盘托出。

    magisk+storage redirect 是可以解决问题,但是解 bl、开 root 又是另一种风险源。

    个人观点:
    1. appops 可以稍微隐藏的深一点,因为 appops 确实晦涩难懂,但不删除,有正常入口应该是底线。
    2. ta 是一个能保证老程序运行的机制,不是一个破坏系统保护规则的漏洞。当隐私保护 /技术演进和 ta 向前兼容有冲突时,应优先考虑隐私保护 /技术演进。用户不允许写 storage 就默认 redirect,用户不允许获取地理位置就永远返回用户设定的地理位置。否则应用厂商永远不会升级 ta,因为 ta 低永远不影响程序运行,而且还能获得更多用户隐私。

    如果微软当年采用的是 ta 机制,我写个 DOS 程序覆写一下 0 地址,机器应该马上死机,但实际上提示的是应用程序不可写,要求用户退出程序(针对一般用户)或启动调试器调试程序(针对高级用户,系统的最终权限要给到用户)。

    既然 Android 现阶段做不到 iOS 的 level (大胆放弃向前兼容,全力维护用户隐私),那也请至少做到 Windows 的 level ( OS 决定不了的事情交给用户)。而不是说目前的开发商来个低 ta,系统就把我卖了。而且这种行为如果继续纵容下去,那在 Android 版本碎片化之后,应用 ta 会越来越碎片化。
    azh7138m
        9
    azh7138m  
       2019-08-11 14:40:36 +08:00
    @laozhoubuluo
    Android 更偏向开发者,这个很多人批判过了
    scoped storage 变为一个非默认选项就很糟糕,开发者反对声音太多了
    iOS 推广 idfa 也是花了好几年的吧,只是它做的早

    @honeycomb
    app ops 控制界面给去掉我也是没能理解他的逻辑,放到开发者选项里面不也挺好的
    honeycomb
        10
    honeycomb  
       2019-08-12 08:56:38 +08:00 via Android
    @azh7138m 有一小部分的 appops 以 special access 权限,开发者选项的方式暴露。

    就 scoped storage 来说,Google 目前不允许通过 appops override 应用自己的设定。你会看到用 appops 读取的时候有两个 legacy_storage,而 appops 只能改掉其中一个,另一个因为 manifest 而出现的无法更改。

    真是麻烦
    honeycomb
        11
    honeycomb  
       2019-08-12 10:59:26 +08:00 via Android
    @laozhoubuluo 只依靠 Google play 限制 ta 确实很不足,如果是在 iOS 上确实足够。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2618 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 11:28 · PVG 19:28 · LAX 03:28 · JFK 06:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.