We will be including crash reporting soon. The way it will work is that when a crash (“panic” usually, in Go parlance) is detected the Syncthing version and backtrace is reported to some server, where it’s stored and aggregated. The data that will be sent looks like this:
07:48:24 INFO: syncthing v1.1.4 "Erbium Earthworm" (go1.12.5 darwin-amd64) firstname.lastname@example.org 2019-05-21 20:36:38 UTC Panic at 2019-05-22T07:48:25+02:00 panic: interface conversion: *pfilter.FilteredConn is not net.Conn: missing method Read goroutine 106 [running]: github.com/syncthing/syncthing/lib/connections.(*quicListener).Serve(0xc000158000) github.com/syncthing/syncthing/lib/connections/quic_listen.go:74 +0x41b github.com/thejerf/suture.(*Supervisor).runService.func1(0xc0001c6690, 0xc000000000, 0x54b4728, 0xc000158000) email@example.com+incompatible/supervisor.go:600 +0x47 created by github.com/thejerf/suture.(*Supervisor).runService firstname.lastname@example.org+incompatible/supervisor.go:588 +0x5b ... more of same gibberish
That is, it does not include any log data, user or other metadata, nor the ID of the sending machine. Excluding that data makes it somewhat less valuable for us, but I think we’ll be OK.
All in all this means sending us less data than global discovery does, which is a feature that is enabled by default. Given that, how do you reason around having this enabled by default or not? Not having it enabled by default means we will lose lots of panic reports, so will be less likely to fix those bugs.
- Enabled by default is fine; the very privacy conscious can disable it like they must global discovery
- No, this must be explicitly opt-in, because …
Feel free to explain your thinking below.