[OTR-dev] OTR Encrypted File Transfer, Spec Draft

[Chris Ballinger]

I talked to Miron about this before and my hesitations about sending it
through the chat channel is that you risk being throttled or banned by the
service because sending a file looks similar to a DoS attack.

Back in the 90s on AIM you could only send so many messages so quickly
before it would boot you off the service. I would be very surprised if
messaging systems today wouldn't do something similar.


On Tue, Jun 4, 2013 at 9:21 PM, Peter Lawler <otr.dev at bleeter.id.au> wrote:

> On 05/06/13 12:47, Hans-Christoph Steiner wrote:
>
>  Oh yeah, I forgot to mention that OTR in-band might continue to work if a
>> XMPP
>> service decided to block XEP-0047 transfers.
>>
>
> My 2c.
>
> If the point of OTR is to 'just work' on any protocol, surely OTR-FT
> should 'just work' on any protocol as well. Thus, if you're on Y! or MSN
> and they decide to snoop FT connection points or even simply shut down
> their FT service. I don't see limiting OTR-FT to XMPP as a 'good thing'.
>
> Although in-band could, I guess, lead to a LOT of data being sent over the
> chat channel. Which could, in theory, result in the IM service 'guessing'
> you're sending a file in-band. Maybe some steganographic techniques could
> be employed on services that utilise 'custom smilies' - but this does move
> away from protocol agnosticism.
>
> Hmmmm....
>
> Pete.
>
>
>
> ______________________________**_________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/**mailman/listinfo/otr-dev<http://lists.cypherpunks.ca/mailman/listinfo/otr-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20130605/3b352cb7/attachment.html>