@chengluyu #2 如果你仔细看了文章，你会发现有一个 bug 阻碍了扩容之后继续同步。

@ddugujiujian #3 有很多 workaround bug 的方法，比如提供 reset iCloud 存储的方法，比如提供更快 purge Messages in iCloud 的方法。

菜市场常见的计算器（市面上最常见的计算器）是这样工作的。

https://binged.it/2Dsu9UR

@CitizenR #6 这个哲学问题是测试之后提出的。

在 Edge 和 Internet Explorer 上并不存在这个问题，所以出问题的不是 (Microsoft) Windows，而是 (Google) Chrome。如果题目改成“ Chrome 专坑别的平台”，那么是在说 Google 用 Chrome 坑 Microsoft Windows ；如果题目改成“ YouTube 专坑别的平台”，这似乎并不是很成立。

不过哲学问题的表述似乎不太准确。我认为这里是 YouTube 坑了 Google Chrome，而不是 YouTube/Chrome 坑了 Windows。
Windows on its own 并不 suffer 这个问题，Google 是自家人打自家人了。

哲学问题：Chrome on Windows 到底算是 Google 的平台还是 Microsoft 的平台呢？

你可以使用 Windows Server，支持同时有多个活动的远程会话。

理论上你可以按照 RDP 的协议要求远程电脑建立一个活动的会话，但这个比较困难。

Component Object Model

https://stackoverflow.com/questions/441758/driving-excel-from-python-in-windows

如果你想识别任务栏所有的程序，你可以 follow Windows 的文档 https://docs.microsoft.com/en-us/windows/desktop/shell/taskbar#managing-taskbar-buttons

但是我强烈不建议你这样做，因为逻辑非常复杂，很难正确实现。

另一个方式是使用 Automation API，但是如何确保你目前在桌面上是个问题。

——————

或者不要重复造轮子，因为所有的 Windows 自带的软件都是可以键盘完成所有基本任务的（否则这是一个 accessibility bug，我觉得盲人基本上不会用鼠标）。

当然有些神奇的软件会做成完全不可访问的样子——比如微信。它的 accessibility 如此之差，令我怀疑他们是不是自己造了一个 windowless UI framework，但是完全没有实现 dialog navigation 和 automation peer。

@geelaw #19

> 换成密码学更容易理解，加密是为了不需要保证没人窃听，而是有人窃听也可以。

应该是

> 换成密码学更容易理解，加密是为了不需要保证没人窃听，即使有人窃听也不会有什么损失。

@chenchangjv #18

> 我对您的问题的理解，就是用户上传了多维数据，通过多维数据的联合可以得到更多的信息量。

正确。

> Apple 有明确说明会把所有的数据聚合在一起去做用户画像吗？

隐私研究的目的是从数学或计算资源上保证坏事不会发生，而不是依靠信任。我没说 Apple 要去把数据合起来做画像，我甚至没说 Apple 要做任何画像。

你去考虑 Apple 是否值得信任、是否会做这件事，是完全背离该项研究的——这研究的目的是为了让人不需要考虑这个问题。

换成密码学更容易理解，加密是为了不需要保证没人窃听，而是有人窃听也可以。

> 在 Apple 描绘的应用差分隐私的场景中，每一个独立的 database 都是符合差分隐私的吧？

Apple 的文档里每个内容都是符合 DP 的，我的点在于这样的参数选取不带来实际的隐私保证。

> 如果我理解的没有问题，那么这能发生并不是差分隐私的问题。Apple 能够达到您所说的攻击的前提是能够将同一用户的不同维度数据聚合起来，这是因为她拥有差分隐私所要发布的信息以外的内容。

并不是，只是 DP 的参数选取问题。

> 我目前在做的只是差分隐私下的一些复杂数据的处理，在差分的缺陷方面无法帮助您。

我没有寻求你的帮助。

> 我无法理解您计算出隐私参数的问题，隐私参数一般是人为指定的，使用例如 Lap （ privacy param ）等方式加噪音到数据上。

你真的不是看了 Laplace mechanism 之后背公式吗？

数据库 curator 的模型下，形式化的表述是这样的：若 D 是一个数据库，F, G 分别是 D 上的 a/b-diff. priv. mechanism，则 (f, g) 是 (a+b)-diff. priv. 的。

这个命题 **并没有** 说 (f, g) 不是 (a+b-1)-diff. priv. 的。我不能理解这么一个简单的不等式放缩为什么会有问题。

再用向量举例子：u, v 的长度都是 1，这相当于你选择每个你支持的 query 的时候 priv. param. 是 1 ；接着你把 u 和 v 相加，在不引入其他条件下我们能说的最准确的话是“ u+v 的长度不超过 2 ”，但这不代表 u+v 的长度不可以是 1.1 ；同理，当你 compose 两个 priv. param. 是 1 的 mechanisms 之后，你得到的是一个 2-diff. priv. 的 mechanism，但这不代表这个新的 mechanism 一定不是 1.1-diff. priv.。

如果你有一个 1-diff. priv. 的 mechanism，它当然也是 2-diff. priv. 的。

@chenchangjv #14 你的话前后矛盾。

> Local DP （ LDP ） 不存在可信的第三方，用户上传的就是被干扰的数据。

> 你说的不信任 Apple 是差分隐私规则以外的问题。

我的讨论假设 Apple 对于数据噪音化的操作是正确实现的，考虑的是用户面对收到数据的 Apple 的隐私问题。

“每个维度泄露的隐私”没有变大，但是“所有维度总体泄露的隐私”是变化的了。因为你可以通过多个维度综合确定一个人。

比如，认为先验是 (0/1/2, 0/1/2) 九种等可能，如果你知道第一个维度的分布应该改变为 7/18 7/18 2/9，则这导致 1.5 倍的概率变化，第二个维度的分布改变为 1/2 1/3 1/6，这导致了第二个维度上 2 倍的概率变化。

第一个维度的 pri. param. 是 log(1.5)，第二个维度的 pri. param. 是 log(2)。

这两个维度可以有相关性，DP 的论证是考虑最坏的 privacy guarantee。如果是独立的维度，联合分布里 (2, 2) 的可能变成了 1/27，概率的变化至少是 3 倍，pri. param. 是 log(3) = log(1.5) + log(2)。

注意：具体的分布和数据里面合成之后的 essential pri. param. 可能比相加要小，但是在一般（数学上的“一半”）情况下可以证明的最小的 pri. param. 是各个的和。

上面这个例子就是说我最开始的最后一句话：

> 而且理论上界和实际发生的隐私消耗也不一定很 match。

如果这个例子有点难想，你可以这么理解：考虑两个向量的和的长度，它不超过两个向量长度的和。

这里每个向量可以看作一个 pri. param.，“和”的操作可以理解为 composition。我们能做的是去证明这个 bound。但是对于具体的向量（也就是具体的噪音叠加），这个 bound 不一定是紧的。

@lekai63 #5 在没有微分隐私的时候你已经可以这样做了。

我个人并不知道 Apple 是否分析每个人的数据，而且本帖里面的数据 Apple 公开表示的作用是进行统计。而你的个人数据是很难撼动 Apple 得到的用户群体的统计数据的。

@ding259336 #7 在 Netflix + IMDb 和 Apple 的案例之间有一个更大的区别：

- 在 Netflix + IMDb 引出的 MSR 的论文里和教科书初次介绍 DP 的时候，持有数据库的实体是发布统计数据的，噪音是持有数据库的实体增加的，而贡献数据记录的个体是没有进行噪音处理的。防范的是查看统计数据的实体。
- 在 Apple 的使用里，噪音是个体加上去之后提交给 Apple 的。这类似于“抛硬币法调查运动员嗑药率”。连“调查员”都是防范的。

虽然 Apple 发布了一些用户群体的统计信息，但是这里的隐私模型最应该关注的是：个体的隐私不能泄露给 Apple。而不是：Apple 不能因为发布数据而泄露用户的隐私。前者是一个比后者强得多的条件。

另一个理解 Apple 模型的方式是把每个用户当成响应 query 的角色。

我之前把它们加起来的方式，现在我不知道对不对。因为这个模型的差异使我们需要重新考虑微分隐私的合成。

然而，从直觉上考虑，这里的 privacy budget 放在一起加起来 makes sense，因为 Apple 把单个用户的不同部分的数据拿来混合分析没有数学上的障碍（至于 Apple 发布的统计数据是分离计算的，只能说明查看 Apple 发布数据的实体应该以 parallel composition 来处理，但从 Apple 的角度仍然是 sequential composition ）。

这里的防范对象首先是 Apple 而不是查看 Apple 发布的数据的实体（当然，防范了 Apple 自然也就防范了任何查看 Apple 发布数据的实体，因为隐私合成的缘故）。

Will look into that when I have time.

@chenchangjv #10 你需要注意：

> 我觉得每天的隐私预算上限在保护具体数据方面并不重要。

和

> ... 差分隐私的前提，是抹掉任何标志信息，即使是同一个用户上传的数据，在收集者那里理论上应该不具备判断的可能性。

是矛盾的。或者后面这一句本身 doesn't mean anything. 因为微分隐私“抹去的程度”是 priv. param. 决定的。

如果你只是想说用户发给 Apple 数据的时候不包括任何 PII，这件事情本身和 DP 没关系。我谈论的是 Apple 使用 DP **带来的** 隐私的多寡，抹除 PII 的贡献自然不能算在里面。

@geelaw #11 BTW 带自己的手机几乎总是一个好的解决方法。

取决于你的隐私要求。

如果你不想让公司知道你访问了这些网站，不要使用。
如果你不想让公司知道你的内容等，但允许公司知道你曾经访问过这些网站，用 InPrivate + HTTPS。

使用 VPN 等自己的服务违反规定的风险比较大。

@ding259336 #1 DP 介绍系列的第一个例子就是 Netflix+IMDb 的匹配，同一个群体（那个例子里是公众，这个例子里是 Apple ）掌握的数据库应该看成一个，隐私消耗需要合并计算。

至于你认为 cost 已经足够小，我说了准确性和隐私之间自带 trade-off。这里的点在于，Apple 的实现没有提供特别有意义的隐私。

@passerbytiny 转发不是代收。在设置里面可以设置自动转发（ Start forwarding ）。

@geelaw #17 呃，不对，还有一个方向的问题。那应该提醒楼主 #8 第一行和第二行的“树”不是同一个概念。

@zealot0630 #8 “没有分杈”是有根树才有的概念，你想说的是“度为 1 的节点不超过两个”。

@glues #14 这个场景里并没有 adversarially chosen strings，MD5 属于一种随意的选择。

回到楼主的问题，如果你把 hash 函数建模为 random oracle，输出长度是 k bits 时，在 2^(k/2) 个 strings 时有常数概率碰撞。一般希望碰撞概率是 negligible，所以可以设置

k = w(log t) + 2 log N

其中 N 是数据的个数，t 是安全参数，w 表示严格高阶无穷大。

就是你怎么想、观察、对待一个对象。

举例：二叉树是一种层次对象，不会因为你用数组实现了一个满二叉树就变成了线性表。