Re: Kiosk mode

[Matt Hughes <mhughe uvic ca>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher James Lahey wrote:
| 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 don't think regex'ing urls is worth the trouble; people can probably
find ways to get around it, and a proxy does a better job anyway.

I think these are a requirement though:

file_protocol_disable
default: false
Usage: If true file:/// protocol urls are not loaded.


about_protocol_disable
default: false
Usage: If true about: protocol urls are not loaded.

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

Most kiosks will want to turn off the location bar. But for cases where
the location bar is kept around:

user_javascript_disable
default: false
Usage: If true, prevents the user from executing javascript in the
location bar or javascript console.


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

Ok, as long as clicking on unknown mime types (i.e. types without a
plugin or handler) produce a "downloading disabled" dialog.

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

They are: /apps/epiphany/dialogs/print_*

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

Bookmarks go in a file. ~/.gnome2/epiphany/ephy-bookmarks.xml

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

In kiosk situations, we use a single full screen window and we use tabs
for everything. We found that as long as the tabs are brightly coloured
(i.e. choosing a appropriate theme), users figure out how to use them
pretty quick.

There is another, less restrictive case is a kiosk where multiple
applications are allowed. In this case, both tabs and windows are allowed.

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

Yes, turning off unnecessary UI elements is critical. Most kiosks will
be used by people who have very little computer experience, not GNOME2
hackers. For inexperienced users, it's better to just remove the items.
They won't know what they are missing.

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

Yup, removing the location bar entry is important for kiosks.

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

Yes, this is important. The case for this is a kiosk used for
registration or something, where the user fills out a form and submits
it, and recieves a printed output automatically. All navigation must
take place via links on the pages.

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

Yeah, kiosks will be configured well before and the configuration will
not (generally) change while someone is using it.

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

Session resets probably don't belong in the browser. There may be a few
other applications that run in kiosk mode, and their settings may need
to be cleaned up as well.

It is important to clean up cookies and so forth, but it's probably
better to do this in scripts. The user can exit the browser to indicate
end of session.

Often kiosks run in fullscreen mode with no menubar, only a toolbar. To
allow users to exit the browser (indicating end of session), we added a
exit button to the toolbar (in Galeon). A similar button on the Ephipy
toolbar would be nice.

The only other concern I have is turning off keyboard shortcuts. See
http://bugzilla.gnome.org/show_bug.cgi?id=123784

Thanks.

- --
~ Matt Hughes
~  + mhughe uvic ca
~  + "Were there monkeys? Some terrifying space monkeys maybe got loose?"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/tSQk+lbvw5408osRAqciAJ9CBtX696qMKw+hq8ODBIGxDi2/GwCdHgeY
o4xvqBV6sdDQWA6dRMU2I1M=
=9qrM
-----END PGP SIGNATURE-----