Re: Kiosk mode

[Christopher James Lahey <clahey ximian com>]

On Thu, 2003-11-13 at 17:32, Christian Persch wrote:Hi,
> > 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.

I'm not too tightly bound to this idea at all.  Disabling unsafe
protocols would be perfectly fine.

What do we do about javascript?  I could easily see people wanting it
for use within the browser, but not wanting people to be able to type it
into their location bar.  Particularly if they've restricted their proxy
to keep things within their network.

How will we allow the user to configure this?  Have a list of protocols
that they turn off, or just have a boolean to turn off "unsafe"
protocols?

> > url_deny
> What's the use case for this, and how is it different from url_allow ?

I put this in for completeness to some degree.  It's the opposite of
url_allow.  If we don't both with url_allow, then this is totally
pointless.

> > 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.

Which bit did you mean to see below here?

> > enable_printing
> Needs a way to specify default options like printer name/paper size
> settings etc.

Ah, I assumed that these options were in gconf.

> > 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.

I assumed.  So, this might be a useful key, depending on discussion
below.

> > 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?

Well, firstly chrome changes from js are a separate issue, as someone
brought up.  I'd be fine with immutable_ui for this.  I see this as
separate from disabling toolbar editing.

> > 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?

My presumption was that some users would want to disable tabs to
simplify the UI.  I'm not attached to this one at all.

> > enable_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...

I agree in general, but since the point of the discussion is a kiosk
mode, it is important for the sysadmin to be able to turn off access to
these.  I've seen lots and lots of places running netscape 4 or IE with
all of the menus off, and if epiphany doesn't allow that, then they will
stick with what they have.

> > 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?

For a kiosk this makes total sense.  The difference between this and
allow/deny_url is that in this case the user doesn't even have UI for
typing in a URL.

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

I added this because of some notes about Privacy in the bug about kiosk
mode.  They said one of the things they wanted was the ability to turn
off back/forward, for instance, so as to not be able to see what a
previous user was browsing.

> > Some things to note:
> > 
> > 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".

I agree that immutable_ui is probably a better solution for this,
particularly since it can be used for normal users to make it so that js
can't turn off their toolbars and menus.

> > 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.

For me it would depend on which key and how much work.  When it's a huge
amount of work, I agree it's not worth it, but when we can, it'd be cool
if we made it work.  Not super attached to this.

> > 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.

Ah, this is why I put reset session there.  But you make good points
about that reseting history and trails and cookies and so forth.

> We also should differentiate between not persisting user-made changes
> [tb/bookmarks/ui/etc] and not allowing them outright.

A cool idea.  Wouldn't this add a fair bit to the implementation
though?  Or would you just have the reset button optionally set all of
these back to their defaults?

> 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 don't mind the proxy idea so much.  I was more worried about about:
and file: and such, but if you say it's easy to turn those off, I will
trust you.

When it comes time to add this unsafe urls code, would you be willing to
do that bit at least?

Thanks much for the comments,
   Chris