rjh@cs.purdue.EDU (Bob Hathaway) (04/08/89)
[This is a comment on RFC 1097, which provides a standard for sending and receiving subliminal messages across the internet. Since newsgroups are a potential victim of subliminal messages, I'm cross-posting this article.] I sincerely hope RFC 1097 is a joke, subliminal suggestion is a devious and underhanded way to influence people into taking actions or adopt ideas without their consent. People should be afraid to look at terminals if there is a possibility subliminal messages are being sent. Why isn't this practice illegal? I vote for a complete banning of subliminal messages from any electronic medium and propose for now a banning of subliminal messages across the Internet. Subliminal messages are a dangerous threat to our security and the integrity of the Internet. From rfc 1097: > >4. Motivation for the option > > Frequently the use of "Message of the day" banners and newsletters is > insufficient to convince stubborn users to upgrade to the latest > version of telnet. Some users will use the same outdated version for > years. I ran across this problem trying to convince people to use > the REMOTE-FLOW-CONTROL Telnet option. These users need to be gently > "persuaded". > Persuading users without their consent? Do we really want system administrators and programmers to secretly influence us to use their latest fad software or worse? This is absurd. > 1. Server suggests and client agrees to use SUBLIMINAL-MESSAGE. > > (Server sends) IAC DO SUBLIMINAL-MESSAGE > (Client sends) IAC WILL SUBLIMINAL-MESSAGE > (Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Use VMS" IAC SE > > [The server is "suggesting that the user employ a stable > operating system, not an unreasonable request...] VMS is a proprietary operating system, this tactic should not be used. Any software producer could subliminally suggest we use their software. This is an unconscionable and underhanded means of influencing people and selling products. In my opinion, subliminal messages are a direct, unconscionable, and flagrant violation of our civil rights and should be banned immediately. So, 1. I am preparing another RFC to ban subliminal messages from passage across the Internet. I wouldn't give subliminal messages the respectability of an RFC, and think we should replace the existing RFC 1097 by a new RFC banning the practice, not just obsolete RFC 1097. I believe this is necessary to maintain the respectability of the Internet. 2. How did this RFC ever get adopted? If this adoption practice is carried out in private, I vote RFC's should be posted for public discussion first, perhaps in comp.protocols.tcp-ip. Bob Hathaway rjh@purdue.edu Seen in a .signature recently: The price of freedom is eternal digilence.
dpz@pilot.njin.net (David Paul Zimmerman) (04/08/89)
I think somebody missed the joke ... for anyone interested in submitting an RFC titled "Requirements for Internet Users", please contact me :-) David -- David Paul Zimmerman Rutgers University dpz@pilot.njin.net rutgers!dpz dpzimmerman@zodiac.bitnet
tim@hoptoad.uucp (Tim Maroney) (04/09/89)
Jeez, we better not less this Hathaway guy read any Padlipsky. He'd probably blow a gasket. Anyone interested in a SENSE-OF-HUMOR TELNET option? Unfortunately, it seems the usual response from some people to an IAC DO SENSE-OF-HUMOR would be IAC WONT SENSE-OF-HUMOR. Or perhaps we should add a CANT opcode to option negotiation.... -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Those who restrain desire, do so because theirs is weak enough to be restrained..." - Blake, "The Marriage of Heaven and Hell"
skl@van-bc.UUCP (Samuel Lam) (04/09/89)
In article <8904081252.AA03712@alanine.phri.nyu.edu>, roy@ALANINE.PHRI.NYU.EDU (Roy Smith) wrote: >Uh, yeah Bob, I think it was a joke. Did you notice the April 1st date >on the RFC? You are of course correct about the evils of subliminality >but I wouldn't be surprised if some hackers out there have already worked ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >support for 1097 into their telnet clients and servers. Perhaps it was ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >a joke taken too far, but rest assured that it was a joke. Well, at least they wouldn't be able to implement RFC1097 "to-the-letter". :-) RFC854 says the TELNET option code is one-byte long. Now, someone would have to be pretty creative to figure out how to jam the decimal value 257 into that poor byte. :-) (Of course, "byte" means octect in this context.) (I admit that I wasn't totally convinced about it being a joke until the 257 came along. :-( ) -- Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl
mckenzie@bbn.com (Alex McKenzie) (04/10/89)
Bob, Better check RFC 748 for another bad idea. Alex McKenzie
bob@oz.cis.ohio-state.edu (Bob Sutterfield) (04/10/89)
(In the voice of Foghorn Leghorn:) "That's a joke, son!"
mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) (04/12/89)
Alex -
As the author of RFC 748, I take extreme offense at the suggestion that
RFC 748 was a bad idea. It was, perhaps, an idea that was before its time
(the RFC was written 10 years ago), but with the advent of Internetworking,
TCP, and ISO the problem addressed by RFC 748 has become more serious. RFC
748 provides a simple and elegant way of solving the problem.
I expect that the authors of the forthcoming Host Requirements RFC will
make RFC 748 a mandatory part of all host implementations.
With tongue firmly planted in cheek,
-- Mark --
-------tinker@ultra.UUCP (Don Tinker) (04/12/89)
I am heartened by the sensibility of the community that met this proposal with silent disdain. After all, a User is a device for maintaining connectivity among devices (or maintaining reconnectivity, in the case of those $%*&^#% sliding-latch connectors), and thus more properly should be specified by EIA. Don Tinker tinker@ultra.com Systems Engineer (703) 821-8393 Ultra Network Technologies
jeff@hpctdkz.HP.COM (Jeff Hughes) (04/12/89)
I am confused. Is RFC1097 a joke or what? If so, no one is laughing. I agree with Bob H. completely!
watrous@porthos.rutgers.edu (Don Watrous) (04/13/89)
In article <6462@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: > I sincerely hope RFC 1097 is a joke, subliminal suggestion is a devious and > underhanded way to influence people into taking actions or adopt ideas > without their consent. People should be afraid to look at terminals if > there is a possibility subliminal messages are being sent. Why isn't this > practice illegal? I vote for a complete banning of subliminal messages from > any electronic medium and propose for now a banning of subliminal messages > across the Internet. Subliminal messages are a dangerous threat to our > security and the integrity of the Internet. I would have agreed with you a while ago myself. When our systems group first considered implementing subliminals, I strongly opposed on ethical grounds. I gave in to a test period only after assurances that it would be used only on our most difficult users by unanimous decision of the systems staff, and *NEVER* on the staff themselves. Well, I must say that after the test period was over, I was convinced. Our users seem happier and decision making around here has never gone easier. In terms of user satisfaction, our performance has never been better. That's what we're here for, right? Get down off your ethical high horse and deal with problems pragmatically! ;^) Don -- {backbone}!aramis.rutgers.edu!watrous watrous@aramis.rutgers.edu
barmar@think.COM (Barry Margolin) (04/19/89)
In article <3270014@hpctdkz.HP.COM> jeff@hpctdkz.HP.COM (Jeff Hughes) writes: > I am confused. Is RFC1097 a joke or what? If so, no one is laughing. Maybe you aren't, but I chuckled when I read it. It was dated April 1, so I recognized it immediately for what it was (I don't think a serious RFC ever has or will be published on that date). It was good satire, as it was written in the precise style of normal Telnet option RFC's. It was funnier than the usual Usenet humor, which is mostly made up of Star Trek: The Next Generation parodies, definitions of "Real Programmers", and computer folklore discussions that degenerate into lists of all the silly things naive users do to floppy disks. But the proof of the pudding is that some people actually believed it, despite repeated warnings in news.announce.important to be on the lookout for April Fool's Day hacks. The other funny thing is that there are still people flaming about it nearly three weeks later. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dan@ccnysci.UUCP (Dan Schlitt) (04/19/89)
It must be working like magic. Haven't heard a noise out of Webber in
ages.
--
Dan Schlitt Manager, Science Division Computer Facility
dan@ccnysci City College of New York
dan@ccnysci.bitnet New York, NY 10031
(212)690-68687thSon@SLCS.SLB.COM (Chris Garrigues) (04/19/89)
We felt that this option would be useful here because we have a number of users who appear to be unable to remember instructions from one day to the next, so I was going to implement it. I first decided that I should implement WILL RANDOMLY-LOSE (RFC 748), however since it would be useful to turn this flag on until I got SUBLIMINAL-MESSAGE debugged. However, I've been having a hell of a time figuring out how to get either 256 or 257 encoded into a single byte. Should this be implmented using the EXTENDED-OPTIONS-LIST of RFC 861? Chris
mckee@MITRE.MITRE.ORG (H. Craig McKee) (04/20/89)
>From: hpfcdc!hpldola!hpctdlb!hpctdkz!jeff@hplabs.hp.com (Jeff Hughes) > > I am confused. Is RFC1097 a joke or what? If so, no one is laughing. >I agree with Bob H. completely! I believe the date of the RFC (91/1989 Julian) should influence our thinking on this matter. Regards - Craig
ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) (04/21/89)
To anyone who's still unsure about whether this is a joke: just try to
implement it. Upon careful reading of RFC 1097, you'll see the following:
1. Command name and code.
SUBLIMINAL-MESSAGE 257
Good luck,
Walt Wimerpeter@ficc.uu.net (Peter da Silva) (04/24/89)
What sort of hardware is needed to implement this? The 1/60 second update rate of standard CRTs is too slow for subliminal messages, even ignoring considerations of phosphor decay rates. Do you need some sort of RS232-able tachistoscope to get the required ~2ms display time? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jqj@HOGG.CC.UOREGON.EDU (04/25/89)
What sort of hardware is needed to implement this? The 1/60 second update rate of standard CRTs is too slow for subliminal messages, even ignoring considerations of phosphor decay rates. Do you need some sort of RS232-able tachistoscope to get the required ~2ms display time? A standard vector CRT with a reasonably flexible controller should do the trick. HP makes such a beast, for instance. If you keep the display list very short and tell the controller to scan once only, you may be able to achieve 2ms display time. In a perception lab with which I am associated we routinely get ~10ms temporal accuracy, more limited by the cpu clock than by the display. Note, however, that since you must draw characters the text of your message must be kept short. A reasonable upper bound would be 2 characters. Thus, the subliminal message "IP" is doable, but "OSI" probably is not. More seriously, but not appropriate to this list: if anyone knows of any raster display hardware capable of < 10ms temporal resolution please send me email. We are interested in buying... Our T-scope controller is a networked PC (spry.psych.uoregon.edu), but the stimuli still have to be inserted in the fields manually.
7thSon@SLCS.SLB.COM (Chris Garrigues) (04/25/89)
Date: 24 Apr 89 15:48:40 GMT
From: peter%ficc%sugar%texbell@bellcore.com (Peter da Silva)
What sort of hardware is needed to implement this? The 1/60 second update
rate of standard CRTs is too slow for subliminal messages, even ignoring
considerations of phosphor decay rates. Do you need some sort of RS232-able
tachistoscope to get the required ~2ms display time?
I was actually implementing it on a Lisp Machine and because this is an
AI machine, I can use various AI techniques to display the message very
quickly on a portion of the screen where I can be reasonably certain the
user isn't looking (by use of an expert system modeling the user's
visual system).
Admittedly, this solution isn't guaranteed to always keep the message at
a subliminal level, but we feel that our model is accurate enough (and
our users are sufficiently asleep), that the majority of them will never
know what hit their retina.
A second option I was considering was to simply display it as a
notification with the string "Don't read this: " appended to the front,
but after some experimentation, I now feel that this might be too
obvious.
Two techniques which I haven't experimented with are (a) to dither the
message into the background pattern on my window system. This would
make the message difficult to read, but isn't that the idea? and (b) to
use the audio system of the console to actually say the words very
quietly. I suspect this would work on people like myself who work with
the radio on, but might be detectable by those who perfer to work in
silence.
I expect to have more success when I port to a color screen because I
can simply write the charaters with the color being almost, but not
quite, identical to the background color. After all, can *you*
differentiate 16,777,216 different colors? How to select the colors is
certainly a fascinating area for future research.
Chrishenry@utzoo.uucp (Henry Spencer) (04/27/89)
In article <8904251341.AA04991@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes: >A standard vector CRT with a reasonably flexible controller should do >the trick. HP makes such a beast, for instance. If you keep the >display list very short and tell the controller to scan once only, >you may be able to achieve 2ms display time... > >Note, however, that since you must draw characters the text of your >message must be kept short. A reasonable upper bound would be 2 >characters. Thus, the subliminal message "IP" is doable, but "OSI" >probably is not... Of course, if you've got a Three Rivers Graphic Wonder, you could probably do a chapter or so out of Padlipsky's book... :-) (For those not familiar with it, the GW was a CMU invention that Three Rivers tried -- not very successfully -- to sell commercially. The market wanted vector displays to be smart; the GW was dumb but very very very fast. It tended to fill its dual-ported memory before it ran out of refresh speed, but Tom Duff once estimated it could refresh 100,000 short vectors without serious flicker, if you could find somewhere to store them all.) (U of T has Three Rivers GW serial number 001.) -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (04/27/89)
In article <19890425150305.1.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>, 7thSon@SLCS.SLB.COM (Chris Garrigues) writes: > Two techniques which I haven't experimented with are (a) to dither the > message into the background pattern on my window system. This would > make the message difficult to read, but isn't that the idea? The problem is that the human visual system is cued to movement and to certain kinds of borders. If you use differential dithering patterns you may or may not be able to see the message at all, particularly if the size of the message is on the order of magnitude of your background. Consider the success of copy-protected checks, that use two areas of the same luminance but a different sized mesh of dots to print a ghostly 'VOID' on the check... one that can't be seen but will produce a visible interference pattern with the screen in a copy machine. Of course this might actually have a subliminal effect. Maybe the anxiety you feel at payday is NOT just related to the size of your paycheck? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.