Application usage statistics and targeted user surveys
vkrause at kde.org
Thu May 25 11:08:28 BST 2017
On Friday, 12 May 2017 00:05:59 CEST Albert Astals Cid wrote:
> El dimarts, 2 de maig de 2017, a les 19:58:05 CEST, Volker Krause va
> > On Tuesday, 2 May 2017 00:07:43 CEST Albert Astals Cid wrote:
> > > El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va
> > > Should submissionInterval and encouragementInterval also be a property
> > > in
> > > Provider?
> > I only added properties needed for a QML configuration user interface so
> > far, but if someone wants to do the entire setup in QML it probably makes
> > sense to expose the entire API indeed.
> +1 i think we should start thinking more in "which are the qproperties that
> make sense to expose" instead of the "what are the ones that i actually
> Though i guess adding new qproporties is abi and api compatible it's always
> nice if someone that has other needs doesn't need to add the qproperty at a
> later stage.
Done, and Aleix added properties for SurveyInfo, so we are getting closer to
full QML usability, with Discover being the guinea pig for that.
> > > I see you protected the data on the server with a user/password.
> > It's protecting both read access on the data and write access on product
> > configuration and survey campaigns, yes. It would probably make sense to
> > separate those two interfaces, and thus also enabling different access
> > control for data analysis and product/campaign management.
> +1, i'd like at least a "read" and an "admin" privilege separation, if i
> understand we plan to run this as a "KDE-wide service".
That's implemented now.
> > > If the data is really anonymous do we really need user/password ?
> > Good point, I would also argue that for building trust in such a system
> > the
> > data must be public. However, there are two reasons that still made me
> > protect it:
> > (1) if it's world-readable the fact that it is essentially world-writable
> > (see above problem with submitting wrong data) makes this easily
> > exploitable for spreading links to illegal content, same as e.g. our
> > pastebin was abused.
> Apply the same solution we made for pastebin? i.e. i think you need an
> identity account now?
Right, which should now be doable with the option of having read-only access
to the data.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel