Talk:ListenLog

From Project VRM
Jump to navigation Jump to search

Users Might Object

A potential concern with ListenLog is that end-users will perceive it as yet another mechanism for aggregating attention data that will (or at least could) be used by a third party that is unwarranted or used in an unwarranted fashion. There are four aspects of this concern, depending on how the LL concept is presented and implemented:

  1. Knee-jerk negative reaction to the concept of personal/attention data even being monitored in the first place. This reaction is prior to any consideration given to why and for whom the data might be used.
  2. Assumption that whenever personal data is captured, it is captured ultimately for a vendor's benefit, even if we are told otherwise. The default assumption is that data is stored and used by the vendor who is in control of the current user experience, e.g. whomever distributes this software application or hosts this website. The assumption might be that it is used by unwarranted vendor or that even if explicit permission is given, the data might be used in an unwarranted fashion (e.g. when you provide your phone number to a vendor who then later uses it to solicit you).
  3. Concern that even if the data is owned or controlled by us, it is captured and stored and might eventually be compromised, e.g. by a malicious 3rd party, oppressive government, legal body, etc. Since we intend to store the data remotely, this will aggravate the concern.
  4. Why would I choose to do this? Since LL will like have the ability to opt-in or opt-out, why would someone choose to collect their own data? What's in it for them? There will be built-in resistance without a compelling use case.

What might we do to address these concerns? Here are some suggestions I propose:

  1. Clear, careful presentation of the concept. This is unlike anything people will be familiar with and they will likely resist, misunderstand, or compare it to other negative things. A primary emphasis on previously unavailable user functionality might be a good approach.
  2. Store the data somewhere other than


Khopper 15:31, 2 February 2009 (UTC)