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]

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.

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.

[Llorean]

So any time a config file is loaded (every boot of the player) that contains settings that aren't allowed to change *from the original default* a password is needed?

This would basically mean to use the player if you changed any of these settings from the default, you'd need to put in the password every boot.

[ve4cib]

I honestly don't know if that would be the case or not.  As I said, I haven't looked at the code, so I don't know what the architectural changes would have to be to let that kind of password-protected feature lockdown occur.  I was just throwing ideas out there for discussion.

I was working under the assumption that launching a plugin and loading the plugin were two different things.  You load everything at startup, but when you actually go to execute something that's locked-down you're prompted for a password.

If, for example, you choose to lock down Solitaire you you would be prompted for a password the first time you launch Solitaire from the Games menu after booting up.  If you lock down the mpeg plugin you'd be asked for a password the first time you try playing a movie since your last boot.  And so on with every other locked feature.

[Llorean]

I was talking about the settings aspect, not the plugins aspect. You are aware that settings are saved in a .cfg file, which is then loaded upon boot, and that other .cfg files can be loaded? Thus if any setting is "protected" any time a .cfg file changed it (such as restoring your settings, every boot) it would request the password.

Not to mention, plugins really are plugins. If someone wanted to they could just download our version of the plugin here and play the unprotected version.

[ve4cib]

I'm not entirely sure I follow what you're saying...

Settings are stored in a .cfg.  Fine.  I don't see why that's an issue.  Why would you ever be prompted for a password when loading settings?  It's not the settings that are protected.  It's the actual launcher that would require the password.  Unless the radio or mpeg plugin is actually executed during startup then you shouldn't get a prompt until you actually go to the menu and launch that feature.

Not to mention, plugins really are plugins. If someone wanted to they could just download our version of the plugin here and play the unprotected version.

Plugins are plugins... yes.  Yes they are.  I don't understand your point.

And yes, to get around the password protection on a given feature you could always reinstall the system.  But to get around a compiled-out radio feature you could do the same thing.  So the level of security is the same between the two.

[Llorean]

Your original description talks about being able to disable every FEATURE, not just plugins. So I discussed it in relation to all the non-plugin features (settings being the vast majority of them).

I don't see why you're confused by this, unless you really meant "just plugins" and your earlier post was misleading.

[saratoga]

So the level of security is the same between the two.

And unsurprisingly, both will never be accepted into SVN.

[ve4cib]

Your original description talks about being able to disable every FEATURE, not just plugins. So I discussed it in relation to all the non-plugin features (settings being the vast majority of them).

I don't see why you're confused by this, unless you really meant "just plugins" and your earlier post was misleading.

I was using the term "Feature" to describe only the plugins.  I meant the "features" that get advertised to the end-user (things like radio, mpeg players, text viewers, games, etc...).  Bad wording on my part I suppose.

And unsurprisingly, both will never be accepted into SVN.

Well I guess that pretty much wraps this thread up then doesn't it?