SMS is working so far, but how should we secure it? Do we need other remote storage and logging capability?

How can the device know that its user is being detected vs an intrusion?

If onion service option is enabled, the onion address shows all the triggered events with no authentication. Considering the legacy onion addresses (<v3) are not too hard to find, this might have serious privacy implication on people if the onion address to their phoneypot is found. Now it does slightly help that it's not running on port 80 but implementing #33 is going to change it anyway.

I suggest making use of HidServAuth or adding some basic auth password to the webserver phoneypot is running.

create a folder per event/session

Is our current motion detection good enough? Should we incorporate this?

• can we do this through pure client/apps code
• we might need to use a server with Signal-CLI

I'm using a Nexus 5 with LineageOS, and Haven 0.0.18.

As soon as I'm done clicking through the onboarding wizard, the app crashes. Here's a screenshot and the logcat logs:

12-18 15:25:14.173  1782  1913 D audio_hw_primary: enable_audio_route: usecase(1) apply and update mixer path: low-latency-playback
12-18 15:25:18.820  2294  3471 I ActivityManager: START u0 {cmp=info.guardianproject.phoneypot/.MonitorActivity} from uid 10078 on display 0
12-18 15:25:18.910  8676  8676 I CameraFragment: Sensitivity set to High
12-18 15:25:19.037  1789  2729 I CameraService: CameraService::connect call (PID -1 "info.guardianproject.phoneypot", camera ID 1) for HAL version default and Camera API version 1
12-18 15:25:19.038  1789  2729 I CameraService: onTorchStatusChangedLocked: Torch status changed for cameraId=0, newStatus=0
12-18 15:25:19.049  1789  8730 D NuPlayerDriver: notifyListener_l(0xb5d2b080), (1, 0, 0), loop setting(0, 0)
12-18 15:25:19.066  1789  8732 D NuPlayerDriver: notifyListener_l(0xb5d2baa0), (1, 0, 0), loop setting(0, 0)
12-18 15:25:19.082  1789  8734 D NuPlayerDriver: notifyListener_l(0xb5d2ba40), (1, 0, 0), loop setting(0, 0)
12-18 15:25:19.082  1789  2729 I Camera2ClientBase: Camera 1: Opened. Client: info.guardianproject.phoneypot (PID 8676, UID 10078)
12-18 15:25:19.085  1789  2729 D mm-camera-intf: mm_camera_open: dev name = /dev/video2, cam_idx = 2
12-18 15:25:19.085  1792  1792 I mm-camera-sensor: module_sensor_start_session:584 session 2
12-18 15:25:19.304  1792  1792 I mm-camera-sensor: module_sensor_init_session:478 ois device is not supported
12-18 15:25:19.304  1792  1792 I mm-camera-sensor: 
12-18 15:25:19.306  1792  1792 I mm-camera: gyro_module_start_session: Enter
12-18 15:25:19.306  1792  1792 I mm-camera: gyro_module_start_session: Init DSPS
12-18 15:25:19.306  1792  1792 E mm-camera: Failed to open sensor1 port
12-18 15:25:19.306  1792  1792 I mm-camera: gyro_module_start_session: dsps_proc_init() failed
12-18 15:25:19.306  1792  1792 I mm-camera: gyro_module_get_port: Exit failure
12-18 15:25:19.306  1792  1792 I mm-camera: cpp_module_start_session:352, info: starting session 2
12-18 15:25:19.327  1792  1792 I mm-camera: cpp_module_start_session:433, info: cpp_thread created.
12-18 15:25:19.328  1792  1792 I mm-camera: cpp_module_start_session:436, info: session 2 started.
12-18 15:25:19.328  1792  1792 I mm-camera: c2d_module_start_session:246, info: starting session 2
12-18 15:25:19.328  1792  8736 I mm-camera: cpp_thread_func:55: cpp_thread entering the polling loop...
12-18 15:25:19.328  1792  8737 I mm-camera: c2d_thread_func:39: c2d_thread entering the polling loop...
12-18 15:25:19.328  1792  1792 I mm-camera: c2d_module_start_session:284, info: c2d_thread created.
12-18 15:25:19.330  1792  1792 I mm-camera: c2d_module_start_session:306, info: session 2 started.
12-18 15:25:19.331  1792  1792 I mm-camera-sensor: module_module_set_session_data:2667 max delay 2 report dSelay 1
12-18 15:25:19.331  1792  1792 D mm-camera: module_faceproc_set_session_data:1987] Per frame control 2 1
12-18 15:25:19.331  1789  2729 D mm-camera-intf: mm_camera_open:  opened, break out while loop
12-18 15:25:19.332  3193  3204 E ANDR-PERF-LOCK: Failed to apply optimization for resource: 4 level: 0
12-18 15:25:19.335  1789  2729 I Camera2-Parameters: Camera 1: Disabling ZSL mode
12-18 15:25:19.335  1789  2729 I Camera2-Parameters: initialize: allowZslMode: 0 slowJpegMode 0
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 1280 height: 960
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 1280 height: 768
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 1280 height: 720
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 1024 height: 768
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 800 height: 600
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 800 height: 480
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 720 height: 480
12-18 15:25:19.341  8676  8676 I SurfaceView: width: 640 height: 480
12-18 15:25:19.341  8676  8676 I SurfaceView: selected width: 640 selected height: 480
12-18 15:25:19.342  1789  1789 E Camera2-Parameters: set: Requested preview FPS range 15 - 30 is not supported
12-18 15:25:19.346  8676  8676 D AndroidRuntime: Shutting down VM
12-18 15:25:19.347  8676  8676 E AndroidRuntime: FATAL EXCEPTION: main
12-18 15:25:19.347  8676  8676 E AndroidRuntime: Process: info.guardianproject.phoneypot, PID: 8676
12-18 15:25:19.347  8676  8676 E AndroidRuntime: java.lang.RuntimeException: setParameters failed
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.hardware.Camera.native_setParameters(Native Method)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.hardware.Camera.setParameters(Camera.java:2015)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at info.guardianproject.phoneypot.sensors.motion.Preview.surfaceCreated(Preview.java:228)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.SurfaceView.updateWindow(SurfaceView.java:618)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.SurfaceView$3.onPreDraw(SurfaceView.java:161)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:944)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2205)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1254)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6344)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:874)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.Choreographer.doCallbacks(Choreographer.java:686)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.Choreographer.doFrame(Choreographer.java:621)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:860)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.os.Handler.handleCallback(Handler.java:751)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:95)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:154)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:6186)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
12-18 15:25:19.347  8676  8676 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)
12-18 15:25:19.349  2294  3348 W ActivityManager:   Force finishing activity info.guardianproject.phoneypot/.MonitorActivity

Sometimes people can move fast, and not get caught on camera

so far we are using SMS and notifications.

Do we need to log evidence in a more hardened way?

How do we present that to the user?

we should prompt or set some default for action

There shouldn't be any notifications, especially not when the screen is locked and the app is activated. Don't want to tip anyone off about the system running.

Perhaps trigger a "reminder' notification when device is unlocked if the PP app is active

This would allow you to turn PhoneyPot off before you enter the room.

Allow multiple Haven instances to synchronize/backup data between eachother over HTTP or preferably HTTP-over-Onions. This would enable a hub device to backup data for multiple remote Haven instances in more insecure locations. It would also support a "smart home" type configuration with multiple points of monitoring.

When Haven is activated, it shows this notification on the lock screen.

There should be at least an option to not show it there. If you're using Haven as a security device, like in a hotel room, and an attacker picks up the phone and looks at the lock screen, in many situations it would be better if they didn't realize their actions were being logged.

what are reasonable thresholds

When setting up the Signal number in Haven, the process quietly fails if you do not enter the number in international format. It should ideally try to automatically fix it or inform user what's the right format with an example.

Implement a "low power mode"uses camera and other high power sensor more efficiently, by triggering them from low power sensors

sound + light sensor -> trigger camera activate and/or video recording

light, motion -> trigger one minute of active camera motion detection -> trigger one minute video recording

Yes I think so!

I've been testing out PhoneyPot 0.0.5, and I'm seeing some weird behavior. Inside my app there are currently 14 incidents. The first incident has 3 camera motion events, with 3 different images.

But the rest of the incidents only have sound events, and in fact I can't even get the app to register camera motion events at all. If I activate it and move a bunch in front of the camera, or pick up the phone, it doesn't register new camera motion events (or accelerometer events). It only registers sound events.

In the remaining 13 incidents, all of the sound events are the exact same audio file (the sound of emergency vehicle sirens driving by). It's a 14-second clip, and that same clip is listed for each event. Most of the incidents have only 1 event, but one incident has 4 different events, but those events are all the same 14-second sound clip of sirens.

Also, I can't always reproduce this one, but sometimes when I'm scrolling through the list of incidents, I can't scroll all the way to the bottom of the list, it just stops before the bottom so I can't click on the most recent items. Although that's not happening now. In any case, it would be helpful to reverse the order of the incidents, so that the most recent is at the top instead of at the bottom.

My test phone is a Nexus 5 running the latest version of LineageOS, without root. I'm happy to try to help debug by extracting data from my phone.

I can think of multiple situations where one might want to make use of an external camera (like this and this) or mic for their phoneypot. Especially that some of these cameras already do have LED lights. I haven't tested this myself but are they supported out of the box, if they're compatible with android? Or do you need to add support for that?

This seems mostly to be working, but more work to do.

What can we do to change that?

Trigger via other sensors?

it would be great if along with a remote notification message (via SMS or something better in the future), you could also see the photo or hear the audio

isn't the phone lock enough?

When you activate and it's counting down, maybe it should specifically say, "Lock your face and place it face up [or face down]", depending on which camera you're using. Also I think good to tell the user to lock their phone.

Will wakelock and foreground service handle this properly?

Until next gen onion services are live, the actual onion addresses aren't private from HSDir nodes. So it's possible that Haven onion services could get discovered by an attacker, giving them access to all of the evidence logs.

The easiest way to thwart this is to generate a random string and prefix all the URLs with it. So instead of starting with just http://blahblahblah.onion:8080/, the URLs should start with http://blahblahblah.onion:8080/randomstring/. This way, if an attacker discovered the onion service, they won't be able to view the logs without guessing the value of randomstring -- which is essentially a random password. This is how OnionShare URLs works.

The camera is the most likely culprit.

Should we offer a mode without the camera?

Can we increase time interval and turn camera on/off between?

link

Link to an existing device, instead of registering a new number. This shows a "tsdevice:/…" URI. If you want to connect to another signal-cli instance, you can just use this URI. If you want to link to an Android/iOS device, create a QR code with the URI (e.g. with qrencode) and scan that in the Signal app.

-n NAME, --name NAME
Optionally specify a name to describe this new device. By default "cli" will be used.

I'm having trouble connecting to the PhoneyPot onion service from OnionBrowser in iOS. When I load http://[myaddress].onion:8888/ I get the error message:

Cannot Open Page
An error occured: The requested URL was not found on this server. (Error "NSURLErrorDomain: -1100")

I think that this is due to an OnionBrowser bug where it's parsing the URL incorrectly, and isn't actually trying to connect to port 8888. I should open an OnionBrowser bug to address this.

However, there's no need to listen on a port other than 80 anyway. PhoneyPot can still listen on 127.0.0.1:8888 on the device, and the onion service can just forward port 80 to port 8888. (This is how OnionShare works as well, the actual web service is on some high port, but the onion service forwards port 80.) It's just a matter of configuring the hidden service.

We'll have to see how the visual change detection works in different lighting

In-app "report" view. The pin-gated reporting view would display the timestamped list of which sensors alarmed at which times, ideally with image previews for all alarms.

with preview, graph of severity/level, appropriate for type of sensor

currently there are the last 10 photos stored, but nothing related to specific incidents.

here are some thoughts:

• how many photos, audio or length of time should we capture?
• should this be stored in encrypted IOCipher file system?
• what is the user interface for displaying these, etc?
• how do we allow users to export/share incident reports and media?

Hey @n8fr8! You may want to move this to the wiki, but I'm posting it in an issue for now because it's what I have access to. I put together a storyboard with my thoughts about how to tell the story of phoneypot and get people set up when they first use it. This is a start. If you like the direction, I think we should put it in front of some people to get their impressions.

Everything in black is what would be shown on the screen. In green are notes about the interactions.

We need to incorporate settings into the onboarding better, and then add a settings menu somewhere

we need to decide if the light, heat, barometer sensors are actually useful here

A possibility the multi-sensor capability of the smartphone is that alarms on some sensors could trigger an otherwise-undesirable capability that fixes the light-level problem: activating the flashlight to get a clear capture of the otherwise pitch-black environment.

It would be useful to add an event when Haven is manually activated, and another event when Haven is manually deactivated. Also, I'm not sure if this is currently implemented, but it would be useful for there to be an event when the phone shuts down due to low battery, and an event when the app closed (because someone is powering off the phone for example) but not deactivated or because of low battery.

I think having these extra events will make users more sure of themselves. And if you come back to find Haven not activated, you'll have evidence that it's because you just forgot to activate it rather than because someone tampered with the phone while you were away.

if you've got no events in your event library, I think users can get a little lost trying to go back to the "configuration" page once you've finished on-boarding. It's nice and easy from the Haven Log page, but when you're on the arming ("Tap to change countdown") page, the options of just Start Now / "Start Later" aren't as obvious. "Start later" takes you to the log (where you need to be), but the giant "click the go button down here, dummy" arrow leads the user away from the triple-dot in the upper right they're actually seeking. Maybe just add the triple-dot to the arming screen as well.

for evidentiary purposes too, in the event of a serious intrusion you want to go public with,

Some people might want to turn off mic, camera, motion, etc... we need to have a better UI overall for sensor configuration on the fly.

It would be nice to be able to tap on an image that PhoneyPot takes in order to see it full screen, and pinch and squeeze to zoom in and out and look around.

This should be possible: https://scholar.google.com/scholar?bav=on.2,or.r_cp.&biw=1920&bih=940&um=1&ie=UTF-8&lr&cites=3938968519160815019

generate pgp key pair and sign all incident reports
send a hash of data over SMS or other service
blockchain notarization of hash?

I'm trying to build the apk for some testing but can't get it to work. I get 5 errors of Gradle saying it wasn't able to resolve resolve project :external:signal-cli. Is there something obvious I'm missing? Do I need to be using a specific version of Gradle or Android Studio?

"Sample Android application that serves as a monitoring service by leveraging on device's accelerometer, camera and microphone."