GNOME Bugzilla – Bug 123784
Lock down features (kiosk mode)
Last modified: 2004-12-22 21:47:04 UTC
Here is a list of requirements, I'll post a more detailed comment about possible implementation later. Btw you are encouraged to add your thoughts. 1 Ability to block the use from interacting with the system (panels etc). Not sure if this should be solved in epiphany, though we need at least to be able to suggest how to configure gnome to get this. 2 Ability to disable most menu/toolbars functionalities. This could be done by allowing custom xml definitions for menu and toolbars or with gconf keys that control functions or groups of functions 3 Ability to disable proxy configuration 4 Ability to disable print dialog, everything is automatically sent to the printer 5 Ability to prevent the mime action dialog from being shown when the user clicks on a file with an unrecognized type. Instead shows a dialog that says downloading has been disabled. 6 Ability to not allow to open new windows. Tabs could be allowed. The hard case here is popups. 7 Turn off about:config
*** Bug 113015 has been marked as a duplicate of this bug. ***
Havoc comment about 2 (talking for all desktop). 1. With the new GTK+ 2.4 menu system, admins can get precise menu control that way, automatically for all menus. This is how it works in KDE. Either we can say they have to edit the menu layout files, or we can have a little "override" file for each layout that lets you exclude items. This way the lockdown is tied to the layout files and doesn't get out of sync.
One important thing missing from the kiosk mode description above is the ability to prevent users from using shortcut keys, e.g. so they can't use F11 to get out of full screen mode, CTRL+B edit bookmars, etc. This might be part of #2 above, but worth mention on its own: 8 Multiple levels of keyboard shortcut/right click menu lockdown a) all shortcuts b) basic navigation only (fwd, back) c) no keyboard shortcuts & no right click menu (this lets us prevent users from spying on previous users by visiting browser history [via back button]). Ideally in this third option right click would actually be interpreted as a left click thereby mimimizing confusion for novice and left-handed users. I'm not sure what the HIG would have to say about having the right mouse button act like a left one, but it's useful in kiosk situations.
Some comments from my experience with Galeon as Kiosk: 1 I have distinguished root window from the others. Root window has no frame (always in fullscreen) and cannot be closed. New windows have root's toolbar + a close button (in case we accept new windows of course). 2 A button has be added to clear all personal informations collected during surf (cookies, password, forms, ...). This button resets the session and gets the browser back to home page. For completion, the reset action is accessible from command line. 3 Security. I have added a control over the number of windows a user can open (some sites are awful).
Created attachment 21665 [details] [review] Patch to provide hide_menubar and disable_javascript_chrome gconf keys.
Created attachment 21670 [details] [review] Patch to add hide-menubar, disable-javascript-chrome, and disable-arbitrary-url
My plan is to keep adding stuff to this patch. As soon as it goes in cvs, I'll start a new patch, of course. It's not worth it to maintain them separately since they wouldn't apply safely (because of the key list at the very least.)
Looks pretty good in general. Here some nitpicks: + <long>Hide menubar by default.</long> Hide _the_ menubar by default I guess ? I could be missing something since english is not my native language. +/* Lockdown */ +#define CONF_LOCKDOWN_DISABLE_JAVASCRIPT_CHROME "/apps/epiphany/lockdown/disable_javascript_chrome" We define conf keys on the file where they are used unless they are shared by multiple files. So this should go in ephy-window.c. + if (window->priv->is_ppview) { + window->priv->actual_chrome_mask = EMBED_CHROME_PPVIEWTOOLBARON; + } else { if style is like this if () { } else { } There are several place where you are using a different style. +void ephy_window_end_ppview (EphyWindow *window); While we are changing this I think we should do something like: void ephy_window_set_print_preview (EphyWindow *window, gboolean enabled); I think this will work better when we will fix print code. Two things that I'm not sure about: - Should we have a separate schemas file for lock down ? The main one is already pretty big ... - I tend to think it would be better to have all lock down keys in the lockdown directory. I can see the simmetry reason to have menubar hide in the general directory, but I think having all lock down keys in the lockdown directory will be more handy for people willing to setup a kiosk. Christian, do you have any comments about the patch or opinions about these last things ?
About the second part of the patch: 1 Could you explain the reason of the original_uri thing ... Arent we just setting the entry to be non editable ? 2 ephy-location-entry.c should not know about specific epiphany prefs. It would be better to have an "editable" property for ephy-location-action.c, sync it in toolbar.c with the pref and in -action.c set the entry to be not editable. Editable is also property of gtkentry, so if we need to take additional actions when it changes we can do that in ephy-location-entry.c by listening to this property changes. Though I'd need to know the answer to 1 to be more specific :)
I discussed this a bit with chpe. We think we should have a separate schemas file for lockdown and that hide_menubar should go in lockdown directory too. Also (I think I asked this already on the list) what's the use case for un-editable loc entry ? Wouldnt be enough to use a custom toolbar layout ...
I refactored your arbitrary url implementation and committed it. Please just leave your ephy-location-entry changes out when committing, I made sure there are not other conflicts, so that should be enough. I have not added the key myself to not conflict with your patch, so please commit it too.
Clahey, I'm checking in your patch with my nitpicks fixed. I hope it's ok.
Created attachment 23458 [details] [review] Adds lockdown setting for always opening new windows in tabs.
Created attachment 23647 [details] [review] Adds lockdown, including: disable_quit, disable_new_window, first_window_fullscreen
I think this patch is all that is left for a first pass. I removed always_open_in_tab in favor of disable_new_window which does the same thing as well as disable the New Window command. Running epiphany from the command line still opens a new window. first_window_fullscreen makes the first window opened be locked fullscreen. disable_quit makes it so that the last tab of the first window opened can't be closed.
Chris, should this bug be resolved now? Reassigning target in the meantime.
Marking this 2.7, since it is past feature-freeze. Hope that's OK with everyone- feel free to punt back if you think you can get it past the release team or it is actually all checked in already. ;)
Created attachment 26568 [details] [review] implement disable-quit and fullscreen lockdown I implemented those in a much simpler way; I figured the only time you want always-open-in-tabs is in fullscreen mode, and there's no need for fullscreen lockdown to instant-apply: it suffices to make this a startup-only pref.
To follow your idea, i implemented 5 lockdown features i need: - CONF_LOCKDOWN_DISABLE_FILE_OPEN: not sure if it is a gnome or epiphany feature (see save as model), - CONF_LOCKDOWN_FIRST_WINDOW_FULLSCREEN: this is an absolutly nedeed feature for kiosk. First window must be distinguished from followers, - CONF_LOCKDOWN_HIDE_EXIT_FULLSCREEN_BUTTON: in case the first window is locked, - CONF_LOCKDOWN_DISABLE_QUIT: applies only on first window, - CONF_LOCKDOWN_DISABLE_SESSION_PERSISTENCE: surf is anonymous in kiosk mode and so we don't need to memorize current configuration of the browser. I hope part of the patch will be helpfull for kiosk mode.
Created attachment 26652 [details] [review] DISABLE_QUIT FIRST_WINDOW_FULLSCREEN HIDE_EXIT_FULLSCREEN_BUTTON DISABLE_FILE_OPEN DISABLE_SESSION_PERSISTENCE
Created attachment 26654 [details] [review] slightly updated patch, fixes crashers
I don't see why you want to change it to not be instant apply when the code already handled it, but see below. Also, I don't think that you always want always_open_in_tab to be tied to first_window_fullscreen. I could see both combinations being useful. Fullscreen without tabs is useful if you want popups in new windows, but the first window fullscreen. Tabs without fullscreen is useful not so much as lockdown, but as a highly requested feature for people who really like tabs. Next, I just realized a possible solution to the problem of having the fullscreen window automatically raise. Perhaps if we have first_window_fullscreen on, all subsequent windows should be reported to the window manager as being children of the first window (or at least descendents.) Does the window manager handle this correctly and not raise the fullscreen window over them? If not, I would say that it's a bug in the wm. In this case, I could see this not being instant apply. I'm not sure if you can reassign the parent hierarchy in the window manager hints after window creation. I seem to remember that you can't. Finally, in jframeau's patch, first_window_fullscreen and hide_exit_fullscreen_button are separate tags. Why would you want these to be separate? Thanks, Chris
Chris, you are right. first_window_fullscreen and hide_exit_fullscreen_button tags are not to be separated, although I do not like the exit fullscreen button ;) Also, I use sawfish window manager for kiosks because of its windows stacking feature, that is the order in which windows are shown, from topmost to bottommost. So the first window is always the bottom most one. Is there something equivalent in Gtk ? Finally, did you think about to add a button that reset all personal data (password, cookies, history, forms, cache, ...) ? Thanks, jeff
- I checked in chpe patch because it was the simpler one and this is a last minute check in (because of feature freeze). Though I agree that fullscreen/open_in_tabs_only should not be implicitly dependent. I'm not sure about auto apply, chpe why this pref should behave differently ? - I didnt check in the open-popups-in-tabs part. Isnt that known to cause crashes in galeon ? I'm not fully sure it's the right thing to do either, but I guess I need to understand the exact use case. - chpe your patch seem to miss the schemas part. Can you please check that in ? I'm closing this bug because the original plan is completed, please open separate bugs for the remaning issues and for additional features (jeff patches for example).