Use CENSUS and ask the users to opt-in, or use a new UMSP_CENSUS option and allow users to opt-out?

Yes, we need to respect the user privacy, even if it will cost us in precision

6

21%

Use CENSUS option and each plugin developer who is interested in stats should ask the users, as a courtesy to enable CENSUS in order to get stats data.

6

21%

No, we need to know what plugins are used, and data is being anonymized anyway.

8

29%

Use a new UMSP_CENSUS option and have it on by default. Instruct users in the firmware release notes to disable it if they don't agree with the data being collected. The cost in storage is a new conf variable.

I agree that CENSUS is not on on nearly enough systems, which would skew any statistics.

How about this, then: don't use CENSUS, but introduce a new option, that is ON by default, specific for UMSP stats. If the users want out, they can configure it to say so. If they don't care, then we get the info we like.

We could add this option under UMSP in WEC. We can call it UMSP_CENSUS.

mad_ady wrote:I agree that CENSUS is not on on nearly enough systems, which would skew any statistics.

How about this, then: don't use CENSUS, but introduce a new option, that is ON by default, specific for UMSP stats. If the users want out, they can configure it to say so. If they don't care, then we get the info we like.

We could add this option under UMSP in WEC. We can call it UMSP_CENSUS.

Shall I change the poll?

that may be the acceptable medium

I think the data is worth very little at only 20% CENSUS useage

if we do collect data, users must have the ability to opt-out

if we provide a default enabled with an option to opt-outwe'll still get some people cry foul because default is enabled

but it may be the best compromise solution available

KAD

If you like my work please consider a Donation. DonatePlease read the appropriate documentation before posting questions! READ MEFAQWIKIPM's are for private matters. Post support questions to the appropriate forum, or they will be ignored.

Why can't 20% of the users not be representable? What do you think statistic companies use for calculating who becomes president or how much viewers a television-show had... 20% is very very much in statistics. Just multiply the results by 5 and I can't imagine the results differ 10% from the truth.

We have no clue if the users with CENSUS enabled are 20%, 50%, 1% or 0.1%.Also, people who tend to leave CENSUS=ON are people who better understand open source and the need for communication inside a community. Also, the only benefit of census was the online-update for users who had donated. The average person who installs a custom firmware and has problems enabling moviesheets will probably never enable CENSUS.

Perhaps b-rad has a better idea of how many users have enabled census...

I see the poll results favor the UMSP_CENSUS option being on by default.I have implemented this and it works quite well. I am ready to merge my changes in the repository, but before I do this, I need the following questions answered (by a wdlxtv dev):

1. Where should I send the census data to? Should it be fwup.wdlxtv.com like the other census data?2. Who can approve and upload the server-side code? I have a perl UDP listener, a mysql database, and an aggregation script (perl as well). Also, there is a web interface to display results (php + mysql + extjs). Once all bits are in place, I can test them further, but I need somebody with access to that server to be my remote hands. Apart from this I have a small UMSP patch to enable sending census data + webend option to disable it.

Te results web interface took some days of tinkering to get working, but it looks nice (some images with fake data):The main view - top plugins in the current month:Plugin usage - select plugin:Select time interval:Plugin usage per time:

I do not understand why you need a Сensus to collect statistics of plugins usage?Сensus, as I understand it, is tied to the use of personal serial number. And what for need to know serial number of the user (activate the Сensus), if you want to monitor only the total number of plugin downloads with no personalization?

(P.S. more points in vote for "No, we need to know what plugins are used, and data is being anonymized anyway." - its just wrong counting its duplicate 3. and 4. item check it it happen after editing the poll )

The goal is for UMSP plugin developers to know if their plugins are used/popular. This way they can choose to invest more or less time in a specific plugin. Also, regular users can see what plugins are popular and maybe discover new content (there will be a link to the graphs in the webend)...

This approach does not count how many times a plugin has been downloaded. This could have been done directly on the plugin server, without any user interference. It actually measures if a user accessed a specific plugin at some point in time. When the user selects the plugin from the OSD and enters the plugin's main menu, a UDP packet is sent to the census server containing the following data:

The md5 hash of the serial number is something that is done to ensure that a plugin is only counted once per day for a user. Even if the user's device generates the same packet every time it enters the plugin's main menu, the database will only record it once based on this hash. It doesn't have to be an md5 of the SN, it can also be an md5 of the eth0 MAC address, for instance. It just needs to be unique per device. I'm open for suggestions on this...

In terms of security/data integrity, the server doesn't get the actual serial number (and I doubt you can easily use rainbow tables to deduce it...). A problem that isn't addressed is an attacker could generate fake census data by pushing UDP packets to the server, to influence results. I hope this will not be the case, and the data isn't crucial to the project, but it's nice to have.

The reason for my proposed UMSP_CENSUS option to be on by default is to take advantage of users who will not care and leave it on. As I said, a packet is sent only when accessing a plugin through the OSD and one can assume that the user has visited the webend to enable and configure the plugin, so it's fair to say he has seen the option. Anyway, it will be stated in the firmware changelog that this type of data is collected automatically, and the user can opt out if he is concerned.