Re: Kiosk mode

[Christian Persch <chpe stud uni-saarland de>]

Hi,

On Fri, 2003-11-14 at 18:19, 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'm not too tightly bound to this idea at all.  Disabling unsafe
> protocols would be perfectly fine.
Yeah, let's just disable internal/unsafe protocols [data: about: file:?]... or
the other way 'round, _en_able only known safe ones [http: https: ftp:]
?

> 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.
If the proxy doesn't let the user go to some page, it doesn't matter if the
user typed it directly/had a link in a page/did it via js, does it?


> > > 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.
Yes, I think we should let the proxy handle this restriction.

> > > 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.
Hm, they are in gconf, but we they're loaded via the print dialogue, so
if that one's not shown they don't get loaded... Will
libgnomeprintification make this easier?

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

> > > 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.
There is a gconf key for toolbar showing, if it's not writable we could
make this insensitive for the user, as well as make it impossible to
change from js. Same really applies for all things where gconf keys
exist.

> > 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.
I'm not totally against it, only questioning its value :)

> > > 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.
I'm not against setting the items insensitive, only agains not showing them
at all.
The only thing I could find on this in the HIG is
http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-locked
which only is about dialogues, where they set the controls insensitive,
but still show them.

> > > 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.
I think this is unnecessary, the same can be achieved with
no-toolbar-editing + a custom toolbar layout.

> > > 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.
Makes sense. Also there are some web applications which internally keep
track of where you are and get confused when you use nav buttons instead
of the page's links.
Ok.

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

> > > 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.
Everywhere's no performance penalty in the non-lockdown-mode case we can do 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?
That's simply a matter of an early return in some _save functions.

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

Regards,
	Christian.