Gesendet: Mittwoch, 01. Februar 2017 um 08:16 Uhr
Von: "Daniel Wagner" <wagi(a)monom.org>
An: "Ingo Albrecht" <randomice(a)quantentunnel.de>
Cc: connman(a)lists.01.org, "'Marcel Holtmann'"
<marcel(a)holtmann.org>, "Slava Monich" <slava.monich(a)jolla.com>
Betreff: Re: [PATCH] service: Add EnableOnlineCheck config option
On 01/31/2017 08:29 PM, Ingo Albrecht wrote:
>> Hi Lukasz,
>> On 01/26/2017 06:51 PM, Lukasz Nowak wrote:
>>> From: Lukasz Nowak <lnowak at tycoint.com>
>>> Global config option, which allows to enable/disable (enabled by default)
>>> use of http get in wispr to transition a default service from READY to
>>> ONLINE state.
>> ./configure --disable-wispr
>> good enough?
> no it isn't.
Lukasz has stepped up to get --disable-wispr doing what it is supposed
to do. So soon you should be able to turn it off for real.
While I appreciate the work, being able to --disable-wispr during configure unfortunately
is a functionality trade-off for all end-users, who would rather be able to configure it
> In fact the online check as it is done so far (default enabled,
> option to turn it off, no mention of it in the manpage, no privacy
> policy available for the nginx server replying on how it cycles logs)
> can quickly get this project into trouble. The current implementation
> clearly violates privacy laws (EU-wide for starters).
These are good points.
> You clearly should not only implement a user-configurable option for
> it, but also default it to off (default off gets you a consent of the
> user to the use of the online check service).
I still hope to convince Marcel, that I prefer adding Salva's patches
which allow the user to set the server address for the online check.
I actually agree with Marcel on the point that making the online check URL itself
configurable introduces other problems. Yet, summarizing like "There is no
machine id or any kind of information to associate this HTTP request with another one from
the same source IP." is wrong in an IPv6 world. A connman client/ infrastructure
cannot control such, i.e. the fridge's connectivity may well be identified and tracked
long-term with a default connman.conf.
Now, that's my five cents. I will watch how and what patch gets implemented. Perhaps,
I can suggest a complementing doc patch or else later.
> I can give you more input on the why, if you require it. But
> case is _very_ clear.