[Top][All Lists]

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

lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)

From: Klaus Weide
Subject: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)
Date: Wed, 15 Dec 1999 05:32:27 -0600 (CST)

On Wed, 15 Dec 1999, Leonid Pauzner wrote:

> 15-Dec-99 09:56 Henry Nelson wrote:
> >> * Now check directly in postoptions() whether the loaded document is one
> >>   from which submission of option changes can be accepted, using the new
> >>   tracking mechanism.  Only the form-based Options Menu and Visited Links
> >                                                               ^^^^^^^^^^^^^
> >>   are allowed.  Relying on a good random generator to prevent spoofing is
> > Would someone remind me why Visited Links had to be allowed?  It *seems*
> > preferable to not have the Options Menu show up there.
> Perhaps you have not visited "Visited Links":)
> in recent dev.XX - it now have a tree-like presentation
> and switch for layout type near the top.
> This choice also available via forms-based options menu.

Yes, the reason is that I didn't want to break that.
I could have just pretended I didn't know anything about special
needs for Visited Links (it isn't documented anywhere), and let Ilya
fix it.

Ilya added that layout choice popup at the top of the Visited Links
page, which expects access to the form-style Options Menu code without
going through the Options Menu itself.  Apparently he didn't pay any
attention to the "secure_value" stuff.  He didn't need to - it worked
without.  Which demonstrates howe useless the "secure_value" stuff was
for spoofing protection.  Ilya could "spoof it" just fine (probably
without realizing that that's what he was doing).  (Hence the need for a
different mechanism; hence my patch.)


Relying on rand() for security is really a bad design choice, IMO.
Unless you can guarantee that the random number generator of the system
is "good" maybe, AND you understand all this stuff (psudo-random number
mathematics and algorithms, cryptography...) well (I certainly don't).
Otherwise it may just *appear* to solve a problem which can be solved
differently, giving people who *do* understand how to exploit weak
reandom numbers still a way in.

This also goes for using random numbers for temp file names - the
mechanisms for guaranteeing opening new files that "we own" should be
reliable without resorting to this (and I though that they *do* work, on
a normally configured Unix-like system).  Personally, I find the
predictable temp file names more convenient for debugging.  If we can
have predictable filenames and still be safe, I see no reason why we

> Unfortunately this item is not saved in .lynxrc
> which is a pain: I do not like the new presentation
> but could not switch back permanently.
> IMHO, reverse historical order is rather intuitive
> when I need a near history (2-3-4)
> while the tree-like presentation may be useful for
> pages deep in history [but it looks ugly anyway
> since the display size is limited: many links
> does not fit into one line, and we need scrolling
> up and down to look around - it was only one direction
> previously].

I am not a fan of the new Visited Links display either, so far.
The few times I've used it, I was confused by it and ended up switching
the mode to what seemes to come closest to the previous style.

So for me, the old order was intuitive, while the new default isn't at
all (but I haven't invested much time to discover its logic).


Changing the Visited Links style with the popup on the V.L. page works
even when the key-based Options Menu is selected (with the -forms_options
switch, for example, if key-based isn't already selected by default).
This is a bit surprising.  It could be regarded as another hole.

But that only applies if both types of Options Menus are compiled in.
If only key-based is compiled in, the popup will still appear on the
V.L.  page but it's worthless - you can select, but submission will
fail.  (This is untested, but it's an obvious consequence of relying
on postoptions() and the LYNXOPTIONS: URL scheme for processing the
submission.)  IOW, A user of Lynx compiled only with the old-style
Options code (which so far has always been *the safe thing*, IMO,
despite some people claiming that the key-based Options Menu is
obsolete) has *no way* to set the Visited Links style to the
accustomed behavior, not even for the current session.

Obviously, this ought to change.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]