On Tuesday 06 Aug 2013 00:01:43 Robert Hailey wrote: > > On 2013/08/05 (Aug), at 5:28 PM, Matthew Toseland wrote: > > >> There might be a stat we can collect in this respect.... IMO, we should > >> have a timer that fires if a node has not been initialized after N days (1 > >> day? 2?) that makes a HTTP request to the server saying, "I'm running, but > >> lost"... maybe reporting how many (if any) wizard screens they got > >> through, esp number of FProxy requests (did they even hit the first > >> screen!). > > > > If it was downloaded via Tor or via filesharing etc then it would need to > > know that so that it could not report in. IMHO we need explicit informed > > consent here.
This is an important point: They did not necessarily download Freenet from our website, they did not necessarily intend to enable opennet. > > While I certainly understand your perspective (maybe even that of our "target > audience"), I disagree. > > What we are trying to do here is diagnose an unknown failure case, and it is > already the case that our "target audience" (that would appreciate the app > not phoning home) can generally get Freenet up & running. > > IMO, it is enough that: > * the delay be long enough that even a "mild geek" would get it working > before such a time (or the time to setup a darknet connection?), > * the "most personal" info transmitted be IP address (unavoidable) and System > type (which platform is broken?) > * the transport be HTTPS > > To add explicit consent only adds an additional step they might get lost at > (or balk at). > > > Maybe a checkbox at the beginning of the installation process - before even > > installing Java? > > > > Only a handful of users will tick it, but stats from them would be useful. > > > > [ x ] Tell the Freenet Project how the installation went (warning this will > > make an encrypted connection to our server freenetproject.org). > > How about avoiding the scary words, default to true (they already d/l it from > our server, right?) thusly: > > [x] Report installation failures over HTTPS No way. Explicit, prior, informed consent. We don't need feedback for every install. We only need feedback for a representative sample. That limits the risk of scaring people away. > > > Or better ... have a 10% chance of asking the user explicitly: > > > > Do you want to help us to improve Freenet? If you click yes, the Freenet > > installer will tell us whether your install of Freenet succeeded, and if it > > failed then at what point it failed. No other information is sent to us, > > but as a bunch of geeks who mostly use Linux, this is very useful > > information! Only click Yes if you downloaded Freenet from our website. > > Which (to the user) roughly translates to: > > Would you like to help us improve Freenet? If you click yes, [.... ugghh, a > paragraph?? I have to read? How do I get to the pictures??...] This is patronising. People do read. Most people have a fairly advanced reading age. What makes their face glaze over is a long paragraph of deeply technical text that doesn't make any sense. Which is what we need to avoid. > > > There are lots of possibilites: > > - Ran away before running the installer. Due to AV warnings or lack of > > signature. > > - User runs away when realises need to install Java. > > - User runs away while installing Java (it can take a while and doesn't > > always show much on screen, can assume it's borked and cancel). > > - Problems installing Java. > > I didn't think about this one.... I wonder if there are common corporate > policies against installing java. > > > - Problems installing Freenet. > > - Didn't see the rabbit icon / didn't try it. > > - Didn't complete the wizard - at what stage did they drop out? > > > > How can we distinguish between them? AFAICS a feedback mode is the obvious > > way to do this. > > I agree.... unless you mean a "please tell us why your leaving the installer" > sorta feedback system. > > ... but it sounds like we might need two nearly identical mechanisms. One for > installation failure, another for installed-but-not-initialized. Closely related mechanisms.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
