Hacker News new | comments | show | ask | jobs | submit login

Why turn off a safety feature? if you're not-technical enough to install a malicious app that slipped into the market, this mechanism is practically made for you.

I am a massive Google fan. But I know a number of people who are not and prefer not to "trust" them with data.

Most have android phones because they feel similarly about Apple. This would horrify them.

Admittedly that's an overreaction. But I can't help feeling that a persistent connection with little option/choice is not the sort of thing a free platform should have.

I think it's actually a necessity specially for an open platform, imagine if a malicious app got loose and they couldn't do anything about it. It's a 'damned if you do, damned if you don't' situation.

I'm tired of these excuses for software makers to have more and more control over the devices we own.

Palm OS phones like the Treo never had any remote kill switch or other such nonsense. Anyone could develop for it and post their apps wherever they pleased. There was no gatekeeper to be be paid or placated, nor were there any super-scary viruses that brought down the network.

If this kind of Orwellian control is "a necessity specially for an open platform", why not allow Linux vendors the same power over your servers and workstations? After all, "imagine if a malicious app got loose and they couldn't do anything about it".

Seriously: it is up to the users to exercise good judgement and safe computing practices. If an infected phone is causing problems, let the carrier disconnect it (just like ISPs disconnect problem accounts). Turning power over to someone else is just another example of the nanny mentality. Not to mention that the back doors themselves may be exploited by malware.

Well if I wrote a malicious app my first approach would be to kill that connection :)

So it is something of a false security.

Besides; to fit with the whole "ethos" of the Android system it should be an optional feature (App Kill and App install).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact