哪些数据传输到Canonical进行实时补丁?


11

我刚刚升级到18.04,想尝试livepatch。在阅读《 Livepatch服务条款》网页(https://www.ubuntu.com/legal/terms-and-policies/livepatch-terms-of-service)之后,我对个人数据部分中的这两段感到有些疑惑:

我们还可能会收集您计算机上的某些非个人身份信息。收集的信息可以包括与数据传输频率有关的统计信息,以及与软件和配置有关的性能指标。您同意Canonical保留并使用此信息。

如果需要遵守适用法律或法院,行政机关或其他政府机构的命令或要求,Canonical可能会披露您已发送,发布或发布的任何或所有个人数据和内容。您对个人数据的所有其他使用均受隐私政策的约束。

我了解,为了进行实时修补,Canonical需要了解有关我的系统的一些信息,例如内核版本。另外,通过我的SSO帐户和令牌,他们知道我的电子邮件地址和名称。

到现在为止还挺好。但是我不知道Canonical还需要了解我的系统什么。上面的文字对此含糊不清。“统计信息”和“性能指标”听起来似乎不是实时补丁服务本身所必需的。此外,如果这些数据确实是“无法识别个人身份的”,那么为什么Canonical稍后要求一段落同意他们可以应要求将其披露给行政机构或政府机构?

一次定期发送给Canonical的数据是什么?我如何调查传播的内容?我如何确定传输更多的信号不会突然改变?

这是一个技术问题。我不是想讨论Canonical公司的服务条款或法律问题。我真的很想在注册之前找到一种技术方法来找到要传输的内容。


我认为livepatch可通过snapd来工作,这与Canonical对所有SSO,Launchpad,Snap存储库等使用的ToS /隐私策略相同……我认为snapd会传输诸如硬件信息之类的信息。

我猜想唯一可以确定的方法是将监视器放在您的Internet上传文件上,运行应用程序,然后查看监视器日志。当然,如果他们正在加密您的数据,那么他们上传的内容只会显示二进制garbaly-gook。
WinEunuuchs2Unix

Answers:


12

鉴于livepatch客户端是专有的,我没有完整的答案。

也就是说,客户端(/snap/canonical-livepatch/*/canonical-livepatchd)是用Go编写的。使用Delve进行调试,下面是一些信息:

(dlv) bt
0  0x00000000006ad140 in main.(*client).check
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:212
1  0x00000000006acfeb in main.(*client).Check
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:200
2  0x00000000006b8415 in main.refresh
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:60
3  0x00000000006bf957 in main.newDaemon.func1
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/daemon.go:76
4  0x00000000006b86a3 in main.(*refreshLoop).loop
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:120
5  0x00000000006c0bfd in main.(*service).Start.func1
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/service.go:151
6  0x0000000000457b31 in runtime.goexit
   at /home/c/.gobrew/versions/1.10/src/runtime/asm_amd64.s:2361
(dlv) locals
rendered.cap = 0
rendered.len = 0
rendered.ptr = *uint8 nil
status = main.ClientStatus {ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "",...+7 more}
(dlv) print status
main.ClientStatus {
    ClientVersion: "8.0.1",
    MachineId: "bfcf169468f641528ac653c41ff1797d",
    MachineToken: "",
    Architecture: "x86_64",
    CpuModel: "Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz",
    LastCheck: time.Time {
        wall: 0,
        ext: 0,
        loc: *time.Location nil,},
    BootTime: time.Time {
        wall: 0,
        ext: 63662149770,
        loc: *(*time.Location)(0x963f60),},
    ApplyTime: time.Time {
        wall: 0,
        ext: 0,
        loc: *time.Location nil,},
    Uptime: 3472,
    Kernels: []main.KernelStatus len: 1, cap: 1, [
        (*main.KernelStatus)(0xc4201883c0),
    ],}

status变量中的字段是:

  • 客户端版本
  • 机器ID(来自的值/etc/machine-id
  • 机器令牌(Ubuntu One令牌?)
  • CPU模型和(OS?)架构
  • 最后检查时间
  • 启动时间(启动时间?)
  • 应用时间(??-可能是何时应用上一次更新?)
  • 正常运行时间
  • 内核列表

引导时间和正常运行时间可以视为包含在统计信息和性能指标中。

同样,这是一个起点。随心所欲,并希望其他人可以提供更多确定的信息。

我如何确定传输更多的信号不会突然改变?

你不能 源代码不可用,快照会自动刷新,IIRC。


有趣的是,它在您的链接中说:“此ID唯一标识主机。应将其视为“机密”,并且不得在不受信任的环境(尤其是网络)中公开。我想知道如果我定期更改机器ID,livepatch是否可以继续工作。
塞巴斯蒂安·史塔克

@SebastianStark,因为livepatch对于社区最多可用于三个系统免费,我想它应该至少可以进行三个更改。不知道之后会发生什么。
muru

我想我永远不会知道,我想我的雇主也不会让我签署这份协议。
塞巴斯蒂安·史塔克

您可能不应该这么快就授予赏金。其他人在挖掘内部结构方面可能做得更好。
muru

你也许是对的。尽管我希望这里的人们不仅为(小)赏金而这样做。我认为这个问题非常重要。
塞巴斯蒂安·史塔克

3

我问佳能销售团队实时补丁服务传输什么数据。他们以此回信给我:

这是我们发送给客户的信息:

  • 来自/ etc / machine-id的机器ID
  • 来自livepatch服务器的机器令牌
  • 机器架构
  • 机器CPU型号
  • 客户上次更新时间
  • 系统何时启动
  • livepatch的上次应用时间是什么?
  • 当前系统正常运行时间
  • 内核版本

他们还提到他们还传输了一些统计数据,这些数据可能会随GDPR要求而变化。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.