Ubuntu – What data are transmitted to Canonical for livepatch

canonicalcanonical-livepatchtelemetry

I just upgraded to 18.04 and wanted to try out livepatch. After reading the Livepatch Terms of Service web page (https://www.ubuntu.com/legal/terms-and-policies/livepatch-terms-of-service) I wondered a bit about these two paragraphs in the personal data section:

We may also collect certain non-personally-identifiable information,
which is located on your computer. The information collected may
include statistics relating to how often data is transferred, and
performance metrics in relation to software and configuration. You
agree this information may be retained and used by Canonical.

Canonical may disclose any or all personal data and content you have
sent, posted or published if required to comply with applicable law or
the order or requirement of a court, administrative agency or other
governmental body. All other use of your personal data is subject to
the Privacy Policy.

I understand that, in order to do the live patching, Canonical needs to know some things about my system, like the kernel version. Also, through my SSO account and the token they know my email address and name.

So far so good. But I wonder what else Canonical needs to know about my system. The above text is vague about this. "Statistics" and "performance metrics" do not sound like they are necessary for the live patch service per se. Also, if those data are really "non-personally-identifiable", why Canonical is asking one paragraph later to agree that they may disclose them to administrative agencies or governmental bodies on request?

What are the data transmitted to Canonical, once and regularly? How can I investigate what is transmitted? How can I be sure it will not change suddenly to transmit more than I want?

This is a technical question. I do not want to discuss Canonical's TOS or legal issues. I really want a technical way to find what is transmitted before I sign up.

Best Answer

Given that the livepatch client is proprietary, I don't have a complete answer.

That said, the client (/snap/canonical-livepatch/*/canonical-livepatchd) is written in Go. Debugging with Delve, here's some information to start with:

(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),
    ],}

The fields in the status variable are:

  • Client Version
  • Machine ID (the value from /etc/machine-id)
  • Machine Token (Ubuntu One token?)
  • CPU Model and (OS?) Architecture
  • Last check time
  • Boot time (time taken to boot?)
  • Apply Time (?? - possibly, when the last update was applied?)
  • Uptime
  • List of Kernels

Boot time and Uptime could be considered to be included in statistics and performance metrics.

Again, this is a starting point. Make of it what you will, and hopefully somebody else can provide more definite information.

How can I be sure it will not change suddenly to transmit more than I want?

You can't. The source code isn't available, and snaps are automatically refreshed, IIRC.

Related Question