Application usage statistics and targeted user surveys

[Volker Krause]

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 
escriure:
> > 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
> need".
> 
> 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.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20170525/7193b92f/attachment.sig>