Re: LYNX-DEV user agent?

[Personal]

Philip Webb <address@hidden> writes:
>
>980330 Larry Virden wrote: 
>> If lynx starts shipping with code to make it easy to lie about the
>> type of browser it is, and with code that is technically illegal to
>> ship from the US, you can be sure that a number of folk will drop off
>> this list as well as quit supporting and recommending lynx as a browser.
> 
>fully understood, but in that case surely you should demand
>that the option to change the user agent should be deleted from Lynx:
>that makes it easy enough for dissemblers already.
>
>however, the point at issue is whether -- given the option is there --
>it makes any further difference if Lynx allows it to be saved in  .lynxrc ,
>to which no-one has yet given a rational answer.

Philip,

I think that a rational answer has been given, but since you disagree
with it, you didn't notice it. The answer is that a line has to be drawn
somewhere on legally questionable ideas. Fote decided, and many of us 
agree, that the line lies somewhere between being able to enter a user
agent string to access a poorly coded site and saving that string for
permenant use.

I have (about twice) used the option to alter the user agent to enter
a site that was otherwise inaccessible. The need is definately there. I
don't, however, feel it is necessary to preserve that string, and it is
potentially harmfull to Lynx to do so. By such, I refer to potential legal
action being taken against the college that hosts development. (Hey, it is
my own butt on the line here!) If the college feels that lynx development
offers any potential for legal action against them, I would be ordered to
terminate such development here.

I don't know the legal issues involved. We have three choices. One is to
err on the side of caution and not implement saving the user agent. One is
to investigate and conclusively determine that there is no legal risk to
the developers or the college here in adding such a feature. The third is
to find a new development site, and add anything we want.

I personally feel that the first is the best choice because it is easy,
harmless, and works well. The second is good in that it adds functionality
that some want, but requires considerable investment of time, and potentially
money to be sure of the risk factors. I do not like the third at all, but
then I only serve as a host, and if the dev team want to go elsewhere, they
are certainly free to do so.

Please, all of you, do not feel as if I am threatening to pull the plug on
Lynx dev to get things my way. I just have an obligation to my employer to
see that their system is used in accordance to their policies, and try to
avoid any problems for them. At the same time, I want to see Lynx development
continue. As long as the two are not at odds, there is no problem. If I see
issues in Lynx development that may conflict with hosting here, it is better
for me to mention it, than to have changes introduced into lynx, and later
see lynx development ended here as a result. As I say, if the restrictions
seem too severe, the developers can freely move elsewhere with my blessings
and I'll even help to any extent I can, but it should be by choice, not by
unintentional consiquence of some other decision.

(You can also read the above as being due to me feeling guilty about having
brought up such issues with regards to ssl, and not wanting you all to think
I am a tyrant of some sort!)

Scott

Scott McGee: Salt Lake Community College Webmaster | When in danger,
___________________________________________________| or in doubt,
Email: address@hidden (Scott McGee)         | run in circles,
Web:   http://www.slcc.edu/infotech/webmaster.html | scream and shout.
----------------------------------------------------------------------
My opinions do not necessarily reflect those of the College. Trust me!