On to, 2015-07-09 at 11:15 +0200, Marcel Holtmann wrote: > Hi Jussi, > > >>> Now that we're talking about the online check... I've talked to people > >>> who considered this behaviour "calling home" and thought it > >>> unreasonable that > >>> a) it's not possible to prevent the online check from happening via > >>> configuration and > >> > >> > >> Why would you prevent it to happen? This check is something extra anyway, > >> being "ready" means you are connected. In a way, people should not care too > >> much not seeing there service being set to "online", since such check > >> can't > >> be bullet-proof. > > > > It's not about connman functionality at all. It's (as an example) > > about people building a super secret embedded product demo on top of > > Yocto suddenly realizing that their device is connecting to a web > > server they don't control or even know about (aka "who is this Marcel > > Holtmann why is our IOT Fridge fetching web pages from him?") > > if this super secret fridge is connected to the Internet and can actually > reach it, then it is no longer super secret. If you would be really worried, > then you would have it locked up in a lab with no access to anything. > > And even if it would be calling the ConnMan servers, nobody in the world > could tell super secret fridge apart from someone sitting next to it using > ConnMan on Yocto on a Minnowboard or its laptop. > > I can not repeat this enough. This whole think is designed with full > anonymity in mind. We are building our own HTTP request for exactly that > reason. No headers can sneak in. No unwanted meta data can leak. ConnMan > ships its own HTTP client for a reason. > > Think about this for a second. You can leak more information by using a > distro libcurl by accident that includes some meta headers. If ConnMan's > online check is your concern, then you do not understand privacy at all. > > > FWIW, I totally understand the point Patrik makes in the previous > > discussion: > >> If the URL is configurable, upstream > >> does not have the means to fix online related bug reports as we'd be > >> unable to confirm the online checking service to work properly in the > >> first place. In the worst case even the URL accessed is not known, not > >> even to the person submitting the bug report. > > > > This is a compelling argument as well -- I'm not in favor of making > > this too easy. I do think there are legitimate use cases where people > > do not want to rely on Marcel (or Intel) handling their online checks. > > > > Since the required patches are not big (as shown by Pasi, thanks!) > > just adding clear documentation to Yocto about the online check > > Connman makes and instructions on how to modify it may be a sufficient > > alternative. > > If someone wants to add documentation on what ConnMan is doing, then I am all > for it. More documentation is always good. I am in favor of full transparency.
There is already documentation about online check in ConnMan README file. If that is not enough, then patches are welcome. > > I am however not in favor of giving such an option. If someone wants to shoot > themselves into the foot, then they can pick up the gun by themselves. I do > not see a good reason why would make this easy. > > And honestly I prefer them carrying an extra patch changing the defines in > the source code. That means they have to carry that extra patch. So every > time it breaks, they get a nice reminder that something might have changed. > So they have a change in catching it. The config file is to easy to forget. > > Regards > > Marcel Cheers, Jukka _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
