klive.cpushare.com is unreachable because it currently lacks a DNS entry. Perhaps that is an oversight but it might well be that the project is now abandoned forever. jeroen@epia ~ $ dig cpushare.com ; <<>> DiG 9.4.3-P5 <<>> cpushare.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41351 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;cpushare.com. IN A ;; ANSWER SECTION: cpushare.com. 86382 IN A 88.149.230.202 ;; Query time: 2 msec ;; SERVER: 10.0.0.138#53(10.0.0.138) ;; WHEN: Fri Sep 24 15:52:21 2010 ;; MSG SIZE rcvd: 46 jeroen@epia ~ $ dig www.cpushare.com ; <<>> DiG 9.4.3-P5 <<>> www.cpushare.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5043 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cpushare.com. IN A ;; Query time: 2 msec ;; SERVER: 10.0.0.138#53(10.0.0.138) ;; WHEN: Fri Sep 24 15:52:26 2010 ;; MSG SIZE rcvd: 34 jeroen@epia ~ $ dig klive.cpushare.com ; <<>> DiG 9.4.3-P5 <<>> klive.cpushare.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40605 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;klive.cpushare.com. IN A ;; Query time: 2 msec ;; SERVER: 10.0.0.138#53(10.0.0.138) ;; WHEN: Fri Sep 24 15:52:32 2010 ;; MSG SIZE rcvd: 36
Additionally, it appears there is no server authentication done, things are sent by UDP without any SSL-like protections. As a result, this is a security issue too since if someone installs this it may end up sending data somewhere other than the intended klive.cpushare.com that is down.
I don't see how this is a security issue. We know very well what data are sent, and we already agreed to making the information available publicly or we wouldn't install klive to begin with.
That's a good point. Though that applies to the data sent to klive.cpushare.com. However, if the information is getting sent elsewhere, and elsewhere happens to get other information too, it's one of those scenarios where something like a tracking cookie could be recreated despite clearing it based on the uniqueness of your machine from klive's view. So maybe it's not a security issue or even a privacy issue exactly, but there are still privacy implications beyond what there'd be if you knew the data was only getting sent to the legit klive site.
Apologies, the service is down. Before shutting down I asked kernel.org if they were interested to transfer it there, but they weren't so it shutdown, probably there are other equivalent services available by now. Using SSL would have a bit of a network overkill IMHO, but if the service wasn't down and there was request for it I could have added it. If there was a real need for SSL I would have added it but the whole point of participating in klive was to share the transfered data in the open in the first place...
dropped
