• http://owntracks.org/booklet/features/tls/#android (Screenshots)
• http://owntracks.org/booklet/features/tls/#ios (Screenshots)
• http://owntracks.org/booklet/features/tls/#manual-configuration-on-android (Screenshots, functionality changed)
• http://owntracks.org/booklet/features/tls/#obtain-a-certificate-and-key (s/startssl/letsencrypt/g?)
• http://owntracks.org/booklet/features/tlscert/#android (import file into the app)
• http://owntracks.org/booklet/features/friends/#who-is-that (no contact book feature on Android)
• http://owntracks.org/booklet/features/waypoints/ (describe setup on Android)
• http://owntracks.org/booklet/features/waypoints/#setting-up-ibeacons (describe setup on Android)
• http://owntracks.org/booklet/features/waypoints/#remote-loading-of-waypoints (describe setWaypoints cmd)
• http://owntracks.org/booklet/features/comparison/ (HTTP mode on Android, s/TLS with cert in filesystem /Custom TLS CA cert/g, Remote configuration on Android)
• http://owntracks.org/booklet/features/comparison/#android (drop user-provided certificates via an absolute path, drop button to share a Google Maps link that places a marker at lastKnownLocation
  , drop Google Fused Location Provider...)
• http://owntracks.org/booklet/features/android/#setup (no Advanced Connection Preferences, specify the absolute filesystem path)
• http://owntracks.org/booklet/features/encrypt/ (explain optional encrypted array payload)
• http://owntracks.org/booklet/features/remoteconfig/ (document setConfiguration)
• http://owntracks.org/booklet/features/setwaypoints/ (also on Android now)
• http://owntracks.org/booklet/tech/json/#notes (no extra heading for that, move do description of locked attribute)
• http://owntracks.org/booklet/tech/http/ (move to Features?)
• http://owntracks.org/booklet/ideas/ (drop links to binarybucks/mqttitude. Repo will be removed shortly)
• http://owntracks.org/booklet/faq/ (rework with annoying questions)
• http://owntracks.org/booklet/guide/clients/#o2s (drop?)
• Consider merging http://owntracks.org/booklet/features/comparison/, http://owntracks.org/booklet/features/android/, http://owntracks.org/booklet/features/ios/ to http://owntracks.org/booklet/guide/apps/

As per owntracks/ios#379, I'm having trouble using a TLS client certificate with Owntracks for iOS 9.1.6. My setup used to work, but something changed in the last few months.

Following the documentation recommended setup, I continuously get an error with Mosquitto 1.4.9 and OwnTracks, though I'm still able to connect properly with mosquitto_pub (as long as I specify the proper client certs / files).

When using the Mosquitto broker support for TLS certificates can be enabled as follows:

require_certificate true
use_identity_as_username true

...

We recommend you proceed as follows:

1. Install the TLS CA certificate in your system keystore by sending it (e.g. via e-mail) to your device and installing it in the system profile. (Click on the certificate and follow iOS' instructions.)
2. Send the prepared PKCS#12 file (with an .otrp extension) to your device, and open it. It will be imported into OwnTracks
3. Launch OwnTracks, select Settings and TLS. Select the otrp file you just imported as Client Certificate Filename, and below that, enter its passphrase.
4. Leave Use Custom Security Policy disabled.
5. Verify the connection to your broker.

OwnTracks shows:

error The operation couldn't be completed.
(OSStatus error -9829.) {
}

Mosquitto shows:

1466436433: New connection from XX.XXX.XXX.XX on port 8883.
1466436430: OpenSSL Error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
1466436430: Socket error on client <unknown>, disconnecting.

The reason I'm raising an issue here is that I can see in the screenshots in the issue referenced above that others do have Use Custom Security Policy enabled, and I find that enabling it makes everything work as expected, even with security measures enabled like Validate Certificate Chain and Validate Domain Name.

I'm confused -- should I have Use Custom Security Policy disabled (as per the docs), or should I leave it enabled (as per other users, and what seems to be working)? If the latter, should the docs be updated to reflect this?

What exactly does this switch change? I've tried reviewing the source code, but I'm afraid it's a bit over my head.

Thanks for any help you can provide.

I'm not sure if this is a possibility or not. I fully understand how to create and use a waypoint / region / geofence from a device and how enter/leave notices are published from that device and subscribed to from other devices.

Question... can the waypoint / region / geofence from one device or from the server side be published out to user devices so everyone has the same geofence?

My assumption would be the {"_type":"cmd", "action":"setWaypoints", "waypoints":{"_type":"waypoints","waypoints":[...]} and publish that json message to each device individually? If so, can you provide an example of that json filled out?

In a recent thread in the Node-Red Google Group a user had a problem connecting to the Hosted plaftorm, another user pointed out that the booklet still refers to the platform and this is confusing.

The links are:
http://owntracks.org/booklet/tech/proghosted/
http://owntracks.org/booklet/features/hosted/

a warning at the top of those pages pointing to community post should suffice I think.

Unfortunately I'm not able to submit a pull request myself at the moment.

https://owntracks.org/booklet/features/tls/

owntracks/ios#612

I realized that nowadays installing a certificate and trusting it requires an additional step in iOS. After following the instructions from the booklet for installation of the certificate I had to go to Settings/General/About/Certificate Trust Settings and enable full trust for root certificates for my CA cert. You may want to update the booklet accordingly.

Hello! Reporting an issue with: https://owntracks.org/booklet/features/tlscert/#pkcs12

Please add -legacy to this command. I kept having iOS .otrp "incorrect file or passphrase" errors getting a client certificate working and it's because the openssl v3 binary I was using generates them differently. Once I added -legacy, it solved the error :)

openssl pkcs12 -legacy \
  -export \
  -in jjolie.crt \
  -inkey jjolie.key \
  -name "Jane's certificate/key" \
  -out jjolie.p12

• http to mqtt
• encrypted payloads

Hi,
I'm trying to get the owntracks ios app working with TLS, using letsencrypt certificates on my own domain. I have successfully got the android app working with TLS using the generated .p12 key file, connecting to my private mosquitto mqtt server.

Steps:

1. openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -name "mymosquittocert" -out mymosquittocert.p12
2. renamed .p12 to . otrp
3. Uploaded DST Root CA X3 cert to ipad (Verified check)
4. Uploaded ISRG Root X1 cert to ipad (Verified check)
5. Uploaded Lets Encrypt Authority X3 cert to ipad (Verified check)
6. Uploaded mymqttdomain.duckdns.org cert to ipad (Verified check)
7. Uploaded mymosquittocert.otrp cert to ipad and opened with owntracks.
8. setup private mode, with host as mymqttdomain.duckdns.org, no websockets, TLS, And selected client cert as mymosquittocert.otrp with my passphrase.
9. IPAD General->about->certificate trust settings-> Enabled Full trust for ISRG Root X1 and DST Root CA X3. (don't see any others to enable full trust)
10. NO Custom Security Policy selected. (doesn't make any difference when I select one and select allow untrusted certificates, same error)
11. owntracks is trying to connect to: mqtts://mymqttdomain.duckdns.org:8443 c0 k69 userCJ
    Gets error: OSStatus error -9831.

Looking up with error is means: errSSLPeerUnknownCA - An unknown certificate authority was encountered.
I'm now sure what is unknown about the CA as I've uploaded verified root certs from letsencrypt. What am I missing?

The error on mosquitto mqtt is:
1503144469: OpenSSL Error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
1503144469: Socket error on client , disconnecting.

Over at https://owntracks.org/booklet/features/friends/, there is supposed to be a way to "bookmark" a friend to associate it with an address book contact. I'm not seeing that icon at all.

• App build number: 2.1.3
• Android version: 10
• Device: Pixel 2 XL

Reading the booklet, it seems there is use of reverse geocoding at times. It's not clear if this is disabled by default, and the security implications of sending coordinates to reverse geocoding providers are not addressed.

... so that it matches the link to the newer version found in features/tlscert.md, i.e:

https://github.com/owntracks/tools/tree/master/TLS

instead of...

https://github.com/binarybucks/mqttitude/tree/master/tools/TLS

Over at https://owntracks.org/booklet/features/android/, it is stated that "it is highly recommended to use HTTP mode on Android 6 and higher". However, it's not stated why, or if that recommendation is still current.

Also, "When using MQTT, the broker connection is not maintained permanently." It's not clear what the consequences of this are. There is a reference to the keepalive interval not changing that behavior. https://owntracks.org/booklet/tech/mqtt/#mqtt says that "MQTT was designed with mobile clients in mind so it doesn't require a persistent TCP connection."

Over at https://owntracks.org/booklet/features/friends/, the discussion is solely about MQTT mode, implying that friends support is impossible with HTTP mode. Yet https://github.com/owntracks/recorder#friends-in-http-mode covers friends in HTTP mode.

I'd like to see:

• Clarification on tradeoffs of MQTT vs HTTP and why MQTT is not recommended
• Clarification of what the broker connection not being maintained means
• Clarification of tradeoffs of MQTT vs HTTP regarding friends
• Documentation of the recommendation to avoid websockets

Some prior discussion on this:

owntracks/android#774 (Dec 2019) implies that MQTT was killing batteries. There was a recommendation in there, not stated in the docs, to avoid websockets. The HTTP recommendation is restated.

owntracks/android#745 (Oct 2019) again restates the aversion to websockets

For example:

• Ensure UI has Credits with URL to Web site #41

https://owntracks.org/booklet/features/security/

I have the impression that at least one other location reporter might have a default configuration to use a demo server. It seems clear to me, but not clearly obvious to everyone, that a location reporting program's default configuration must be to NOT report location at all until one has affirmatively configured/enabled a destination.

The README.md for the android app points to the booklet, and while the security section says a lot of useful things, it doesn't address this default configuration issue. (The ios README.md ought to point to the booklet too.)

Overall, having actual documentation for apps is really nice to see, and I appreciate it being there.

The readthedocs theme we use includes loading fonts externally from googleapis

mkdocs/mkdocs#1138 (comment)

When we change to mkdocs 1.2.3 (the current release), we will get another external reference for highlight.js loaded from cloudflare. By deactivating hightlightjs in mkdocs.yml we can avoid the problem for now.

Since mkdocs 1.2.3 a new version of readthedocs was integrated using local fonts, but this version is not available yet

.. as soon as layout is stable.

(assigned to self)

Dear JP and Christoph,

while exploring the documentation a bit more, I discovered that the section about the openHAB integration ¹ points to a repository which has been archived. It still talks about the »Mqttitude Binding« ², which I think is a thing of the past. Do you know of any updated resources on this matter, where the link could be adjusted to?

With kind regards,
Andreas.

• App build number: 2.1.3 (23102)
• Android version: 9
• Device: Xiaomi Mi A1

Hi,

This is a question about the locatorDisplacement value. In the docs, it says:

locatorDisplacement: The smallest displacement in meters the user must move between location updates. Defaults to 0 and is an and relationship with interval. Can be used to only receive updates when the device has moved.

(bold is mine)

However, in the preferences the default value is 500

I think the documentation is confused with the default in the android LocationRequest docs, where 0 is the default, if you don't set it.

In my (limited) experience so far, 500m is the distance that you need to move to trigger an update.

So my question is: which is right? Should the default in the preferences be 0, or should the documents specify 500 as the default?

I'm not a Java dev, so I'm trying to piece things together "from the outside" - please let me know if I'm way off track :)

Thanks,
Andy.

Region Monitoring and Waypoints

(assigned to myself)

in features/json.md

The story

Once upon a time I used to use Google Latitude to share real time location with friends. Then Google killed it and years later introduced alternative in Google Maps. Then a bit while later I started looking into a zero touch, (near) real time location sharing of my location with my partner where I would own the data and I could also control their publication. All that for security purposes. After vetting out a lot of shady apps on the Play Stores I concluded that there is no solution I would be happy using.

So what do you do when you can build an app? Yup, you build an app and regret it later. The app is storage agnostic and for simplicity the first provider is built on firebase and the client for collecting and publishing data was built as Automate script. All was well and nice, except the Automate script was clunky, not easily configurable and buggy in edge cases.

Then someone on Fediverse pointed me to Owntracks and I thought: "heh, maybe that would solve my problems". I looked into the Quicksetup and frankly got scared of the complexity of the "quick" way of setting this up. So I ran an experiment to see what will happen if I point OwnTracks Android client against my firebase provider. And it worked! So I moved the Device part of my app to use OwnTracks and called it a day. Obviously trying to give enough exclamation marks around "this is not something that should be considered secure, unhackable or private". And by no means it has fraction of the functionality of OwnTracks.

But(!) it does have significantly shorter quickstart. And that's what I'm using now. And since you called out for letting you know, I'm letting you know.

tl;dr

I made an app called The Mountains Are Calling for quick & easy & reliable location sharing for security purposes. Turns out OwnTracks Android/iOS client is a perfect part of that puzzle to gather the location data and store it in my quick-setup provider.

https://owntracks.org/booklet/features/traccar/
Is not understandable or wrong.

I just stetted up traccar on android and observed the following:

• Identifier in traccar is not made up like the mqtt topic, instead it is only the tracker id. So in my case
  it was just md. Device ID is completely ignored.
  Just to be clear, the doc suggested the identifier would be: owntracks/username/device-id. Instead it was tracker-id, so literally the only thing the documentation said not to be in the identifier.
• You have to add the device to traccar before connecting owntrack client. Otherwise you will get a http 400 error.

Also I don't understand why there is so much text on the http payload and stuff. People will look for information how to set up a connection between traccar server and owntracks. Development related stuff should be in another section, or at least subsection.

I would volunteer to improve the documentation, but I also wonder if the thing with the identifier is not a bug in android. Having only two letter identifiers limits you and might even be a security issue, because the identifiers are also some kind of secret.

I'm installing on latest Ubuntu LTS and there seem to be quite some breaking changes to the API of Mosquitto. The version Ubuntu has is 2.0.11.

Some changes I noticed are

• port field in config is deprecated
• -v flag of mosquitto_pub doesn't exist anymore (used here https://owntracks.org/booklet/guide/broker/)