Thanks. It should probably be noted in the readme that this will break things like the drawing of recorded GPS tracks on top of a map, as well as calculated distance/etc (because distance depends on latitude). Maybe it's safer to make GPS Scramble actually just record GPS data in its own columns (and disable the in-built GPS). You could then do Math.round((lat-base_lat)*100000) and could reduce the size of the log file a lot which would have its own benefits.

But the more I think about this the worse an idea I think it is... I mean, the position offsets are on the watch anyway (now in code, but I guess later in a settings file), so anyone could figure out what your GPS traces were if they really cared anyway, and right now with the undocumented options in interface.html this just feel like a trap designed to trip up normal users wanting to use the GPS recorder.

Please could we at least have some comments to the extra options in the interface.html that make it clear they are for the GPS Scramble app and shouldn't be enabled otherwise?

If you're seriously concerned about data privacy we need something a bit more global - stuff like unread notifications and health history data probably want to be secure too and we really don't want every app developer implementing their own different (and probably insecure) encryption schemes.

Yes that's a fair point about it messing up the actual GPS entries in the log, I'll move them to another column.

I think to find out the source GPS traces, someone would need the original starting coordinates though, right? Otherwise they'd be trying to overlay a trace on various parts of the surface of the earth around where they found the watch, seeing if it would line up with roads etc? But yes, it doesn't hold a candle to actual crypto, but my threat model is a non-techie who's interested in anything they can quickly garner from a discovered watch.

If we were to take a more global approach, any computational effort could be offloaded to the firmware and we don't have to worry about maintaining a key in memory across JS reloads. The user would only need to enter a key when their watch is powered on, for example. The only question is how do we handle someone accessing the watch when it's powered on? I'd like to avoid a lockscreen as I really enjoy the accessibility of BangleJS.

(Happy to move this conversation back to the forum if preferred)

Yes, probably best to talk in the forum.

I was imagining not actually encrypting what's written to the storage as that seems a bit heavy, but just restricting Bluetooth access to the device (maybe allowing a password/passcode that the app loader/gadgetbridge saved, or even just using Bluetooth's bonding/security in such a way that nobody but you could pair a new device).

I guess if someone had access to the watch but it wasn't connected to a phone they might be able to find some data, but that is almost a separate problem - I guess we could add something like "don't unlock watch unless there's a trusted bluetooth connection"

I like those ideas, shall have a think about it and continue a discussion in the forum

Will close this for now - I'm leaning towards E.setPassword

Ok, thanks! Right now I don't believe we prompt for a password on connection when E.setPassword is set, but I guess we could send a pw: prompt that it would be easy for the app loader to pick up, and perhaps in that case it could prompt the user

Sounds like a plan, I'll see what I can do