Re: Kiosk mode



Hi,

On Thu, 2003-11-13 at 19:36, Christopher James Lahey wrote:
> I've been looking at epiphany and thinking about what sort of things
> we'll need for a kiosk mode.  I reread the thread from a couple of
> months ago and have started to quantify what I think we need.  I've come
> up with a few keys I think we should implement.  Please comment on
> these.  Especially comment if you've thought of any other keys that I
> haven't commented on.
>
> Thanks.
> 
> url_allow
> default: ""
> Usage: If non-empty, all urls will be checked against this regexp.  If
> they don't match, then they won't be displayed.  If possible, I'd like
> to make it so that this regexp must match the beginning of the url so
> that people can't view urls like 'javascript: whatever(); "print
> http:";'
> Possible suggested values: "http:", "http:|ftp:", "http:|ftp:|file:",
> "http://mylocalwebsite/";
I think this is overly general; some sites use javascript even for
normal links, and anyway you can just disable javascript outright. And
any link can be obfuscated so the regexp won't catch it, so this doesn't
provide what you expect.
In lockdown mode we should simply disable unsafe protocols like about:
(with the exception of about:blank), no regexp needed.

> url_deny
> default: ""
> Usage: If non-empty, all urls will be checked against this regexp.  If
> they match, then they won't be displayed.  No ^ will be prepended.
> Possible suggested values: "^about:", "^file:"
What's the use case for this, and how is it different from url_allow ?

> enable_save_to_disk (Perhaps this should be a global gnome setting?)
> default: true
> Usage: If false, the user will not be able to save data to disk.  This
> will disable Save As, Save Background As, and Download Link, as well as
> the download option for unknown urls.
See below.

> enable_execute_arbitrary_commands (This should probably be a global
> gnome setting?)
> default: true
> Usage: If false, the user will not be able to execute arbitrary
> commands.  The main place that I know of that this would currently
> affect things is the print dialog.  The print dialog shouldn't contain a
> command line anyway, but until that's fixed, this key should disable
> printing.
Ok.

> enable_printing
> default: true
> Usage: If false, the user should not be able to print at all.
> enable_print_setup
> default: true
> Usage: If false, the user will not be able to set any print settings. 
> File->Print and javascript printing will just cause the default settings
> to be used.
Needs a way to specify default options like printer name/paper size
settings etc.

> 
> enable_bookmark_editing
> default: true
> Usage: If false the user will not be able to edit bookmarks.  I would
> prefer not to have this key and simply have the ability to lock down the
> tree of gconf keys for bookmarks and have epiphany notice that said tree
> is locked down, but I'm not sure if that's possible.  This would cause
> all menus involved in bookmark editing to disappear.
? There are no gconf keys for bookmarks.

> enable_toolbar_editing
> default: true
> Usage: If false the user will not be able to edit the toolbars.  I would
> prefer not to have this key and simply have the ability to lock down the
> tree of gconf keys for toolbars and have epiphany notice that said tree
> is locked down, but I'm not sure if that's possible.  This would cause
> all menus involved in toolbar editing to disappear.
Why not simply immutable_ui, which disables tb editing as well as chrome
changes from js?

> enable_tabs
> default: true
> Usage: If false, epiphany would not have the ability to use tabbed
> browsing.
What has this go to do with lockdown? If max_window_count is > 1, does
it matter if the user opens those in new windows or as tabs?

> At least one of the following two.
> 
> enable_new_window
> default: true
> Usage: If false, epiphany would not have the ability to open a new
> window.
> 
> max_window_count:
> default: 0
> Usage: If non-zero, the maximum number of open windows allowed.  Set to
> 1 to disallow new windows.
> 
> enable_quit
> default: true
> Usage: If false, the user would not be able to quit epiphany.
> 
> enable_menus
> default: true
> Usage: If false, there would be no menus.
Why? There are useful things in the menus even when locked down, like
changing page encoding. Also I think menus/menu items/dialog elements
should _never_ disappear, but simply made insensitive when the
corresponding action is unavailable. The user may use Epiphany also in
other environments where no or different lockdown prefs are applied, and
nothing is more frustrating for users than knowing where sth is in the
menus but having it disappear...

> enable_arbitrary_url
> default: true
> Usage: If false, the user would not be able to browse to an arbitrary
> URL.  This would include making the location bar disappear and disabling
> C-l.
The location bar is also there for the user to _see_ where he is, why do
you want to take that away? Also, how is this differentiated from
allow/deny_url?

> enable_navigation
> default: false
> Usage: If false, no navigation other than clicking on links would be
> allowed.
Why?

> Some things to note:
> 
> We don't need a key for disable proxy set up.  That will be done by
> locking the keys for proxy set up.
> 
> Fullscreen mode already has a key, but if that key is locked true, then
> the "Exit Fullscreen" button should not appear.
> 
> Show toolbars already has a key, but it can be overruled by javascript
> and doesn't apply in full screen mode.  These facts either need to
> change, or we need a second key which, when false, disables toolbars
> always.  Also, if said key is locked, the checkbox should disappear from
> the View menu.  Similar things apply to show menus and show statusbar.
See above for "immutable_ui".

> Ideally, these should all be active keys.  If they change, then the UI
> should immediately change.  This is important so someone setting up
> their kiosk wouldn't have to keep restarting epiphany.  Not sure how
> difficult that would be for some of them.
Not worth it IMHO.

> Not a key, but we should add a reset session command.  Probably in a
> menu and also available as a toolbar button.  The sysadmin could then
> set up reset session in their toolbar.
Yes.

----

You completely forgot the user's privacy: In a shared environment, we
need to not save passwords, disable cookies or re-set their lifetime to
a short time (~1h), not persist history, make history items lifetime
short too, make it a 1-click operation for the user to clean out all his
trails.
We also should differentiate between not persisting user-made changes
[tb/bookmarks/ui/etc] and not allowing them outright.
And with respect to content, I can see the worth of having a simple way
to only allow browsing to _one_ location (http://mysite/*), but if the
desired lock-down includes which content should be viewed, they should
set up a proxy to do so, not have it in the browser.

I wanted to say more, but I forgot what it was :/

Regards,
	Christian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]