lynx-dev restrictions logic (was: proposal for LYK_SCRIPT and patch)

[Klaus Weide]

On Mon, 5 Jul 1999, Henry Nelson wrote:

> Again, off topic, Klaus, (and I should have discussed it at the time)
> but what you did with CAN_ANONYMOUS_VIEW_LYNXCFG_INFO and the others
> seemed like "overkill" to me. I know you are strictly correct, but for
> some reason I just cannot imagine anyone running -anonymous to possibly
> want to advertise the organization of their file system, or allow
> pretty much anyone to deduce what operating system is on the machine.

Frankly, I don't care that much about how useful any specific combination
of settings is.  What I did care about was the general model, which I saw
as being subverted. :)  Or perhaps "in decay" is a good metaphor.

Not that I use restrictions much.  But, after ignoring the topic for
years, I had reason to look at how "all that stuff" is implemented and
how it's supposed to work, and I found that another level of exceptions
had been added, which made it more complicated to understand.  Not a
systematic attempt to replace an older, too complicated way (I would
disagree) of doing things with a new simpler way, just what looked
like a rotting away of support for some options that have
(apparently) fallen into disuse and obscurity... (-restrictions,
-validate...)

There is no one "anonymous" boolean setting in Lynx.  The -anonymous
flag just translates into detailed restriction flags, and they are what
is used in the code, and can be set individually as well.  That's a
powerful model, I don't understand why anyone would want to get rid of
it once that's understood - even if you don't actually use most of it.

There was an attempt to make -anonymous act as some generic restriction
flag, in addition to its action of setting a default set of detailed
restrictions.  That means some features would be controlled by the
part of -anonymous that translates into detailed flags, as before, while
other parts are controlled by -anonymous directly.  There were various
problems with it, and it made things just more complicated.

> Would you mind setting me straight here why it is so important for
> -restrictions to be available for anything under -anonymous.

It's "important", in my opinion, because it is the documented behavior,
and because it's better in the long run to be consistent.  (Or at least
make things not *more* inconsistent than they already are...)

Control for the new features didn't seem to fit under any of the available
detailed restrictions, so I made up some new ones.   They seemed
appropriate to me, of course you may disagree and make a patch to combine
them or subsume them under other restrictions.

> IOW, what's
> wrong with assuming, for the sake of simplicity, that some "features"
> are incompatible with public access and should just be turned off period?

What's right with taking choice away, just because you don't see a need
for the flexibility?  Anyway, I don't really understand for whom "just
turning off period" would provide more simplicity.  It's not that invoking
lynx "anonymously" has become any more complicated.  That's the beauty
of the -anonymous shortcut...

There are now three or four more options in userdefs.h that can be
changed.  I don't think that's overly complex.  Also, I don't provide
restricted lynx access to anyone, so I can't really speak for that -
but I assume if I did, and had somehow become aware of those new features,
I would be wondering whether they are all turned off for the anonymous
account.  Now I can read about it (and even change it), in the place where
I already have to look anyway, instead of looking all over the place.

> (Granted there is a need to document what the -anonymous command line
> switch does turn off.)

And documenting it becomes just much more complicated if some restrictions
are handled differently from others.

  -----

As for CAN_ANONYMOUS_VIEW_LYNXCFG_INFO you specifically mention -
well, I can imagine that someone feels secure enough about the
security of their system that revelation of a few file paths
in lynx.cfg wouldn't hurt it.  While perhaps allowing users to
provide more meaningful bug reports. (In an ideal world LYNXCFG:
would be used for this...)  Have you actually checked how much
or little setting of CAN_ANONYMOUS_VIEW_LYNXCFG_INFO (but not the
others) reveals?   And you don't even have to actually change
it in userdefs.h and recompile to check this out, since you can
just explicitly set the combination of -restrictions flags that
you want to check. :)  (Not using "default" or "all", of course.)

And, really, the name -anonymous is misleading in my opinion.
That sounds like it can only be used for anonymous accounts.
I can think of other uses (say, I feel paranoid about "not touching
anything" on an unfamiliar system, so I set restrictions for myself).
Admittedly unusual, but why exclude the possibility if all the parts
are already there?

  -----

Yes, It seems the -restrictions= model is too flexible for nearly
everybody's needs.  But can something really be 'too flexible', as
long as it remains easy to use?

  -----

For the longest time, the whole area of restrictions seemed much more
complicated to me than it really is, and one big reason for that is
that it would usually be discussed in terms of "anonymous accounts"
and the -anonymous flag (but not restrictions) - in documentation,
comments, lynx-dev messages, by the few in the know.  I always felt
I didn't have the understanding of the kind of setup involved, to
make sense of it.  Now that I know that -anonymous is just a set of
"restrictions", there is no mystery any more, it's all quite simple.

I see a more general lesson here (in case anyone cares): don't name
options according to what you think they are good for, but according
to what they do.  With lynx, the worst offender imo is -validate.
The -help used to say just
    -validate        accept only http URLs (for validation),
does 'validation' clarify this flag's purpose really for anyone?
Maybe it's just me, but it never made sense to me (and was a
deterrent to trying to understand what it does).

Henry, you see I can get off topic just as well as you...

   Klaus