Hello all,

I just got a notification from the Caddy[1] project's GitHub page[2] that
the Caddy project is indeed going ahead with their plan to implement
telemetry into the server. As implemented (default on) [3] (search
"telemetry"), it exposes a rather terrifying amount of data including but
not limited to:

   - the number of vhosts you are serving
   - the version of Caddy
   - the number of TCP(/UDP?) listeners Caddy has open
   - the server type of Caddy (in case you compile in the DNS server option)
   - OS (linux, windows, etc)
   - Architecture (aarch64, ppc64, etc)
   - CPU brand name
   - Number of logical CPU cores
   - CPU AES-NI support
   - the number of configuration directives in the loaded configuration
   - how many connections are likely or not likely to be TLS-MITM-ed
   - its best guess if the user is running this in development or
   production based on what ACME servers Caddy is configured to use
   - the number of sites being served by Caddy
   - how many hits from how many unique user agents Cadey processes
   - the number of HTTP requests Caddy processes
   - the number of TLS certs Caddy manages
   - the number of TLS certs that Caddy manually loads from files
   - the number of TLS certs obtained from an ACME server
   - the number of TLS certs renewed from an ACME server
   - the number of TLS certs revoked from an ACME server
   - TLS client hello information [4] (this isn't implemented yet, but they
   obviously plan to)
   - TLS handshake count
   - TLS handshake unique error count
   - the number of managed TLS certs currently loaded into ram
   - the number of manually loaded TLS certs currently loaded into ram
   - the number of self-signed certs Caddy is configured to generate in ram

This seems a bit much for opt-out telemetry, and made me wonder if Alpine
has any policies about packages with telemetry features in general. If so,
what are they? If not, I think it would be reasonable for telemetry in
alpine programs to be OPT-IN (as in: the user MUST take action to enable
telemetry) or patched out from programs.

---

Christine Dodrill
https://christine.website

[1]: https://caddyserver.com/
[2]: https://github.com/mholt/caddy/pull/2079
[3]: https://github.com/mholt/caddy/pull/2079/files
[4]:
https://github.com/mholt/caddy/blob/52316952a575b01871224e68d4d248c0e2cdf271/caddytls/handshake.go#L103

On Fri, 23 Mar 2018 02:16:28 +0000
Christine Dodrill <shadow.h511@gmail.com> wrote:

> Hello all,
> 
> I just got a notification from the Caddy[1] project's GitHub page[2] that
> the Caddy project is indeed going ahead with their plan to implement
> telemetry into the server. As implemented (default on) [3] (search
> "telemetry"), it exposes a rather terrifying amount of data including but
> not limited to:
> 
>    - the number of vhosts you are serving
>    - the version of Caddy
>    - the number of TCP(/UDP?) listeners Caddy has open
>    - the server type of Caddy (in case you compile in the DNS server option)
>    - OS (linux, windows, etc)
>    - Architecture (aarch64, ppc64, etc)
>    - CPU brand name
>    - Number of logical CPU cores
>    - CPU AES-NI support
>    - the number of configuration directives in the loaded configuration
>    - how many connections are likely or not likely to be TLS-MITM-ed
>    - its best guess if the user is running this in development or
>    production based on what ACME servers Caddy is configured to use
>    - the number of sites being served by Caddy
>    - how many hits from how many unique user agents Cadey processes
>    - the number of HTTP requests Caddy processes
>    - the number of TLS certs Caddy manages
>    - the number of TLS certs that Caddy manually loads from files
>    - the number of TLS certs obtained from an ACME server
>    - the number of TLS certs renewed from an ACME server
>    - the number of TLS certs revoked from an ACME server
>    - TLS client hello information [4] (this isn't implemented yet, but they
>    obviously plan to)
>    - TLS handshake count
>    - TLS handshake unique error count
>    - the number of managed TLS certs currently loaded into ram
>    - the number of manually loaded TLS certs currently loaded into ram
>    - the number of self-signed certs Caddy is configured to generate in ram
> 
> This seems a bit much for opt-out telemetry, and made me wonder if Alpine
> has any policies about packages with telemetry features in general. If so,
> what are they? If not, I think it would be reasonable for telemetry in
> alpine programs to be OPT-IN (as in: the user MUST take action to enable
> telemetry) or patched out from programs.

We don't have any written policies about this, but I would prefer that
this kind of thing is an opt-in, and I would be be ok to apply an
Alpine specific patch to disable telemetry by default.

-nc

> 
> ---
> 
> Christine Dodrill
> https://christine.website
> 
> [1]: https://caddyserver.com/
> [2]: https://github.com/mholt/caddy/pull/2079
> [3]: https://github.com/mholt/caddy/pull/2079/files
> [4]:
> https://github.com/mholt/caddy/blob/52316952a575b01871224e68d4d248c0e2cdf271/caddytls/handshake.go#L103



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---