|
|
| Author |
Message |
| 25 new of 92 responses total. |
remmers
|
|
response 45 of 92:
| 
Mar 14 21:27 UTC 1999 |
(It didn't clickify it due to length. But you can probably copy & paste
into into your browser's "go to" box.)
|
aruba
|
|
response 46 of 92:
|
Mar 15 00:07 UTC 1999 |
John, could you give us an example of what kind of attacks you're worried
about? My apologies if you already did and I've forgotten.
|
dpc
|
|
response 47 of 92:
|
Mar 15 01:48 UTC 1999 |
Could we limit sexually explicit HTML graphics to the sexually explicit
conferences? 8-)
J/K. I'm not sure we should allow graphics at all in items
and responses, actually.
|
other
|
|
response 48 of 92:
|
Mar 15 03:35 UTC 1999 |
I have proposed a specific set of solutions to handling html tags in
grex's conferences, and i would very much like to know what issues of
concern it fails to address, aside from that of grex regulating the
content of audio and image data. since we don't much regulate text
data, i don't imagine we need to code such regulation into backtalk,
although we should discuss a policy addendum for handling complaints
about data content on a case-by-case basis. this would be the necessary
planning for eventualities such as the linking of sexually explicit
images or otherwise offensive (to some) image or audio files to grex
conference postings.
Let me summarize my proposed solutions. Please address the ways in
which they do not address the aforementioned concerns. Otherwise,
please feel free to propose alternate solutions. Keep in mind that
unless we focus on finding solutions which address the particular
concerns we present, we are not moving the discussion toward a
satisfactory conclusion.
1) Allow backtalk users to define new items as either plaintext or html
at the time they are entered, by the user entering the new item.
2) Allow backtalk users to specify a preference to either display:
A) only items entered as plaintext
B) all items, regardless of format, displayed in the format in which
they were entered
C) all items, regardless of format, but displayed only in plaintext.
These settings would allow users to specify how they see grex conference
postings, and allows those who are opposed to html postings to
automatically ignore any items entered as html. All settings would be
user-changeable (except item definition) at will, and ignored html items
would be treated as simply forgotten, so they could be manually
'remembered' if the user desires.
|
other
|
|
response 49 of 92:
|
Mar 15 03:37 UTC 1999 |
the above assumes that all items either entered or read through picospan
would be treated as plaintext.
|
devnull
|
|
response 50 of 92:
|
Mar 15 04:27 UTC 1999 |
What would people think of having two agora-like conferences, one of which
would have all the html features enabled, and people like me wouldn't bother
reading at all quite likely, and another one with no html features enabled?
|
srw
|
|
response 51 of 92:
|
Mar 15 19:56 UTC 1999 |
Eric is proposing that the HTML feature be established for each item.
Currently it is allowed by conference, and turned on for each response.
Doing any of this per item is a different approach than the one we've
taken so far. I'm not very compelled by the benefits.
This feature is an important feature for backtalk because there are
competing programs that offer it, and we get requests for it. Other
licensees of backtalk are generally very different from grex, though, so
there is no a priori belief on our part that this feature would be best
for Grex.
I agree with Remmers that enhanced text display, and hyperlinks would be
advantages. We have hyperlinks already, but HTML would allow hypertext
where the word is the link, rather than the URL.
I think inline images could be useful, but clearly they could also be a
vulnerability. Out of curiosity, I'd like to see it here, but I don't
have a good answer for worries about inappropriate images. Even sounds
may have some use, perhaps in the music conference.
Tags can be turned on or off individually within backtalk. It's easy
(for me), although it has to be done in the code. There's an implied
argument in that statement that it would be a good idea to allow it to
be done with a site configuration, but that's not planned.
|
janc
|
|
response 52 of 92:
|
Mar 16 15:37 UTC 1999 |
Here's a link to John's musical response in the backtalk test
conference:
http://www.grex.org/cgi-bin/pw/bt.new/peek:8,38
Backtalk currently allows EMBED but no BGSOUND. I'd personally be happy
to see EMBED go away.
Maybe we need to find ways to do at least per-site configuration of what
tags are allowed. Per conference configuration is a bit harder.
|
toking
|
|
response 53 of 92:
|
Mar 17 17:03 UTC 1999 |
and I quote:
conference 8 does not exist
|
mwg
|
|
response 54 of 92:
|
Mar 17 18:10 UTC 1999 |
If any form of HTML is to be allowed, a means of blocking the whole mess
would be a good idea. I've mentioned that, in the past, the
controllability of the responst had an inverse effect on the content, HTML
would likely result in messages with less than no content, if that makes
any sense. I really think that flat text is the best way to run a
conferencing system, and the increased formatting control of HTML is not
just asking for problems, it just about forces them to happen.
If HTML is not to be avoided completely, a user-settable ability to block
items/conferences/whatever containing it should be available.
I still hold that avoidance of HTML is the sane course, give that whatever
credence you will.
|
pfv
|
|
response 55 of 92:
|
Mar 17 18:37 UTC 1999 |
I agree:
The ability to accept boldness/fonts is one thing,
author-specified colors and images are another.
yer back to what I said earlier. been There, thought That.
|
dpc
|
|
response 56 of 92:
|
Mar 18 15:09 UTC 1999 |
I'd also appreciate an HTML-blocker.
|
janc
|
|
response 57 of 92:
|
Mar 21 18:51 UTC 1999 |
Ugh. I misentered the URL above. Should be:
http://www.grex.org/cgi-bin/pw/bt.new/peek:backtalk,8,38
|
janc
|
|
response 58 of 92:
|
Mar 21 19:20 UTC 1999 |
What exactly would an "HTML blocker" show you instead of the HTML
formatted output? A "plain-text" version, like what Picospan users see?
Or should it just make all such responses hidden?
Personally, my inclination is to turn the thing on and then fix problems
that actually appear, instead of trying to fix all the problems people
imagine might exist.
We went through a huge agonizing discussion about enabling anonymous
reading, with lots of people worried about how it would change or
destroy the spirit of the conferences. I implemented a "shylist"
feature, enabling people to filter their responses so anonymous readers
wouldn't see them. There are now five people on the shy list, one
reaped, one who has never posted a response to any conference, and one
who has posted exactly one message which contained six words and four
punctuation marks. The other two are fairly active participants. The
shylist was worth implementing as a nod to feelings of people who were
worried about anonymous reading, but in retrospect the whole frabble was
over a problem that never actually materialized.
My personal theory is that all the theories above about how HTML will
lead to disaster will not turn out to be correct. However, I have no
evidence at all for this theory. I am not enthusiastic about doing a
lot of coding to address problems that may or may not happen. I'd much
rather TRY IT, and if there are problems, FIX IT.
I've got a dozen different people with different worries and concerns,
and different ideas for what I should do. I can't code to that spec.
|
mwg
|
|
response 59 of 92:
|
Mar 21 23:02 UTC 1999 |
You can only do what you see as reasonable, we can toss in input, but in
the end, the staff makes the decision.
The reason I am arguing so hard against this is that the nearest
equivalent to this issue that I have direct experience with, that of color
text on the old dial-up BBSes, has a known and predictable consequence
that I do not want to see repeated here. If HTML can be useful, people
can chuck a pointer in thier responses to a real web page for things like
diagrams.
If HTML gets permitted, just make sure that there is a stripped
translation used for non-browser types. If the past is any guide, such
stripped posts will be fairly obvious from thier 'content'. The other
point, be sure that the support can be easily turned off, should it prove
necessary.
|
aruba
|
|
response 60 of 92:
|
Mar 22 00:16 UTC 1999 |
Re #59: Grex policy decisions are not up to the staff, though the staff of
course has to make decisions if no one else speaks up. But any policy issue
may be put to a vote if a member asks that it be so.
|
scott
|
|
response 61 of 92:
|
Mar 22 11:59 UTC 1999 |
There actually are some color responses out there, in the older conferences.
|
mwg
|
|
response 62 of 92:
|
Mar 23 14:54 UTC 1999 |
In the far past, people would occasionally bury hard-coded cursor controls
for VT100/ANSI terminals in thier responses. This could be amusing if you
had the right terminal, but otherwise you saw garbage, and in some cases
your terminal could end up in a not-very-useable state. The best 'cursor
dances' operated entirely on spacing and backspace control.
Cursor dancing doesn't work well these days because most people connect at
higher speeds than this sort of visual fiddling is effective at.
|
remmers
|
|
response 63 of 92:
|
Mar 23 16:12 UTC 1999 |
(For an "HTML blocker", would it be feasible to put in a
user-configurable option of always being shown the plain-text version of
responses? Since a plaintext version will always exist, and since
Backtalk will show that to the user anyway in the cases where there *is*
no HTML version of a response, it doesn't seem like it would be hard to
show that to the user in all cases.)
Re resp:58 - I remember quite well the debate on anonymous web reading,
which got a heck of a lot more heated than this discussion has. I
favored anonymous web reading and thought the whole controversy was a
tempest in a teapot. And indeed, it's had just about zero visible impact
on Grex.
Unlike anonymous reading, which is invisible to users (almost by
definition), HTML would have a visible impact on every user of Backtalk.
There's an aspect of it that makes me nervous: The <IMG> tag makes it
very easy to embed images that are stored on any web server on the
internet. And unlike fancy formatting, which takes some work, putting
images into responses can be done casually, by typing a few characters.
And there are a lot of images out whose posting could have legal
implications. I'm concerned that support for <IMG> might (note that I
say "might", not "would") result in a substantial number of problematic
images (sexually explicit, copyrighted, illegal, etc.) popping up in the
conferences.
Only two people responded to my earlier question about what we should do
if this happens: Joe Parish, who said he would simply censor such images
(which as it happens, fairwitnesses can't do in Grex's version of
Picospan), and Steve Weiss, who said he didn't know how it should be
handled. Any other takers?
Generally speaking, I favor Jan's "TRY IT, and if there are problems,
FIX IT" approach to things. Thing is, I can see three possible fixes to
the "problematic images" problem, should it arise:
(1) Ignore it. Grex doesn't censor, so just leave the images there.
(2) Have cfadm censor them, following some established appropriateness
criteria, and report the poster to their ISP. This would mean we would
have the staff "policing" the conferences, similar to the way we now
police for vandals and mail spammers).
(3) Disallow images by having Backtalk filter out <IMG> tags, on the
grounds that preserving Grex's open, unpoliced, and uncensored style of
conferencing is more important than the ability to jazz up responses
with pictures.
Which of these three fixes do folks favor? Can anyone think of others? I
know I strongly favor (3). I think (1) is ruled out as a general policy
for legal reasons, and I would REALLY REALLY REALLY hate to see policing
spread to the conferences. That leaves (3). Do other people feel the
same way? I have no more evidence that a problem will arise than Jan
does that it won't, but I'd feel more comfortable going into the HTML
posting era if we have a concensus beforehand on how we would react to
this particular problem, should it arise.
|
jep
|
|
response 64 of 92:
|
Mar 23 19:58 UTC 1999 |
I favor 3. The likelihood of problems seems high. Maybe an option
could be given to fw's to allow IMG tags to operate in their
conferences, which might allow for some interesting specialty
conferences to arise.
|
scott
|
|
response 65 of 92:
|
Mar 23 21:53 UTC 1999 |
I like option (3) also.
|
scg
|
|
response 66 of 92:
|
Mar 23 21:57 UTC 1999 |
I think option 2 may have some legal problems, in that if we make it a policy
that staff will go through and edit out illegal content, then we may be in
trouble if the staff misses something.
|
janc
|
|
response 67 of 92:
|
Mar 23 22:27 UTC 1999 |
Looks like we want to allow fairwitnesses to turn off HTML images in
conferences, without necessarily turning off all HTML. (Currently
fairwitnesses can either turn HTML off completely or on completely.)
Is that what most people are looking for?
Note that if I implement this the easy way, then if you have HTML images
turned on, and then turn it off, the old posted images will not go away.
They will still be there, but you won't be able to post new images. The
rules are enforced at the time of posting, not at the time of reading.
This means that fairwitnesses will always be able to post images, simply
by turning it on long enough to make the post (just as fairwitnesses
currently can always post to frozen items, by thawing them long enough
to make a posting).
|
aruba
|
|
response 68 of 92:
|
Mar 23 22:31 UTC 1999 |
Is it illegal to put a link on your web page to something that's copyrighted?
|
cmcgee
|
|
response 69 of 92:
|
Mar 24 00:30 UTC 1999 |
I like 3 as well.
|