299472 - Add optional instrumentation code

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, enhancement)

Description

[James Ross]

It has been suggested a few times recentlly (including by myself) that an
instrumented version of ChatZilla that sent usage details back to us (after
asking the user on first start, of course!) could provide a valuable insight
into how users do things, and what things they just don't use. They could also
have an option to send simple comments about missing things, perhaps.

There are some big issues, however. First, should this be built-in to the source
(and enabled via a JS constant in static.js or similar, so two builds could be
made - one normal, the other instrumented), or should it be a plugin that just
adds lots of hooks and stuff?

Then comes the issues of how to get data back... XMLHttpRequest + POST to
webserver? Who's webserver? Ask the user to e-mail a log file? (not automatic
enough IMHO)

Finally, there is the small matter of exactly what gets logged. I would presume
all actions (opening a menu, sending a command, pressing keys like Page Down),
but that can easily get busy. Perhaps just commands run (and how they were
activated)?

Comment 1

[:Gijs (he/him)]

Attachment: [checked in] Patch to add startup ping instrumentation

This patch adds the startup ping instrumentation that went into ChatZilla 0.9.69.2 and newer releases.

Comment 2

[James Ross]

Attachment: [checked in] Add a 'source' to commands run from the menu

Comment 3

[James Ross]

Attachment: [checked in] Add source = "keyboard" for shortcut-activated commands

Comment 4

[James Ross]

Attachment: [checked in] Dispatch menus and default commands as interactive

This is the small adjustment Gijs and I talked about on #chatzilla recently; all methods of the user activating commands should set isInteractive to true. This patch fixes the two cases found where it was not set.

Comment 5

[:Gijs (he/him)]

Comment on attachment 310009 [details] [diff] [review]
[checked in] Dispatch menus and default commands as interactive

r=gijs

Comment 6

[James Ross]

Attachment: The Big One - dialog, code and localisation for CEIP

I believe I covered all the comments made about the code on IRC. The uploading has been tested and the default URL in prefs is correct and working. There are no major differences from the last version put into pastebin, just a few corrections for errors introduced when making the CEIP code be an instanciated object.

Notes on upload: the user's unique ID and the name of the log file are passed in the URL so that the server can do something reasonably smart with them; in particular, it will not accept the same UID+FID pair multiple times.

Comment 7

[:Gijs (he/him)]

Comment on attachment 319233 [details] [diff] [review]
The Big One - dialog, code and localisation for CEIP

Nit: I believe that in objects (notably log event objects) the CZ notation does not have a leading space before the first, or a trailing space after the last, property-value tuple. I could be wrong though.

Just one actual issue that I can see: you're claiming that we never send the arguments to commands, but you do check the pref names used with /.*-pref and the state passed to /log . I'm not sure what to do about this, but I thought I'd note this as it means this statement is not strictly accurate, as far as I'm concerned

r=me with some fix for that (don't log it, reword somehow, w/e)

Also, have we checked that this is OK per whatever rules we should abide by (from Mozilla or privacy laws somewhere that we care about, eg. the UK or the uni where your server is located)? I realize that we don't send anything personally identifiable, but all the same...

Comment 8

[:Gijs (he/him)]

To expand on my last note: we might be required, if this data is on your server, to remove it after N months, or something of the sort.

Comment 9

[James Ross]

Comment on attachment 319233 [details] [diff] [review]
The Big One - dialog, code and localisation for CEIP

I don't think we actually have an official style guideline for object literals, but I've changed the logEvent ones to have no spaces.

I've removed the code for away, attach, log and pref commands as it's too early in the day to figure out how to explain this in the dialog.

I've had a read through of the Data Protection Act 1998 and associated materials, and so long as I keep the data private it's basically fine. There didn't appear to be any time limit on the data, even personal data, in the act, but we could easily set a reasonable time of 12 months, say. Any user wishing to see or have their data removed is allowed given that right, and it's easy to comply with as the collector script stores the data by the random userid value.

Comment 10

[James Ross]

Checked in --> FIXED.