Feature Request: Scheduling and Remote Start Option via Onion

[magnetic5355]

Remote Start via Onion in case activation is forgotten

Scheduling - allow consistent set it and forget it monitoring

[leonardoporpora]

This is a duplicated. I think people is already working for scheduling module whereas we said that remote start is dangerous and we do not know if we will enable it I’m against this feature because it’s cool and good but is more dangerous than helpful.

[kushaldas]

This will be a security risk (by providing remote control access).

[ghost]

• use-case: domestic worker enters the house, and you want to disable the app while they are there (Feature Request: PIN code to disable selectable sensors for a time slot #286)

• use-case: you need airbnb guests to be able to control Haven, so they have privacy. And you need to be able to ensure that it's turned on after they check-out. (Feature Request: PIN code to disable selectable sensors for a time slot #286 (comment))

• use-case: sensitivity is not ideal. Either too much logging or not enough. Returning to the property for adjustments is inconvenient, and also very costly if you're overseas.

@kushaldas

This will be a security risk (by providing remote control access).

There are security risks with or without remote control. If you cannot access the device remotely, you might be forced to give a guest your phone's PIN so they can disable it, at which point they have access to a lot more on your device than necessary. Or if you forget to turn it on, then you're exposed to the security risks of being unprotected until you can return to the device.

The simple answer here is to have access controls, and the controls to the access privs could be locally configured. So the webpage could have an admin login and a read-only login. If admin login is not needed by a user, it could be disabled in the config.

[lukeswitz]

2 way communication is a security risk. It’s the same reason pacemakers and medical devices don’t accept requests, only serve logs.

You can argue the point all day, but look to products like Alfred, etc. that do what you’re requesting instead of steering this project off course.

[ghost]

@lukeswitz

If an attacker has access to the local Haven configuration and can tamper with a switch that would enable remote onion access, then you're already fully compromised and have nothing more to lose at that point. So the negligible or zero risk added by having a (default disabled) switch to facilitate remote access would be considerably less risk than the risks of not having the option at all. IOW, it's actually detrimental overall for a user's security to lack this feature.

Alfred is both proprietary closed-source and also gratis. That dangerous combination is a recipe for disaster w.r.t security. They must monetize that tool and yet users still have to trust it. Haven is actually the closest (perhaps only) open-source tool for remote surveillance, AFAIK.

[ghost]

For the sake of being thorough, we must consider the workaround: that users could alternatively install a mechanism that gives them remote control over their whole phone. That is IMO the only worthy rationale for Haven not offering integrated remote control.

Pros:

• Keeps Haven simple. Many small tools are better quality than a monolithic one. Haven devs have less to focus on.

Cons:

• Droid VNC Server requires root (feature req run without device rooted oNaiPs/droidVncServer#68) and although it's libre it does not exist on f-droid (Add to F-Droid oNaiPs/droidVncServer#134). The only app that works without root is exclusively available as a Playstore-jailed binary blob.
• If it's compromised, the harm has no limits. (whereas the harm done by compromising Haven-integrated remote control is generally limited to Haven's capability, notwithstanding borderline sci-fi-scenarios)

[lukeswitz]

I’m gonna let you continue with this. I am steering you towards Alfred because you want remote options and are out of your depth; there are open source android options as well.

As for how it is implemented: differently than you’re plastering the repo with, probably JSON in the cloud (look back at the year of comments on the topic). I’d focus on learning instead of assuming you’ve figured out cybersecurity and how to mitigate it. The app doesn’t need the feature, you want it. The app needs many things and the list grows daily with major bugs. Focusing on its shortcomings while it’s essentially still a pile of random code complied together seems as big a waste of energy as me writing this.

[lukeswitz]

Looked at your code and other exploits; I can see your rationale after doing a little research into your work (impressive). No question remote control is coming, and your ideas may help the project to arrive there quicker. Thanks for your help.

[ghost]

It's good to have ppl arguing both sides of a security decision. I'm just trying to get all the issues and factors out on the table.

Triage may indeed result in a low priority rating for this ticket, and that's fair enough.

I basically need this feature implemented in 5 days. That's not going to happen even if everyone were on-board, well financed, and taking meth. So rooting and installing Droid VNC Server is perhaps the only feasible trustworthy option in my particular situation, AFAIK. Otherwise if I tune the sensors well and have no visitors who would need to disable it, then it'll all work out.

(edit) Noisy logs is another factor. That is, when monitoring the front door of a house, log pollution is made every time the owner comes and goes. False positives increase the chance of overlooking true positives. Remote control could facilitate cleaner logs.