Most recent activity
-
I've been thinking about this more and like the idea of
setPassword
- my plan would be something like:- In
padlock.boot.js
:
- Read
padlock.setting.json
for the password - Call
E.setPassword(password)
(andE.lockConsole()
)
- Read
- Only allow
padlock.setting.json
to be set from the apploader / IDE
- (If the password is setable from the settings app, anyone with physical access can unlock the watch)
- (If the password is setable from the settings app, anyone with physical access can unlock the watch)
Is there any existing standard setup for adding this into
.bootrst
? I don't see any apps using it at the moment so I was going to generate it from all the<app>.bootrst.js
files, if that sounds like a plan?How cautious should I be with this file btw? Could I potentially brick my watch if I accidentally raise an exception or break BLE connections here?
- In
-
I like the sound of asymmetric keys or using phone IDs/mac addresses to encrypt too.
E.setPassword
sounds very useful for dealing with more technical attacks - I suppose an existing bluetooth whitelist will cover anyone accessing the console unless an attacker guess the allowed mac addresses too.I'm thinking the existing scramble GPS app works as a lightweight/ease-of-use "lock", and I have a few ideas for a more lockdown-mode which would incorporate these ideas along with encryption based on some key.
We could either encrypt just GPS and use
recorder
's existing async prompting to add a password-prompt afterwards, or go for more of a whole-device lock and request a password at either boot or unlock time. -
regular or automatic sync (with auto delete in case no sync happened for a while) of the data to GadgetBridge
This is something I've been thinking about for a while - a bluetooth daemon running on a raspberry pi that regularly updates my watch's clock, fetches health/gps data off the watch and so on
-
Using the phone sounds like an idea, I've created an initial PR to do this without gadget bridge (as I don't have it currently) but would be interested in adjustments to encrypt using a key stored either on the phone, or using some property of the phone.
-
I was thinking recently, if I lost my watch (or more specifically, it was stolen) while I had GPS data on it, then my home address, work etc is all present there.
I'm interested in peoples' opinions on this - would a patch to runplus and/or a module for apps to encrypt and decrypt GPS data be useful?
Tech / CPU use
I feel like AES might be overkill, and we could instead perform some simple scrambling of the coordinates based on a code the user enters, perhaps offset them from the middle of the Pacific using the user's code as a seed for a PRNG.
Usability
Unless we saved the key on the watch (which defeats the point), the user would have to enter a code each time they wanted to read/write GPS - this wouldn't be great for usability, but I'm a little out of ideas.
-
-
Yeah I'd been thinking the second duration was a bit short. Thanks for checking it out! I like having the milliseconds and it makes the code more worth having if we keep it up to 1 minute, I'll go with that for now - will test out the 100m sprint next when I'm next at the track!
Speaking of settings, I'd quite like to drop the settings entirely - what are your thoughts on the format?
-
Thanks for checking it out! I've dropped the decimal point after 1 second, how does this change feel for you?
-
Thanks for the feedback - I've created a PR that should resolve the battery drain, and there's now an option for the
hh:mm:ss
format (although happy to hear more suggestions about tweaking this to fit inside various clocks)
See github