Rockbox Development > Feature Ideas
Disable Radio?
cool_walking_:
ve4cib, I don't think the issue was how much the DAP's being used, but *how* it's being used - I got the impression that certain radio stations in the area are not "family friendly".
AlexP:
Please, stop discussing the why. If anyone has anything to add to the how, then please do, but nothing more on parenting etc.
ve4cib:
I'm in agreement that the easiest way of doing this would be to disable it at compile-time. Either you want the radio disabled or you do not. I can't see much reason for wanting to arbitrarily switch it on and off, so disabling it at compile-time should be sufficient. Besides, that will free up that tiny bit of extra memory for other (more useful?) things.
Something else that just occurred to me (and is arguably way more work than it would be worth)....
What about some sort of password-protected locking feature on the device? If you have certain folders that contain private data, or you share your device with someone else and you don't want them knowing what radio presets you happen to enjoy this might be useful.
Essentially every program (plugins, and core functions) could have a "Lock this feature" and "Unlock this feature" functionality. The easiest place for this to appear would probably be in the context menu. To unlock you'd be prompted with the on-screen keyboard where you'd type in a password. Provided the password is correct you'd be allowed to use the function. An "Auto-lock this feature" might also be useful; you have to unlock it every single time you want to use it.
Obviously this would require a fair bit of coding if you want the password to be secure (you'd need a secure way of storing the password), and you would need to add the Lock/Unlock checking to... well, pretty much everything. I haven't actually looked at the code so I don't even know how feasible this would be.
saratoga:
--- Quote from: ve4cib on March 01, 2009, 12:30:21 PM ---What about some sort of password-protected locking feature on the device? If you have certain folders that contain private data, or you share your device with someone else and you don't want them knowing what radio presets you happen to enjoy this might be useful.
--- End quote ---
This has been suggested many times before. Its been rejected since its trivial to mount any rockbox device in UMS mode and reset the settings.
ve4cib:
For the issue at hand though all we need to do is have a secure password when you want to enable a certain feature. The implementation doesn't need to be bullet-proof, but it can be made "good enough."
This is maybe getting overly complicated, but please bear with me...
1- add a "LOCK_FEATURES" flag at compile-time. If this flag is enabled then you will be promted at compile-time you specify what features will require password-protection.
2- at compile-time you are prompted to enter the password. This password cannot be changed unless you recompile
3- store the password as a read-only encrypted hash in the flash memory/boot-loader portion of Rockbox.
4- when you attempt to use a locked feature you are prompted for a password. You enter it, its secure hash is calculated and compared to the one generated at compile-time.
5- if the password is OK then you can use the feature. It remains unlocked until you power-off the device
Yes, you can mount the device, but all the settings are compiled-in; you can't change anything by mounting it without re-compiling Rockbox and re-installing it. And you can't read the password file since it's an encrypted hash (same kind of idea as the password files on Linux systems). You could brute-force or reverse-engineer the password, and changing the password is very inconvenient, but it should offer feature-locking that's good-enough for most purposes.
For the hash portion one could presumably use the md5 plugin that's already generated. md5 is slightly deprecated, but we're not talking about storing state secrets.
Protecting entire folders, as you point it, is not really viable on media players since you can mount the device and read it anyway. But for locking specific features I think should be possible to do it with password-protection on the off-chance that you want to simply keep certain users from accessing a given feature, rather than leaving the feature compiled-out.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version