Subject: Re: [Simple] Wikipedia link for "tallk" real time texting

From: Gregg Vanderheiden <[email-masked]>
Date: Tue, 25 Mar 2008 09:56:59 -0500

Dean
Can you explain the 'flash attack"

The way we propose- each persons text stays separate.

(Gunnar - can you repost the link to our doc that describes this?)

Thx

Gregg
 -- ------------------------------
Gregg C Vanderheiden Ph.D.
If Attachment is a mail.dat try http://www.kopf.com.br/winmail/

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Tuesday, March 25, 2008 4:31 AM
> To: 'Simple WG'
> Subject: [Simple] Wikipedia link for "tallk" real time texting
>
>
> Check out:
>
> http://en.wikipedia.org/wiki/Talk_(Unix)
>
> Think about N-way mixing, the "flash" attack, and the
> interesting quirks of internationalized text, and you'll
> hopefully realize why all modern texting systems are message-based.
>
> --
> Dean
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 25 Mar 2008 16:50:27 +0100

The draft that documents presentation level conventions for real-time text
is
http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-05.txt

It shows two modes. One with panels arranged side-by-side and the text
positioned in height indicating approximately how the turns were taken in
the session.
Another, with real-time text entries in creation showed approximately as in
"talk", and completed entries presented above them as in common chat views. 

Both variants are implemented and people tend to get one of these modes as
their favourite, but think that both are usable and smoother to use than
plain message-wise IM.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gregg Vanderheiden
Sent: Tuesday, March 25, 2008 3:57 PM
To: 'Dean Willis'; 'Simple WG'
Subject: Re: [Simple] Wikipedia link for "tallk" real time texting

Dean

Thx

Gregg

> Think about N-way mixing, the "flash" attack, and the interesting 
> quirks of internationalized text, and you'll hopefully realize why all 
> modern texting systems are message-based.
>
> --
> Dean

__________ NOD32 2968 (20080324) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 26 Mar 2008 22:23:00 +0100

If you want to get a feeling of what real-time text can be, you can try
SIPcon1.
It is an open source SIP client with audio and real-time text.
A new version of SIPCon1 is available 
at http://sourceforge.net/projects/tipcon1/ 

It can also be used for usability testing. In its text settings, you can
vary the time sampling time within wide ranges, to verify the recommendation
to use 300 ms sampling time. You can also swap between two-panel mode and
real-time preview mode. 
There is even a setting purely for test purposes that make it transmit on
return instead of time-sampled.

SIPcon1 uses RFC 4103 for transport.

Gunnar

-----Original Message-----

Dean

Thx

Gregg

---

From: Dean Willis <[email-masked]>
Date: Sun, 30 Mar 2008 03:42:08 -0500

> Can you explain the 'flash attack"

It's described in the Wikipedia link.

In short, the characters being sent were eventually interpreted by the  
terminal. If one sent a hex 41 it printed "A". If one sent a hex 08,  
the terminal did a backspace. The real problem came in that there were  
all sorts of other control codes that could cause the terminal to do  
something like copy a buffer of text off the screen and send it, or  
launch a shell command and execute a program. Each brand and model of  
terminal had different exploits.

I remember once seeing a Star Wars animation that used Vt100 cursor- 
positioning commands, which was wedged into my terminal over a "talk"  
connection.

Try running an XTerm window (or mac Terminal.app, or Cygwin terminal,  
or whatever), then entering the following command

telnet towel.blinkenlights.nl

then hit "enter" a couple of times to get past the credits.

While this shows you the ASCII art version of Star Wars (which is way  
cool but takes about a half-hour to watch), it could just as well show  
you the login screen for your bank and phish out your password.

While "modern" IM programs might not seem to have the same attack  
vector, one can never be assured that they are NOT being sued from a  
terminal (after all, xterm is a terminal emulator that suffers from  
the same attacks as a physical terminal). Further, the complexities of  
internationalized text (UTF-8, UTF-16, etc). mean that you can  
sometimes send a character in one character set that translates into a  
control code in another character set. This can be areal mess. Even  
without a "terminal" in the loop, internationalization exploits can  
result in some really crazy things happening.  Adding "backspacing"  
and buffer editing vastly increases the complexity and makes it even  
more likely that interesting things can be made to happen.

> The way we propose- each persons text stays separate.

Yeah, if I'm in a 40-person conference, my cell phone has enough  
screen real estate to show a meaningful scrolling erasure window for  
each of those 40 people. No way.

The only way we know of to have it make sense is to interleave whole- 
messages like "Bob said: . . . Alice said: . . . ". Once Alice has  
spoken after Bob, having Bob go back and backspace over what he said  
just doesn't compute.

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sun, 30 Mar 2008 16:05:48 -0500

Thanks

And thanks for blinkenlights too.

Gregg

> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, March 30, 2008 3:42 AM
> To: Gregg Vanderheiden
> Cc: 'Simple WG'
> In short, the characters being sent were eventually
> interpreted by the terminal. If one sent a hex 41 it printed
> "A". If one sent a hex 08, the terminal did a backspace. The
> real problem came in that there were all sorts of other
> control codes that could cause the terminal to do something
> like copy a buffer of text off the screen and send it, or
> launch a shell command and execute a program. Each brand and
> model of terminal had different exploits.
>
> I remember once seeing a Star Wars animation that used Vt100
> cursor- positioning commands, which was wedged into my
> terminal over a "talk"
> connection.
>
> Try running an XTerm window (or mac Terminal.app, or Cygwin
> terminal, or whatever), then entering the following command
>
> While this shows you the ASCII art version of Star Wars
> (which is way cool but takes about a half-hour to watch), it
> could just as well show you the login screen for your bank
> and phish out your password.
>
>
> While "modern" IM programs might not seem to have the same
> attack vector, one can never be assured that they are NOT
> being sued from a terminal (after all, xterm is a terminal
> emulator that suffers from the same attacks as a physical
> terminal). Further, the complexities of internationalized
> text (UTF-8, UTF-16, etc). mean that you can sometimes send a
> character in one character set that translates into a control
> code in another character set. This can be areal mess. Even
> without a "terminal" in the loop, internationalization
> exploits can result in some really crazy things happening.
> Adding "backspacing"
> and buffer editing vastly increases the complexity and makes
> it even more likely that interesting things can be made to happen.
>
> >
> >
> Yeah, if I'm in a 40-person conference, my cell phone has
> enough screen real estate to show a meaningful scrolling
> erasure window for each of those 40 people. No way.
>
> The only way we know of to have it make sense is to
> interleave whole- messages like "Bob said: . . . Alice said:
> . . . ". Once Alice has spoken after Bob, having Bob go back
> and backspace over what he said just doesn't compute.
>
> --
> Dean
>