From fnord at pentabarf.de Tue May 6 12:44:11 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Tue, 06 May 2008 18:44:11 +0200 Subject: [OTR-dev] OTR static strings and html stuff Message-ID: <1210092251.6154.14.camel@hegg> Hi! As I'm currently actively working on getting OTR-encryption working for gajim (see [1]), I've stumbled upon some annoyances in current libotr. 1.) basically all strings used in OTR for user interfaces contain HTML. This is very bad because it breaks CLI clients or clients that don't send HTML over tags in XMPP (*wink* pidgin-otr) 2.) none of those strings are translatable! IMHO libotr should not use human-readable text at all but pass error codes which should be translated to human-readable text by the implementing application. This would integrate with all localisation methods as well as gives HTML-enabled clients the possibility to use HTML. Thoughts? Thanks, Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From evan.s at dreskin.net Tue May 6 13:51:07 2008 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 6 May 2008 13:51:07 -0400 Subject: [OTR-dev] OTR static strings and html stuff In-Reply-To: <1210092251.6154.14.camel@hegg> References: <1210092251.6154.14.camel@hegg> Message-ID: <8C9BEDEB-5FB7-4D06-B9B4-67C5608968D0@dreskin.net> I agree on both points, Kjell! I'm not an OTR dev but I know the library fairly well and would be happy to help review a patch if you're volunteering to write it :) Cheers, Evan On May 6, 2008, at 12:44 PM, Kjell Braden wrote: > Hi! > > As I'm currently actively working on getting OTR-encryption working > for > gajim (see [1]), I've stumbled upon some annoyances in current libotr. > > 1.) basically all strings used in OTR for user interfaces contain > HTML. > This is very bad because it breaks CLI clients or clients that don't > send HTML over tags in XMPP (*wink* pidgin-otr) > 2.) none of those strings are translatable! IMHO libotr should not use > human-readable text at all but pass error codes which should be > translated to human-readable text by the implementing application. > This > would integrate with all localisation methods as well as gives > HTML-enabled clients the possibility to use HTML. > > Thoughts? > > Thanks, > Kjell From ian at cypherpunks.ca Tue May 6 17:46:10 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 6 May 2008 17:46:10 -0400 Subject: [OTR-dev] OTR static strings and html stuff In-Reply-To: <1210092251.6154.14.camel@hegg> References: <1210092251.6154.14.camel@hegg> Message-ID: <20080506214610.GS6425@yoink.cs.uwaterloo.ca> On Tue, May 06, 2008 at 06:44:11PM +0200, Kjell Braden wrote: > Hi! > > As I'm currently actively working on getting OTR-encryption working for > gajim (see [1]), I've stumbled upon some annoyances in current libotr. > > 1.) basically all strings used in OTR for user interfaces contain HTML. > This is very bad because it breaks CLI clients or clients that don't > send HTML over tags in XMPP (*wink* pidgin-otr) > 2.) none of those strings are translatable! IMHO libotr should not use > human-readable text at all but pass error codes which should be > translated to human-readable text by the implementing application. This > would integrate with all localisation methods as well as gives > HTML-enabled clients the possibility to use HTML. > > Thoughts? You're absolutely correct, and it's on the to-do list. I don't have a body actually working on it, though. The plan is to add a callback to the OtrlMessageAppOps which will take a code (it's used for more than just errors) and some other useful parameters, and it'll be up to the calling application to do something human-reasonable with it. - Ian From ian at cypherpunks.ca Tue May 13 09:22:19 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 13 May 2008 09:22:19 -0400 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> Message-ID: <20080513132219.GB7120@thunk.cs.uwaterloo.ca> There are a number of issues raised in this thread. Let me know if I miss any. I'll start with the simple ones. Scott> The other serious problem in my mind is the need for a 'i'm going Scott> offline now' message It's not mandatory. It didn't exist in the first version of the protocol. It's just a hint to the other side that you've gone away, and they're free to deallocate a few resources (and forget the remaining one or two keys). Or are you referring to something else? Jonathan> I also noticed that libotr returns HTML error messages, which Jonathan> we think is bad, they are not translatable and we have to Jonathan> strip HTML from them. We also think this is bad, bad, bad. libotr is divided into three parts: - the low-level packet format, encryption, keys, state, etc. - user authentication support (Socialist Millionaires' protocol in the current version) - the messaging support (otrl_message_sending, fragmentation, etc.) The messaging support is completely crufty. It contains hardcoded English HTML strings, among other nonsense. We're starting a project to revamp the libotr API now, particularly the messaging part. For reference, here are the OTR projects currently underway over the next 3-4 months: - New UI for user authentication, based on results of user study (which will be published in the Symposium On Usable Privacy and Security: SOUPS 2008). The code is pretty much done for this; it needs a congifuration checkbox and some revamped documentation. - Implementation of libotr in Java, hopefully leading to some OTR-on-smartphone action. - Addressing the user-logged-in-multiple-times problem. - libotr API cleanup, as above. Anyone who wants to volunteer to help with in particular the new API, now's the time. One of the big goals is exactly to make libotr have fewer pidgin idioms in it. To do this, we need people with experience with the internals of other IM clients to contribute their domain knowledge. R?diger> According to the OTR spec, the library is supposed to do R?diger> nothing more than replace the plain text with the encrypted R?diger> text. As such, the place for text/plain is supposed to contain R?diger> encryped text/plain, while the place for text/html is supposed R?diger> to contain encrypted text/html. OK, this is the big one. As was noted, it comes up from time to time. In this post, I'll try to clarify my thoughts on the matter. That's not quite what the spec says, as Scott (I think it was) points out. But let's put that aside. Let's talk about what the spec *should* say, not what it says now. The plaintext of an OTR message is a sequence of bytes. How do you interpret those bytes? In addition to the content-type issue (is it text/plain, text/html, text/xhtml, something else?), there's also the encoding issue, which no one seems to have raised. These two things actually go hand-in-hand. The AIM protocol, for example, specifies three choices for the encoding: 7 bit ASCII, UCS-2BE, and ISO-8859-1. Note that none of these is UTF-8 (though some clients may exploit the fact that 7-bit ASCII is a subset of UTF-8 and hope the other end doesn't barf on it). So who specifies the encoding and content-type for the plaintext sequence of bytes inside the OTR packet? There are three choices I see: 1. It's specified explicitly in the protocol. Everyone uses the same choice, and you have to convert between whatever you use natively and this choice before encrypting / after decrypting. Note that it's perfectly reasonable for libotr to provide some commonly used conversion routines to help you with this. 2. It's specified explicitly in the OTR Data packet (within the authenticated section). Different clients may make different choices, or make different choices for different messages (such as the text/plain and text/xhtml parts of a Jabber message). Clients will need to convert between the choice received and their native choice. libotr could again help here by providing common conversions, but now you potentially have an n^2 problem as all formats need to be converted to all other formats. 3. It's specified implicitly by context, probably by "inheriting" whatever encoding and content-type are being used to format the OTR ciphertext. This has the advantage of clients not having to convert anything, since they can just do "in-place" encryption/decryption, most of the time. R?diger is advocating 3; someone else on the list suggested 2. I'm going to suggest 1. Here are my reasons. My main issue with 3 is the potential security hole it opens up. Unlike 1 and 2, the method of interpretation of the plaintext bytes is not securely specified, and is in fact under the control of an adversary. For example, suppose there's a Jabber message sent (in model 3), where the body section contains an encryption of "to put something in bold, wrap around it" and the xhtml section contains an encryption of "to put something in bold, wrap <b></b> around it". Then an adversary replaces the OTR block in the xhtml section with the one from the body section. An end user with an xhtml-aware client will see "to put something in bold, wrap around it", and the attacker has successfully modified the message. The advantage of 1 over 2 is just that there's no chance someone will pick a bizarre format you don't know about; you just need to convert between whatever native format you use for your IM client/protocol and the fixed OTR format. So here's my proposal, which is of course open for debate. - Specify that OTR plaintext is UTF-8 text/xhtml. - Clarify in the section on encrypting/decrypting that you need to convert your plaintext to/from that format. - Have at least one version of the encrypt/decrypt API call take as a parameter the format (type and encoding) your plaintext should be in, and libotr will convert it for you (assuming it knows that format). So if this were implemented, Jabber clients would call otrl_message_sending/receiving with a parameter of UTF8_TEXT_PLAIN to encrypt/decrypt the body part, and UTF8_TEXT_XHTML to encrypt/decrypt the xhtml part. The fact that what you get when you apply AES-CTR to the OTR message body is in fact UTF-8 text/xhtml in either case should be totally transparent. Ideally, I could decide to standardize on "UCS-2BE text/rtf rot13" and you wouldn't even notice. [But of course, everyone would have to be using an OTR library that supported this.] There's a slightly related problem of what do you do if the encoded OTR string (the "?OTR:AAED...") isn't appropriate for your IM protocol. For example, AIM using UCS-2BE. I suppose libotr could translate that for you as well (to "\x00?\x00O\x00T\x00R\x00:\x00A\x00A\x00E\x00D..."), but that's a really rare case. I'll note that the outcome of the "fix the multiple login problem" work above will certainly lead to a rev of the OTR wire protocol. So that would be a great time to clarify this as well. I think that's long enough for now. ["I made this letter longer than usual because I lack the time to make it shorter." -- Blaise Pascal] Comments? - Ian From mail at scottellis.com.au Tue May 13 22:21:45 2008 From: mail at scottellis.com.au (Scott Ellis) Date: Wed, 14 May 2008 12:21:45 +1000 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <20080513132219.GB7120@thunk.cs.uwaterloo.ca> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> Message-ID: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> > Scott> The other serious problem in my mind is the need for a 'i'm going > Scott> offline now' message > > It's not mandatory. It didn't exist in the first version of the > protocol. It's just a hint to the other side that you've gone away, and > they're free to deallocate a few resources (and forget the remaining one > or two keys). In previous discussions about this (too long ago for me to remember who was involved, sorry), I commented that I'd tried to resolve the issue by watching user status. It was mentioned that this can be exploited in an attack if the user status can be spoofed, allowing sessions to be continuously reset, at least chewing resources and possibly reducing the level of security. I don't see any better options though in clients where an 'end of session' message isn't possible. Another problem with this method is that clients who do not end sessions due to an offline status expect to be able to continue the session with 'offline' contacts, causing at least renegotiation but usually requiring a whole new session. And that's not even considering offline messages and invisible users. I'm confused by some of your terminology (I am no cryptographer): "you have to convert between whatever you use natively and this choice before encrypting / after decrypting" - don't you mean after encrypting/before decrypting? You say 'plaintext of an OTR message' - which i would assume to be the decrypted version, and then talk about the 'plaintext byes in an OTR packet' - which I would assume to be the encrypted bytes...or are you talking about the parts of the OTR packet that are not the encrypted message? Nevertheless I think I understand most of what you meant. Below I'm using 'plaintext' to mean 'decoded/unencrypted'. With the encoding stuff, I think you are skirting the major point: for a lot of clients (maybe even most of them) it would be more convenient if the OTR plaintext followed the rules of the transport protocol - i.e. does not contain HTML when using a protocol for transport that does not allow HTML in messages. We're not just talking about ending up with HTML in the plaintext part of jabber stanzas - we're talking about getting HTML tags in decoded AIM messages, and other protocols that don't allow HTML at all. Jabber is atypical and shouldn't be the protocol you use when thinking about this stuff, imo. Also, it usually does not make sense to talk about what a 'jabber(/icq/gg/etc) client' would do (as opposed to what some other client might do) - in a plugin-based multi-protocol messenger, you are not going to have each protocol plugin including code for making calls to OTR - the architecture needs to allow for encryption plugins to get their hands on messages at the appropriate times, via callbacks or whatever. I haven't seen a callback mechanism that would allow for the tight coupling you've described. Protocols and encryption plugins need to be treated uniformly - this makes encryption plugins fundamentally different from protocol plugins. It is unusual for an encryption library to claim protocol status, and I think it just causes problems.. I think this is why the issue of encoding has not come up. People just expect to get out whatever they put in. There should be no need to pass in to OTR any content-type information. The plaintext bytes should be interpreted by the protocol as any other bunch of plaintext bytes are interpreted - the encryption should be transparent to the protocol. For clients that don't natively handle HTML in the interface, it creates a lot of complications if suddenly you have HTML in messages over protocols that would normally handle that themselves. With overly simple (niave?) callback mechanisms, the message is decoded after the protocol has received it but then continues on it's way to the UI without the usual processing that the protocol plugin would do to plaintext. At a minimum that means the decoded messages have to be passed back through any HTML stipping or translation code, and unfortunately that code is usually packaged within the protocol plugin and not exposed via an API. Extending this (and admittedly getting a little bit contrived), what if the protocol allows for embedded commands or configuration or 'customised smileys' or other similar things? The protocol needs to get the message off the network, decrypt it, and then get the decrypted message back to handle as it would any other. Trying to define OTR as a protocol means losing all of this protocol-specific functionality (which, in the case of configuration, may be essential to workings of the protocol) and potentially being forced to include copies of existing code. I don't think it makes much sense to talk about putting encoded HTML in the HTML part of a jabber message - I don't think you'll ever get agreement on the technicalities - i.e. whether it is still HTML when encoded. Imo, a solution that works for jabber is unlikely to work generically. I think the appropriate way to handle jabber would be to take both elements, perhaps even the whole iq stanza, and embed the encrypted version in a message as if it were text/plain data. That would prevent the kinds of attacks you mention, and perhaps make it possible to treat jabber more like other protocols. As it is a special case I think it would be justified if jabber clients and plugins did make their own specific calls to the OTR library, if that turned out to be necessary. I've never had to worry about the encoding used for encrypted OTR messages either - there ought to be encoding information passed from the protocol to OTR during decryption and encryption. E.g. the message being sent comes in to the protocol, is formatted for sending and passed to OTR along with information about it's encoding. It will be converted to UTF8, encoded by OTR, and the encrypted version converted back to the encoding used by the protocol. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at scottellis.com.au Tue May 13 22:58:24 2008 From: mail at scottellis.com.au (Scott Ellis) Date: Wed, 14 May 2008 12:58:24 +1000 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: <96e269140805131958t222fcbcbtca339312de71f66d@mail.gmail.com> > We're not just talking about ending up with HTML in the plaintext part of > jabber stanzas - we're talking about getting HTML tags in decoded AIM > messages, and other protocols that don't allow HTML at all. > I think I need to clarify this one a bit - AIM does allow html tags. What I'm referring to is that in a non-html-aware interface the aim plugin will strip them when a message is received - but that can't be done if the protocol cannot access the decoded message. Same problem for protocols that don't allow HTML and would normally strip it before sending. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at cypherpunks.ca Fri May 16 11:33:34 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 16 May 2008 11:33:34 -0400 (EDT) Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On Wed, 14 May 2008, Scott Ellis wrote: > > It's not mandatory. It didn't exist in the first version of the > > protocol. It's just a hint to the other side that you've gone away, and > > they're free to deallocate a few resources (and forget the remaining one > > or two keys). > > > In previous discussions about this (too long ago for me to remember who was > involved, sorry), I commented that I'd tried to resolve the issue by > watching user status. Which OTR messed up as it is, because automatic replies to OTR requests make it appear the user is no longer idle, while in fact, the user still is. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From evan.s at dreskin.net Fri May 16 11:53:05 2008 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 16 May 2008 11:53:05 -0400 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On May 16, 2008, at 11:33 AM, Paul Wouters wrote: > On Wed, 14 May 2008, Scott Ellis wrote: > >>> It's not mandatory. It didn't exist in the first version of the >>> protocol. It's just a hint to the other side that you've gone >>> away, and >>> they're free to deallocate a few resources (and forget the >>> remaining one >>> or two keys). >> >> >> In previous discussions about this (too long ago for me to remember >> who was >> involved, sorry), I commented that I'd tried to resolve the issue by >> watching user status. > > Which OTR messed up as it is, because automatic replies to OTR > requests make > it appear the user is no longer idle, while in fact, the user still > is. That certainly isnt how Adium behaves - user activity, not network or automated activity, determines idleness. On what client did you see that behavior? In any case, contact online/offline status is the important bit, I think, not idleness/awayness. -Evan > > > Paul > -- > Building and integrating Virtual Private Networks with Openswan: > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From tg at mirbsd.de Sun May 18 12:08:13 2008 From: tg at mirbsd.de (Thorsten Glaser) Date: Sun, 18 May 2008 16:08:13 +0000 (UTC) Subject: [OTR-dev] solution for slow key generation Message-ID: Hi! Jonathan complained that OTR key generation took about an hour on his NetBSD computer (he?ll probably provide specs if desired). I dug into the code and found out that this is because libgcrypt (sucky code?) uses /dev/srandom? for key generation entropy, which uses blocking reads. While it didn?t take that long for me on MirOS ? less than one minute ? I?ve written a tool intended to be used as a contributed script, not to replace the code inside of libotr. This script? uses openssl for key generation, so Debian users should take care ? as not even using -rand helps with the bug they had. Other dependencies are mksh?, chmod, cat, and of course the openssl command-line tool. Add some suitable entropy source (can optionally be given as command line argument) or pull 32 (additional) bytes from me? (this is a slow box on a slow ADSL connection, but it has good entropy quality?). Like I said, I don?t want to replace or criticise anything (maybe except the decision to not use libcrypto/libssl in the first place ?), but I?d be glad if you people would look over that script and maybe include it as ?contrib? in the next libotr distribution. ? may be named different on your OS ? http://www.mirbsd.org/man/srandom.4 ? http://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/otr-genkey.sh ? http://mirbsd.de/mksh ? part of many distributions, ports trees, etc. ? https://herc.mirbsd.org/rb.cgi?from_otr-dev_ml ? https://www.cacert.at/cgi-bin/rngresults ? scroll down to the bottom bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst ?ber *fs From gdt at ir.bbn.com Tue May 20 07:45:49 2008 From: gdt at ir.bbn.com (Greg Troxel) Date: Tue, 20 May 2008 07:45:49 -0400 Subject: [OTR-dev] solution for slow key generation In-Reply-To: (Thorsten Glaser's message of "Sun, 18 May 2008 16:08:13 +0000 (UTC)") References: Message-ID: Thorsten Glaser writes: > Jonathan complained that OTR key generation took about an hour on his NetBSD > computer (he?ll probably provide specs if desired). I dug into the code and > found out that this is because libgcrypt (sucky code?) uses /dev/srandom? for > key generation entropy, which uses blocking reads. Do you really mean srandom? NetBSD provides /dev/random (bits with actual entropy, will block until available) /dev/urandom (bits with entropy if available, and keep hashing if not available) > While it didn?t take that long for me on MirOS ? less than one minute ? I?ve > written a tool intended to be used as a contributed script, not to replace > the code inside of libotr. This script? uses openssl for key generation, so > Debian users should take care ? as not even using -rand helps with the bug > they had. Other dependencies are mksh?, chmod, cat, and of course the openssl > command-line tool. Add some suitable entropy source (can optionally be given > as command line argument) or pull 32 (additional) bytes from me? (this is a > slow box on a slow ADSL connection, but it has good entropy quality?). I'm not sure this is a good idea. openssl ought to be using /dev/random too. If one wants to take bits that might not have adequate entropy, one can just use /dev/urandom. What I do is kick off a 'du /' to get lots of disk activity, which replenishes the pool. It really depends on whether you want to wait for good quality key bits, or to get lesser quality bits faster. RND(4) NetBSD Kernel Interfaces Manual RND(4) NAME rnd -- in kernel entropy collection and random number generation SYNOPSIS pseudo-device rnd DESCRIPTION The rnd pseudo-device uses event timing information collected from many devices, and mixes this into an entropy pool. This pool is stirred with a cryptographically strong hash function when data is extracted from the pool. INTERNAL ENTROPY POOL MANAGEMENT When a hardware event occurs (such as completion of a hard drive transfer or an interrupt from a network device) a timestamp is generated. This timestamp is compared to the previous timestamp recorded for the device, and the first, second, and third order differentials are calculated. If any of these differentials is zero, no entropy is assumed to have been gathered. If all are non-zero, one bit is assumed. Next, data is mixed into the entropy pool using an LFSR (linear feedback shift register). To extract data from the entropy pool, a cryptographically strong hash function is used. The output of this hash is mixed back into the pool using the LFSR, and then folded in half before being returned to the caller. Mixing the actual hash into the pool causes the next extraction to return a different value, even if no timing events were added to the pool. Folding the data in half prevents the caller to derive the actual hash of the pool, preventing some attacks. USER ACCESS User code can obtain random values from the kernel in two ways. Reading from /dev/random will only return values while sufficient entropy exists in the internal pool. When sufficient entropy does not exist, EAGAIN is returned for non-blocking reads, or the read will block for blocking reads. Reading from /dev/urandom will return as many values as requested, even when the entropy pool is empty. This data is not as good as reading from /dev/random since when the pool is empty, data is still returned, degen- erating to a pseudo-random generator. Writing to either device will mix the data written into the pool using the LFSR as above, without modifying the entropy estimation for the pool. RANDOM SOURCE STRUCTURE Each source has a state structure which the kernel uses to hold the tim- ing information and other state for that source. typedef struct { char name[16]; uint32_t last_time; uint32_t last_delta; uint32_t last_delta2; uint32_t total; uint32_t type; uint32_t flags; } rndsource_t; This structure holds the internal representation of a device's timing state. The name field holes the device name, as known to the kernel. The last_time entry is the timestamp of the last time this device gener- ated an event. It is for internal use only, and not in any specific rep- resentation. The last_delta and last_delta2 fields hold the last first- and second-order deltas. The total field holds a count of how many bits this device has potentially generated. This is not the same as how many bits were used from it. The type field holds the device type. Currently, these types are defined: RND_TYPE_DISK The device is a physical hard drive. RND_TYPE_NET The device is a network interface. By default, timing information is collected from this source type, but entropy is not estimated. RND_TYPE_TAPE The device is a tape device. RND_TYPE_TTY The device is a terminal, mouse, or other user input device. RND_TYPE_RNG The device is a random number generator. flags is a bitfield. RND_FLAG_NO_ESTIMATE Do not assume any entropy is in the timing informa- tion. RND_FLAG_NO_COLLECT Do not even add timing information to the pool. IOCTL Various ioctl(2) functions are available to control device behavior, gather statistics, and add data to the entropy pool. These are all defined in the file, along with the data types and constants. RNDGETENTCNT (uint32_t) Return the current entropy count (in bits). RNDGETSRCNUM (rndstat_t) typedef struct { uint32_t start; uint32_t count; rndsource_t source[RND_MAXSTATCOUNT]; } rndstat_t; Return data for sources, starting at start and returning at most count sources. The values returned are actual in-kernel snapshots of the entropy status for devices. Leaking the internal timing information will weaken security. RNDGETSRCNAME (rndstat_name_t) typedef struct { char name[16]; rndsource_t source; } rndstat_name_t; Return the device state for a named device. RNDCTL (rndctl_t) typedef struct { char name[16]; uint32_t type; uint32_t flags; uint32_t mask; } rndctl_t; Change bits in the device state information. If type is 0xff, only the device name stored in name is used. If it is any other value, all devices of type type are altered. This allows all network interfaces to be disabled for entropy collection with one call, for example. The flags and mask work together to change flag bits. The mask field specifies which bits in flags are to be set or cleared. RNDADDDATA (rnddata_t) typedef struct { uint32_t len; uint32_t entropy; u_char data[RND_POOLWORDS * 4]; } rnddata_t; FILES /dev/random Returns ``good'' values only /dev/urandom Always returns data, degenerates to a pseudo-random gener- ator SEE ALSO rndctl(8), rnd(9) HISTORY The random device was first made available in NetBSD 1.3. AUTHORS This implementation was written by Michael Graff using ideas and algorithms gathered from many sources, including the driver written by Ted Ts'o. NetBSD 4.0_RC1 October 12, 1997 NetBSD 4.0_RC1 From tg at mirbsd.de Tue May 20 08:55:54 2008 From: tg at mirbsd.de (Thorsten Glaser) Date: Tue, 20 May 2008 12:55:54 +0000 (UTC) Subject: [OTR-dev] solution for slow key generation In-Reply-To: References: Message-ID: Greg Troxel dixit: >Do you really mean srandom? NetBSD provides Did you not see my reference to the MirBSD srandom(4) manual page further below? ;-) I used this term because the actual names of the random devices differ from platform to platform, so I used the one I?m at home on and put in a link to the explanation. I know for sure it?s /dev/random on Leenocks. >I'm not sure this is a good idea. openssl ought to be using /dev/random Actually, /dev/arandom has better quality on MirBSD (and, possibly, Open- BSD), even though, strongly mathematically spoken, its entropy _level_ is not as high (but the numerical quality of the output is better). >It really depends on whether you want to wait for good quality key bits, >or to get lesser quality bits faster. Considering the fact that you can mix a few bytes from srandom (let me use this name just to avoid confusion with ?random? which might be used as a placeholder for all random devices) with some (as many as needed) bytes from urandom and still have a high-quality output (that?s what pools are for after all), _and_ use the -rand option to openssl (-r in my script) to provide additional entropy, this is a no-issue. Paranoid people will of course want to continue using srandom exclusively, but other people won?t want to wait an hour or more on their headless ser- ver for generation of an OTR key for their backup account. Let me phrase it like this: ?We sell rope.? (This is actually a quote from a NetBSD developer.) Whether you use that rope to hang yourself or do some- thing clueful with it is up to the user. My script is intended for people who know what they do (and do not run Debian ;-). For reference, again: http://www.mirbsd.org/man/srandom.4 ? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst ?ber *fs From paul at cypherpunks.ca Tue May 20 12:36:26 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 20 May 2008 12:36:26 -0400 (EDT) Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On Fri, 16 May 2008, Evan Schoenberg wrote: > >Which OTR messed up as it is, because automatic replies to OTR requests make > >it appear the user is no longer idle, while in fact, the user still is. > > That certainly isnt how Adium behaves - user activity, not network or > automated activity, determines idleness. On what client did you see that > behavior? pidgin. Paul > In any case, contact online/offline status is the important bit, I think, not > idleness/awayness. I never set online/offline, I go by the automatic idle/not idle. Paul From hcat at gmx.net Mon May 26 06:25:56 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Mon, 26 May 2008 12:25:56 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look Message-ID: <20080526102556.10050@gmx.net> Hi everyone. I have been interested in OTR in the past but back then missing support in various widely used clients prevented me from using it. But now the situation seems to be better, with Pidgin, Kopete, Miranda Trillian and Gajim supporting OTR. Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm wondering if there has been any development on the Pidgin plugin since the last release (and I did not find any public SVN etc). I'm mostly wondering about the integration into Pidgin's GUI and the user interaction. For example, the OTR "button" is drawn for any protocol I use ATM. For protocols where I do not have generated a key, it should probably not be shown. Also, this "button" takes a lot of space and I'm wondering if it could be made more compact or even be moved to the chat toolbar? Finally I'm wondering about the icons. The current set of icons is based on the old Gaim icon and does not really fit the style of Pidgin (which uses Tango icons). What icons do other clients use for the OTR states? IMHO it would be important to have the same metaphor for those states on different clients. Each client would then implement the official metaphor in it's own art style (e.g. Tango look for Pidgin). Cheers, Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From fnord at pentabarf.de Mon May 26 08:03:40 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Mon, 26 May 2008 14:03:40 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526102556.10050@gmx.net> References: <20080526102556.10050@gmx.net> Message-ID: <1211803420.6265.5.camel@hegg> Am Montag, den 26.05.2008, 12:25 +0200 schrieb hcat at gmx.net: > Hi everyone. > > I have been interested in OTR in the past but back then missing support in various widely used clients prevented me from using it. But now the situation seems to be better, with Pidgin, Kopete, Miranda Trillian and Gajim supporting OTR. > > Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm wondering if there has been any development on the Pidgin plugin since the last release (and I did not find any public SVN etc). I'm mostly wondering about the integration into Pidgin's GUI and the user interaction. > > For example, the OTR "button" is drawn for any protocol I use ATM. For protocols where I do not have generated a key, it should probably not be shown. Also, this "button" takes a lot of space and I'm wondering if it could be made more compact or even be moved to the chat toolbar? > > Finally I'm wondering about the icons. The current set of icons is based on the old Gaim icon and does not really fit the style of Pidgin (which uses Tango icons). What icons do other clients use for the OTR states? IMHO it would be important to have the same metaphor for those states on different clients. Each client would then implement the official metaphor in it's own art style (e.g. Tango look for Pidgin). > > Cheers, > Michael Just FYI: gajim-svn currently uses the gtk-dialog-authentication stock icon to use the same UI as the esession (jabber-specific OTR-like encryption) uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ian at cypherpunks.ca Mon May 26 08:20:45 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 08:20:45 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526102556.10050@gmx.net> References: <20080526102556.10050@gmx.net> Message-ID: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> On Mon, May 26, 2008 at 12:25:56PM +0200, hcat at gmx.net wrote: > Hi everyone. > > I have been interested in OTR in the past but back then missing > support in various widely used clients prevented me from using it. But > now the situation seems to be better, with Pidgin, Kopete, Miranda > Trillian and Gajim supporting OTR. > > Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm > wondering if there has been any development on the Pidgin plugin since > the last release (and I did not find any public SVN etc). I'm mostly > wondering about the integration into Pidgin's GUI and the user > interaction. > > For example, the OTR "button" is drawn for any protocol I use ATM. For > protocols where I do not have generated a key, it should probably not > be shown. Also, this "button" takes a lot of space and I'm wondering > if it could be made more compact or even be moved to the chat toolbar? > > Finally I'm wondering about the icons. The current set of icons is > based on the old Gaim icon and does not really fit the style of Pidgin > (which uses Tango icons). What icons do other clients use for the OTR > states? IMHO it would be important to have the same metaphor for those > states on different clients. Each client would then implement the > official metaphor in it's own art style (e.g. Tango look for Pidgin). Funny you should ask. ;-) We're just in the final stages of putting a 3.2.0 preview out. The main user interface changes include moving the OTR button to the menu bar (though the button remains an option), support for multiple buddies merged into a single contact / conversation window, improved authentication user interface (based on the user study we did, to appear in SOUPS 2008), and the icons being changed to Tango-based ones. My goal is to get it all into a state where it can be put in the public CVS on sourceforge sometime this week. Then we'll wait a bit for some feedback, and for the various translators to supply translations for the new UI strings, and we'll send it out. - Ian From js-otrim at webkeks.org Mon May 26 10:00:50 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 16:00:50 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526160050.756b19b8@webkeks.org> Ian Goldberg wrote: > We're just in the final stages of putting a 3.2.0 preview out. Will that mean that libotr 3.2.0 with a fixed and finally usable API will also come soon? -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From hcat at gmx.net Mon May 26 10:50:25 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Mon, 26 May 2008 16:50:25 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526145025.270810@gmx.net> > Funny you should ask. ;-) > > We're just in the final stages of putting a 3.2.0 preview out. The > main user interface changes include moving the OTR button to the menu > bar (though the button remains an option), support for multiple > buddies merged into a single contact / conversation window, improved > authentication user interface (based on the user study we did, to appear > in SOUPS 2008), and the icons being changed to Tango-based ones. > > My goal is to get it all into a state where it can be put in the public > CVS on sourceforge sometime this week. Then we'll wait a bit for some > feedback, and for the various translators to supply translations for the > new UI strings, and we'll send it out. Thanks Ian, that's great news! -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian at cypherpunks.ca Mon May 26 13:28:08 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 13:28:08 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> On Mon, 26 May 2008 16:00:50 +0200, Jonathan Schleifer wrote: > Will that mean that libotr 3.2.0 with a fixed and finally usable API > will also come soon? As I mentioned, we'll be working on the fixed and usable API over the next few months, and we're still looking for input on what you'd like to see in the API. This will definitely be a non-backwards-compatible API change, so that version should be 4.0.0. But libotr 3.2.0 will in fact be coming out shortly (along with pidgin-otr 3.2.0), with support for the updated authentication mechanism. - Ian From js-otrim at webkeks.org Mon May 26 13:51:14 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 19:51:14 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195114.41633f72@webkeks.org> Ian Goldberg wrote: > and we're still looking for input on what you'd like > to see in the API. This will definitely be a > non-backwards-compatible API change, so that version should be 4.0.0. That API should *never* return strings, but instead return error codes. We're that pissed of about the current API of libotr that we have thought about dropping OTR support completely in Gajim several times. We lose messages etc. because libotr just gives us an event with HTML included, which we only show as a status in the chat windows, which thus won't be shown if the window is closed and will be lost. And with the current API, we can't fix that. So the next release will be definitely without any OTR support as we can't provide it in a usable way with the current API. We will, however, keep the code in trunk so we can update our code once libotr is fixed and usable, but before, it will never be enabled for a release. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From js-otrim at webkeks.org Mon May 26 13:53:53 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 19:53:53 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195353.4890432d@webkeks.org> Oh, forgot to mention: We're definitely not going to try to match the strings since that's dangerous. And since every OTR event looks to us the same since we don't match for anything, we can't know for example if it's an unencrypted message or not and thus can't know if we should trigger a message event. This really makes libotr unusable for us. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ian at cypherpunks.ca Mon May 26 15:56:18 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 15:56:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> On Mon, 26 May 2008 19:51:14 +0200, Jonathan Schleifer wrote: > That API should *never* return strings, but instead return error > codes. Yes, that's one of the main things we'll be changing; the way it works now is completely silly (not to mention i18n-unfriendly). I've signed up someone who will be working on this API redesign. He should be contacting the various IM client implementors soon (either via this list, or by direct email, not sure yet) to start gathering requirements for the v4 API. - Ian From js-otrim at webkeks.org Mon May 26 16:08:19 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 22:08:19 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526220819.1b190450@webkeks.org> Ian Goldberg wrote: > Yes, that's one of the main things we'll be changing; the way it works > now is completely silly (not to mention i18n-unfriendly). I've signed > up someone who will be working on this API redesign. He should be > contacting the various IM client implementors soon (either via this > list, or by direct email, not sure yet) to start gathering > requirements for the v4 API. Can you give any ETA so we can plan for our next release? We try to release 0.12 ASAP, but it will still take a few months and I'd like to know if there's a possibility we can support OTR in the 0.12 release. It would be enough to know when the biggest part of the API change is done so we can base on that. Doesn't matter if libotr 4.0 gets released after Gajim 0.12 then, at least, we have working support in it then :). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ian at cypherpunks.ca Mon May 26 17:59:40 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 17:59:40 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526220819.1b190450@webkeks.org> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> <20080526220819.1b190450@webkeks.org> Message-ID: <20080526215940.GF30190@yoink.cs.uwaterloo.ca> On Mon, May 26, 2008 at 10:08:19PM +0200, Jonathan Schleifer wrote: > Ian Goldberg wrote: > > > Yes, that's one of the main things we'll be changing; the way it works > > now is completely silly (not to mention i18n-unfriendly). I've signed > > up someone who will be working on this API redesign. He should be > > contacting the various IM client implementors soon (either via this > > list, or by direct email, not sure yet) to start gathering > > requirements for the v4 API. > > Can you give any ETA so we can plan for our next release? We try to > release 0.12 ASAP, but it will still take a few months and I'd like to > know if there's a possibility we can support OTR in the 0.12 release. > It would be enough to know when the biggest part of the API change is > done so we can base on that. Doesn't matter if libotr 4.0 gets released > after Gajim 0.12 then, at least, we have working support in it then :). Assuming Willy gets good feedback from the IM developers pretty quickly about what they (you) want in the API, we hope to have the requirements spec'd out and the API designed by August. Depending on the scope of the changes, the actual implementation of the new API may take longer. - Ian From ian at cypherpunks.ca Tue May 27 09:52:41 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 09:52:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> On Mon, May 26, 2008 at 08:20:45AM -0400, Ian Goldberg wrote: > Funny you should ask. ;-) > > We're just in the final stages of putting a 3.2.0 preview out. The > main user interface changes include moving the OTR button to the menu > bar (though the button remains an option), support for multiple > buddies merged into a single contact / conversation window, improved > authentication user interface (based on the user study we did, to appear > in SOUPS 2008), and the icons being changed to Tango-based ones. > > My goal is to get it all into a state where it can be put in the public > CVS on sourceforge sometime this week. Then we'll wait a bit for some > feedback, and for the various translators to supply translations for the > new UI strings, and we'll send it out. The current code is now up on the sourceforge cvs. http://sourceforge.net/cvs/?group_id=128860 Translators: Can you update your translations file to include the new text from the new version? See po/README for super-brief instructions, or email me if you're having trouble. Here are the languages (and most recent translators) I currently know about (and are checked in): Arabic: Ahmad Gharbeia ???? ????? German: Thorsten M?hlfelder Spanish: Enrique Martinez Cardenas French: Joel Reardon Dutch: Paul Wouters Russian: Sergei Smirnov Slovak: Milan Plzik If you think you've sent me a translation not listed above, send it again, since I must have misplaced it. (But be sure to update it for 3.2.0 first). Others: Please try out the new code and tell me if something goes horribly wrong (doesn't compile on your platform, doesn't work in some weird case, etc.). My aim is to release 3.2.0 next week or thereabouts. The documentation in the README file, as well as the web-based documentation, still needs to be updated. [If someone wants to help with that, let me know that as well.] Thanks, - Ian The new part of the NEWS file: 28 May 2008: - The functionality of the OTR button has now moved to a menu. There's an "OTR" menu, as well as an icon showing the current OTR state of each active conversation in the window. - New OTR icons from - OTR icons show up inline in the conversation window when the OTR status changes. - Buddy authentication has been revamped, based on the user study published in SOUPS 2008. The default is now to choose a question and an answer only you and the buddy should know. The question is displayed to the buddy, who is prompted for the answer. The "shared secret" and "fingerprint" authentication methods are still available. - Translations for Arabic, German, Russian From fnord at pentabarf.de Tue May 27 10:38:25 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 16:38:25 +0200 Subject: Backwards compatability (was: Re: [OTR-dev] Pidgin plugin development and GUI look) In-Reply-To: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> Message-ID: <1211899105.6268.7.camel@hegg> > Others: > > Please try out the new code and tell me if something goes horribly > wrong (doesn't compile on your platform, doesn't work in some > weird > case, etc.). > > Hi Ian, I've not yet tested your code but had a look at the handling of the SMP1Q tlv. If I read the source code in the svn correctly, does this mean that a 3.1.0 user who receives an SMP1Q TLV sees nothing, as he doesn't know it yet? If so, I think it would be more sensible to just re-use the old SMP1 TLV and add the data section question there, which would result in the same thing for two 3.2.0 users, but 3.1.0 would not see the question (but they would still see the initial SMP request!). Thanks, Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From js-otrim at webkeks.org Tue May 27 10:42:33 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Tue, 27 May 2008 16:42:33 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526215940.GF30190@yoink.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> <20080526220819.1b190450@webkeks.org> <20080526215940.GF30190@yoink.cs.uwaterloo.ca> Message-ID: <20080527164233.76df34c6@webkeks.org> Ok, thanks for the information. We will plan a 0.12 release without OTR then, but keep it in trunk so it's easy to upgrade to the new API once the new libotr is released. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ian at cypherpunks.ca Tue May 27 10:53:54 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 10:53:54 -0400 Subject: [OTR-dev] Re: Backwards compatability In-Reply-To: <1211899105.6268.7.camel@hegg> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <1211899105.6268.7.camel@hegg> Message-ID: <20080527145354.GD6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 04:38:25PM +0200, Kjell Braden wrote: > > Others: > > > > Please try out the new code and tell me if something goes horribly > > wrong (doesn't compile on your platform, doesn't work in some > > weird > > case, etc.). > > > > > Hi Ian, > > I've not yet tested your code but had a look at the handling of the > SMP1Q tlv. If I read the source code in the svn correctly, does this > mean that a 3.1.0 user who receives an SMP1Q TLV sees nothing, as he > doesn't know it yet? If so, I think it would be more sensible to just > re-use the old SMP1 TLV and add the data section question there, which > would result in the same thing for two 3.2.0 users, but 3.1.0 would not > see the question (but they would still see the initial SMP request!). SMP1Q has slightly different semantics from SMP1, so we intentionally made it a different TLV type. If you pose a question to your buddy Bob (who answers it correctly), you will authenticate Bob, but Bob will not automatically authenticate you. If Bob is running 3.1.0, which assumes a preshared secret (which does indeed imply mutual authentication), we don't want his code to "fall back" to authenticating you when it shouldn't, and also, he won't see the question, which will be a subtler problem more likely to be overlooked than the authentication window not coming up at all. - Ian From hcat at gmx.net Tue May 27 11:58:05 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 17:58:05 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527155805.152350@gmx.net> > > configure.ac:30: required file `libotr.pc.in' not found > > Oops; fixed. ;-) Thanks, I'm able to compile libotr now. However the gaim/pidgin plugin is still missing a file: config.status: error: cannot find input file: po/Makefile.in.in -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian at cypherpunks.ca Tue May 27 12:12:49 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 12:12:49 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527155805.152350@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> Message-ID: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 05:58:05PM +0200, hcat at gmx.net wrote: > > > > configure.ac:30: required file `libotr.pc.in' not found > > > > Oops; fixed. ;-) > > Thanks, I'm able to compile libotr now. However the gaim/pidgin plugin is still missing a file: > > config.status: error: cannot find input file: po/Makefile.in.in You forgot to run "intltoolize --force --copy" before autoreconf. - Ian From fnord at pentabarf.de Tue May 27 12:46:06 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 18:46:06 +0200 Subject: [OTR-dev] Re: Backwards compatability In-Reply-To: <20080527145354.GD6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <1211899105.6268.7.camel@hegg> <20080527145354.GD6988@thunk.cs.uwaterloo.ca> Message-ID: <1211906766.6268.13.camel@hegg> > > SMP1Q has slightly different semantics from SMP1, so we intentionally > made it a different TLV type. If you pose a question to your buddy Bob > (who answers it correctly), you will authenticate Bob, but Bob will not > automatically authenticate you. If Bob is running 3.1.0, which assumes > a preshared secret (which does indeed imply mutual authentication), we > don't want his code to "fall back" to authenticating you when it > shouldn't, and also, he won't see the question, which will be a subtler > problem more likely to be overlooked than the authentication window not > coming up at all. > > - Ian I see, I missed the part that the authentication will not be mutual in SMP1Q, so your way makes perfectly sense now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From hcat at gmx.net Tue May 27 13:09:25 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 19:09:25 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527170925.216970@gmx.net> > You forgot to run "intltoolize --force --copy" before autoreconf. > Right. Thanks, works now. I tested the pidgin plugin for a while, it seems to work well. I have however a few notes regarding the UI: 1.) Auth dialog: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-auth.png A) The space seems to be one line to big. B) The nested expanders look bad. IMHO one would be enough (showing 2 paragraphs of text) or even better: a help button which would open a help webpage. C) Window title should be "Authenticate _B_uddy" (not _b_uddy) as per HIG D) Why "other"? I don't see any other options, so just "Authentication Options" would be enough IMHO E) The smiley is nice but it does not really serve a propose. Why not use the GTK stock icon gtk-dialog-authentication? 2.) Chat window: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-chat.png A) The background of the user icon should be transparent, not white. It looks a bit broken this way. B) Why is the chat partner's account listed here? Clicking it does nothing... IMHO this is confusing and should be removed... or does it serve a purpose I don't get ATM? C) This seems to show the status again (duplication, as it is also shown in the menu header). Clicking it opens the webpage, I wonder if a "What is OTR?" or "What does this all mean?" menu entry would not be better. Generally I like how the icon is integrated now, but I don't like the way the same menu opens when pressing "OTR" or the icon behind. It should be possible to combine both to only one menu (with text and icon). Perhaps also add the status as a text there? I have done a mockup for this: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-1.png Also, I have the feeling that having the OTR indicator closer to the text box would be better. The same menu could be integrated into the toolbar (as a 3rd option?): http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx From xx.0mmg at gmail.com Tue May 27 15:21:48 2008 From: xx.0mmg at gmail.com (Patrik Willard) Date: Tue, 27 May 2008 21:21:48 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527170925.216970@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> Message-ID: <483C5F4C.6050808@gmail.com> hcat at gmx.net wrote: > Also, I have the feeling that having the OTR indicator closer to the text box would be better. The same menu could be integrated into the toolbar (as a 3rd option?): http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png > > Cheers, > -Michael A friend of mine experimented with just this, and the result was pretty good. He wrote a blog-post about it ( http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) Cheers, -Patrik From ian at cypherpunks.ca Tue May 27 15:34:17 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 15:34:17 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527170925.216970@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> Message-ID: <20080527193417.GI6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 07:09:25PM +0200, hcat at gmx.net wrote: > > You forgot to run "intltoolize --force --copy" before autoreconf. > > > > Right. Thanks, works now. > > I tested the pidgin plugin for a while, it seems to work well. I have however a few notes regarding the UI: > > 1.) Auth dialog: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-auth.png > A) The space seems to be one line to big. There's no explicit whitespace being added; I'm not sure where it's coming from. Any ideas? The stuff underneath is in a notebook page; maybe that's it? > B) The nested expanders look bad. IMHO one would be enough (showing 2 > paragraphs of text) or even better: a help button which would open a > help webpage. I wanted at least some help text that doesn't entail going to the web. You're suggesting just having "What's this?" open the HTML widget directly, with the current first-level text as its first paragraph? > C) Window title should be "Authenticate _B_uddy" (not _b_uddy) as per > HIG Fair enough. Fixed. > D) Why "other"? I don't see any other options, so just "Authentication > Options" would be enough IMHO Also fixed. > E) The smiley is nice but it does not really serve a propose. Why not > use the GTK stock icon gtk-dialog-authentication? It's the stock INFO icon. The stock authentication icon is a lock, and a lock just really doesn't convey what's going on here, in my opinion. > 2.) Chat window: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-chat.png > A) The background of the user icon should be transparent, not white. > It looks a bit broken this way. Hmm. The original pngs *do* have a transparent background. The background in your image isn't in fact white; it's the background colour of the menu bar. Might this be a bug in how GTK handles menus labelled by icons (an admittedly unusual case)? > B) Why is the chat partner's account listed here? Clicking it does > nothing... IMHO this is confusing and should be removed... or does it > serve a purpose I don't get ATM? Ah, it's because you can group buddies into contacts, and all buddies from a single contact show up in the same conversation window. So we need some way to show that there are multiple conversations going on at the same time, and they may have different OTR statuses. Try picking different things from your "Send To" menu; you'll see the single OTR menu (representing the "current" conversation), but multiple icons (representing all conversations, labelled by who you're talking to). Indeed, it's unfortunate that clicking it does nothing. If anyone knows a way to make that menu item not highlight at all, I'd love to do that. [But making it inactive causes it to grey out so much that I found it unreadable.] > C) This seems to show the status again (duplication, as it is also > shown in the menu header). Except it's shown in the menu header just as an icon; the added text may be useful for people new to OTR. > Clicking it opens the webpage, I wonder if a "What is OTR?" or "What > does this all mean?" menu entry would not be better. Good call. Fixed. > Generally I like how the icon is integrated now, but I don't like the > way the same menu opens when pressing "OTR" or the icon behind. It > should be possible to combine both to only one menu (with text and > icon). Perhaps also add the status as a text there? I have done a > mockup for this: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-1.png As above, this is because there can be multiple icons for multiple conversations in the same window. > Also, I have the feeling that having the OTR indicator closer to the > text box would be better. The same menu could be integrated into the > toolbar (as a 3rd option?): > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png We left the button available for people who want something like this. Do you think this is vitally important? (Do most people leave that toolbar visible at all?) Thanks so much for your feedback! I'm checking in the above changes now. - Ian From hcat at gmx.net Tue May 27 15:34:18 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 21:34:18 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <483C5F4C.6050808@gmail.com> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> Message-ID: <20080527193418.56680@gmx.net> > A friend of mine experimented with just this, and the result was pretty > good. > He wrote a blog-post about it ( > http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) I really like that, even better to put it aligned to the right edge of the toolbar instead of as the next "button" on the toolbar. I also feel that having the colored text works very well and is a lot better than even the nicer icons we have right now. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx From ian at cypherpunks.ca Tue May 27 15:44:58 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 15:44:58 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527193418.56680@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> Message-ID: <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 09:34:18PM +0200, hcat at gmx.net wrote: > > A friend of mine experimented with just this, and the result was pretty > > good. > > He wrote a blog-post about it ( > > http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) > > I really like that, even better to put it aligned to the right edge of > the toolbar instead of as the next "button" on the toolbar. I also > feel that having the colored text works very well and is a lot better > than even the nicer icons we have right now. One of the issues identified in the user study is that people couldn't figure out how to get to the "Authenticate buddy" menu item. With the button, you needed to right-click on the button to bring up the context menu, which stymied a number of people. They suggested to move it to a menu (for which (left-)clicking is the obvious way to pull down a menu), so that's what we did. We'd also have to think about how to handle the multiple-conversations-in-one-window case. - Ian From hcat at gmx.net Tue May 27 16:02:48 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 22:02:48 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527200248.56650@gmx.net> [sending again to the list... webmail sucks for mailing lists :(] > One of the issues identified in the user study is that people couldn't > figure out how to get to the "Authenticate buddy" menu item. With the > button, you needed to right-click on the button to bring up the context > menu, which stymied a number of people. They suggested to move it to a > menu (for which (left-)clicking is the obvious way to pull down a menu), > so that's what we did. Why the right click? (Left-)Clicking the "OTR: " like Patrik linked would just display a small menu just like the formatting and insert "toolbar buttons" do. Well, the OTR menu item could even stay in the menu bar (minus the icon, which looks a bit alien there anyway) and the "OTR: " could just display the status down in the toolbar. From fnord at pentabarf.de Tue May 27 16:11:22 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 22:11:22 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527200248.56650@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> Message-ID: <1211919082.7542.2.camel@hegg> Am Dienstag, den 27.05.2008, 22:02 +0200 schrieb hcat at gmx.net: > [sending again to the list... webmail sucks for mailing lists :(] > > > One of the issues identified in the user study is that people > couldn't > > figure out how to get to the "Authenticate buddy" menu item. With > the > > button, you needed to right-click on the button to bring up the > context > > menu, which stymied a number of people. They suggested to move it > to a > > menu (for which (left-)clicking is the obvious way to pull down a > menu), > > so that's what we did. > > Why the right click? (Left-)Clicking the "OTR: " like Patrik > linked would just display a small menu just like the formatting and > insert "toolbar buttons" do. > Well, the OTR menu item could even stay in the menu bar (minus the > icon, which looks a bit alien there anyway) and the "OTR: " > could just display the status down in the toolbar. I'd love this toolbar approach. Not sure if that's what hcat just suggested, but I'd suggest using the "OTR: " thing in the toolbar as a menu, with the contents from what is in the menu on the top. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ian at cypherpunks.ca Tue May 27 16:13:56 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:13:56 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527200248.56650@gmx.net> References: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> Message-ID: <20080527201356.GO6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:01:08PM +0200, hcat at gmx.net wrote: > > One of the issues identified in the user study is that people > > couldn't figure out how to get to the "Authenticate buddy" menu > > item. With the button, you needed to right-click on the button to > > bring up the context menu, which stymied a number of people. They > > suggested to move it to a menu (for which (left-)clicking is the > > obvious way to pull down a menu), so that's what we did. > > Why the right click? (Left-)Clicking the "OTR: " like Patrik > linked would just display a small menu just like the formatting and > insert "toolbar buttons" do. Yes, it could, but that's not what the linked-to patch does, is all I'm saying. > Well, the OTR menu item could even stay in the menu bar (minus the > icon, which looks a bit alien there anyway) and the "OTR: " > could just display the status down in the toolbar. How would you show multiple conversations? If we could figure this out, someone could try to add it at least as an option. - Ian From hcat at gmx.net Tue May 27 16:14:38 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 22:14:38 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527193417.GI6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527201438.56660@gmx.net> > I wanted at least some help text that doesn't entail going to the web. > You're suggesting just having "What's this?" open the HTML widget > directly, with the current first-level text as its first paragraph? I didn't realize that it embeds a HTML widget. I just don't see the need for two expanders here, if a user really wants some help text he/she will most likely open the second expander as well, just to see what's written there. > It's the stock INFO icon. The stock authentication icon is a lock, and > a lock just really doesn't convey what's going on here, in my opinion. Ah... yeah that's theme dependent. GTK uses a lock, GNOME icon theme uses some kind of a keyring. "Info" hmm... > Hmm. The original pngs *do* have a transparent background. The > background in your image isn't in fact white; it's the background colour > of the menu bar. Might this be a bug in how GTK handles menus labelled > by icons (an admittedly unusual case)? I just ran a few more tests with different GTK themes and engines and it looks like most are affected. Only the very basic ones display "correctly"... Not sure if this is a GTK or engine bug though. > Ah, it's because you can group buddies into contacts, and all buddies > from a single contact show up in the same conversation window. So we > need some way to show that there are multiple conversations going on at > the same time, and they may have different OTR statuses. Try picking > different things from your "Send To" menu; you'll see the single OTR > menu (representing the "current" conversation), but multiple icons > (representing all conversations, labelled by who you're talking to). > Indeed, it's unfortunate that clicking it does nothing. If anyone knows > a way to make that menu item not highlight at all, I'd love to do that. > [But making it inactive causes it to grey out so much that I found it > unreadable.] I understand this now, but I take it for a bad sign that I was not able to get the meaning myself. But indeed not easy to solve... > We left the button available for people who want something like this. > Do you think this is vitally important? (Do most people leave that > toolbar visible at all?) I didn't know the toolbar can be disabled... IMHO the old button takes a way too much space. Integrating the OTR status into the toolbar (like http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/) doesn't change the pidgin UI too much but still shows the OTR status very nicely. Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx From ian at cypherpunks.ca Tue May 27 16:24:11 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:24:11 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527201438.56660@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> Message-ID: <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:14:38PM +0200, hcat at gmx.net wrote: > > I wanted at least some help text that doesn't entail going to the web. > > You're suggesting just having "What's this?" open the HTML widget > > directly, with the current first-level text as its first paragraph? > > I didn't realize that it embeds a HTML widget. I just don't see the > need for two expanders here, if a user really wants some help text > he/she will most likely open the second expander as well, just to see > what's written there. I can see about making this change. Not today, though. > I just ran a few more tests with different GTK themes and engines and > it looks like most are affected. Only the very basic ones display > "correctly"... Not sure if this is a GTK or engine bug though. In any event, I'm pretty sure it's nothing we can fix. > I understand this now, but I take it for a bad sign that I was not > able to get the meaning myself. But indeed not easy to solve... But even if you don't understand why it's there, it's at worst a bit redundant. > > We left the button available for people who want something like this. > > Do you think this is vitally important? (Do most people leave that > > toolbar visible at all?) > I didn't know the toolbar can be disabled... IMHO the old button takes > a way too much space. Integrating the OTR status into the toolbar > (like http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/) > doesn't change the pidgin UI too much but still shows the OTR status > very nicely. Yes, I totally agree. We just need (a) to find a way to do it that still allows for multiple conversations, and (b) someone to actually do it once we figure out what ought to be done. - Ian From hcat at gmx.net Tue May 27 16:35:41 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 22:35:41 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527201356.GO6988@thunk.cs.uwaterloo.ca> References: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527203541.56660@gmx.net> Wow this is one fast mailing list ;) > How would you show multiple conversations? If we could figure this out, > someone could try to add it at least as an option. Btw are we talking about "multiple conversations" like a) having multiple conversations to multiple persons in the same window using tabs or b) chatting with a meta contact using more than one account at a time (e.g. XMPP and ICQ)? For a), showing the status icon in the menu bar is a bit confusing IMHO. The menu is relative to the selected tab, but the user could also interpret it as relative to all of the tabs. For b) this would be the same in the toolbar as what is now in the menu bar. Without clicking, "OTR: " would be relative to what you currently use. I'm not sure about this but if you write to someone using XMPP and he replies using ICQ, will your reply go out using ICQ? If this is the case, the stauts should change to the new active protocol. The popup would have status information for all accounts, similar to what is currently in the menu (which I think can still be improved to make it more obvious). Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx From ian at cypherpunks.ca Tue May 27 16:50:39 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:50:39 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> References: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527205039.GR6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 04:24:11PM -0400, Ian Goldberg wrote: > On Tue, May 27, 2008 at 10:14:38PM +0200, hcat at gmx.net wrote: > > > I wanted at least some help text that doesn't entail going to the web. > > > You're suggesting just having "What's this?" open the HTML widget > > > directly, with the current first-level text as its first paragraph? > > > > I didn't realize that it embeds a HTML widget. I just don't see the > > need for two expanders here, if a user really wants some help text > > he/she will most likely open the second expander as well, just to see > > what's written there. > > I can see about making this change. Not today, though. Maybe I'm wrong. I'm not going to check this in right now, but apply this patch and tell me what you think. - Ian -------------- next part -------------- Index: gtk-dialog.c =================================================================== RCS file: /cvsroot/otr/gaim-otr/gtk-dialog.c,v retrieving revision 1.18 diff -u -r1.18 gtk-dialog.c --- gtk-dialog.c 27 May 2008 19:54:06 -0000 1.18 +++ gtk-dialog.c 27 May 2008 20:48:05 -0000 @@ -423,33 +423,21 @@ const char *moremarkup) { GtkWidget *expander; - GtkWidget *ebox; - GtkWidget *whatsthis; - GtkWidget *more; - GtkWidget *frame; GtkWidget *scrl; GtkWidget *imh; GdkFont *font; + char *alltext; expander = gtk_expander_new_with_mnemonic(_("_What's this?")); gtk_box_pack_start(GTK_BOX(vbox), expander, FALSE, FALSE, 0); - frame = gtk_frame_new(NULL); - gtk_container_add(GTK_CONTAINER(expander), frame); - ebox = gtk_vbox_new(FALSE, 10); - gtk_container_add(GTK_CONTAINER(frame), ebox); - whatsthis = gtk_label_new(NULL); - gtk_label_set_line_wrap(GTK_LABEL(whatsthis), TRUE); - gtk_label_set_markup(GTK_LABEL(whatsthis), whatsthismarkup); - - gtk_box_pack_start(GTK_BOX(ebox), whatsthis, FALSE, FALSE, 0); - more = gtk_expander_new_with_mnemonic(_("_More...")); - gtk_box_pack_start(GTK_BOX(ebox), more, FALSE, FALSE, 0); scrl = gtk_scrolled_window_new(NULL, NULL); - gtk_container_add(GTK_CONTAINER(more), scrl); + gtk_container_add(GTK_CONTAINER(expander), scrl); imh = gtk_imhtml_new(NULL, NULL); pidgin_setup_imhtml(imh); - gtk_imhtml_append_text(GTK_IMHTML(imh), moremarkup, GTK_IMHTML_NO_SCROLL); + alltext = g_strdup_printf("%s\n\n%s", whatsthismarkup, moremarkup); + gtk_imhtml_append_text(GTK_IMHTML(imh), alltext, GTK_IMHTML_NO_SCROLL); + g_free(alltext); gtk_container_add(GTK_CONTAINER(scrl), imh); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrl), @@ -459,7 +447,7 @@ * is (a) complicated, and (b) not fully supported by older versions * of libpango, which some people may have. */ font = gtk_style_get_font(imh->style); - gtk_widget_set_size_request(scrl, -1, 6 * (font->ascent + font->descent)); + gtk_widget_set_size_request(scrl, -1, 10 * (font->ascent + font->descent)); } From ian at cypherpunks.ca Tue May 27 16:53:41 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:53:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527203541.56660@gmx.net> References: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> Message-ID: <20080527205341.GS6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:35:41PM +0200, hcat at gmx.net wrote: > Wow this is one fast mailing list ;) > > > How would you show multiple conversations? If we could figure this out, > > someone could try to add it at least as an option. > > Btw are we talking about "multiple conversations" like a) having > multiple conversations to multiple persons in the same window using > tabs or b) chatting with a meta contact using more than one account at > a time (e.g. XMPP and ICQ)? We're talking about b. When the user switches tabs, the status in the menu bar changes appropriately. > For a), showing the status icon in the menu bar is a bit confusing > IMHO. The menu is relative to the selected tab, but the user could > also interpret it as relative to all of the tabs. It is indeed relative to the selected tab. > For b) this would be the same in the toolbar as what is now in the > menu bar. Without clicking, "OTR: " would be relative to what > you currently use. I'm not sure about this but if you write to someone > using XMPP and he replies using ICQ, will your reply go out using ICQ? > If this is the case, the stauts should change to the new active > protocol. The popup would have status information for all accounts, > similar to what is currently in the menu (which I think can still be > improved to make it more obvious). But we'd like it obvious at a glance that there are multiple conversations of differing security happening at once. Try it out with the currently checked-in code to see how it works now. - Ian From hcat at gmx.net Tue May 27 17:46:16 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Tue, 27 May 2008 23:46:16 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527205039.GR6988@thunk.cs.uwaterloo.ca> References: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527214616.167040@gmx.net> > Maybe I'm wrong. I'm not going to check this in right now, but apply > this patch and tell me what you think. I think it looks cleaner than before. I think I would also move the expander to the left (aligned with the other expander. -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx From hcat at gmx.net Tue May 27 18:41:08 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Wed, 28 May 2008 00:41:08 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527205341.GS6988@thunk.cs.uwaterloo.ca> References: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527224108.167060@gmx.net> To the list... > But we'd like it obvious at a glance that there are multiple > conversations of differing security happening at once. Try it out with > the currently checked-in code to see how it works now. Another quick mockup from me that tries to address the multi conversations problem: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-3.png This is using the details bar to display all active accounts and their OTR status. Normally they are flat tiles, hovering them would give the same button feedback as hovering the toolbar does, pressing either (left) would pop up a menu similar to the current menu popup (shown at the bottom of the mockup). Alternatively the tiles could show the OTR status icon instead of the protocol icon. Either way, the currently inactive icon(s) should be displayed with about 30% transparency (mockup uses 50% but this is not enough I think). Grayscaling is not a good idea as it would look disabled and for example the "not private" icon is already gray. IMHO this would be another nice option with the advantage that the different account states belong to the active tab. Still having a simple "OTR: " or "OTR: " or "OTR: " on the right side of the toolbar would be nice because: a) you mostly care about what you will get on the next send. If you type and look at the text box, you will notice a "not private" icon or red text there, but probably not notice those when they are only displyed at the top of the window. b) I don't think multi-account chats are *that* common. I have quite a few meta contacts with people who have 2-5 different accounts, but it rarely happens that accounts get changed during conversations. Cheers, -Michael -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian at cypherpunks.ca Tue May 27 20:19:01 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 20:19:01 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527214616.167040@gmx.net> References: <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> Message-ID: <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> On Tue, May 27, 2008 at 11:46:16PM +0200, hcat at gmx.net wrote: > > Maybe I'm wrong. I'm not going to check this in right now, but apply > > this patch and tell me what you think. > > I think it looks cleaner than before. I think I would also move the > expander to the left (aligned with the other expander. Except that that expander is part of the notebook pane; there are separate instructions for each authentication option. - Ian From hcat at gmx.net Wed May 28 06:25:11 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Wed, 28 May 2008 12:25:11 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> References: <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> Message-ID: <20080528102511.22440@gmx.net> > Except that that expander is part of the notebook pane; > there are separate instructions for each authentication > option. Another thing which I did not notice right away! Ok, let's restart this. The main problem of the dialog as I see it is that the workflow is backward or upside-down :) Dialogs should work from top to bottom. In this case, if you want to change the auth method, you have to use the last control first, which then changes the (hidden) help text and the input fields above that. The last thing you actually do is input secret and/or question at the top of the dialog. I have redesigned the whole dialog to work around these problems: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-4.png - The "Authenticate " line stays but "again" appended to show that you already authenticated the user once (instead of the string that was shown below... is this enough?) - Below the line the first part of the help text is drawn. This is short and catchy and guides the user through the dialog, so I don't need the use of hiding it first. Also, this place is definitely better than below the input fields. - Next I put the auth method selection, as a combo box instead of a radio. IMHO this is easier to the eyes and takes away less space. Again, no real need to hide this by default IMHO. - The next parts will change if the combo selection changes. - Following is the second part of the help text. This is drawn using a slightly smaller italic font. We do the same in the preferences menu of Banshee btw. - Last, we have the actual input boxes for the secrets/questions etc. - I also changed the "OK" button to read "Send Request", as the HIG discourages the use of generic button labels like "OK"; instead the button should always say what it does. How do you like this? I have to say I'm really happy with this design. Cheers, -Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From ian at cypherpunks.ca Wed May 28 08:10:41 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 08:10:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528102511.22440@gmx.net> References: <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> Message-ID: <20080528121041.GA24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 12:25:11PM +0200, hcat at gmx.net wrote: > > Except that that expander is part of the notebook pane; > > there are separate instructions for each authentication > > option. > > Another thing which I did not notice right away! > > Ok, let's restart this. The main problem of the dialog as I see it is that the workflow is backward or upside-down :) > > Dialogs should work from top to bottom. In this case, if you want to change the auth method, you have to use the last control first, which then changes the (hidden) help text and the input fields above that. The last thing you actually do is input secret and/or question at the top of the dialog. > > I have redesigned the whole dialog to work around these problems: > > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-4.png I like the concept, but have a few questions about the details. > - The "Authenticate " line stays but "again" appended to show > that you already authenticated the user once (instead of the string > that was shown below... is this enough?) I don't think it's enough. The appearance of "again" is *way* too subtle, I think. > - Below the line the first part of the help text is drawn. This is > short and catchy and guides the user through the dialog, so I don't > need the use of hiding it first. Also, this place is definitely better > than below the input fields. The rest of the help text is now entirely absent, including the link to the web-based help pages. > - Next I put the auth method selection, as a combo box instead of a > radio. IMHO this is easier to the eyes and takes away less space. > Again, no real need to hide this by default IMHO. I'm just worried about putting so much text into a combo box. Especially in some other languages, this would make the box really, really wide, no? > - The next parts will change if the combo selection changes. > > - Following is the second part of the help text. This is drawn using a slightly smaller italic font. We do the same in the preferences menu of Banshee btw. > > - Last, we have the actual input boxes for the secrets/questions etc. > > - I also changed the "OK" button to read "Send Request", as the HIG > discourages the use of generic button labels like "OK"; instead the > button should always say what it does. I don't think "Send request" is the right thing to say here, though. The word "request" appears nowhere else in the dialog. - Ian From ian at cypherpunks.ca Wed May 28 08:59:18 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 08:59:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527224108.167060@gmx.net> References: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> <20080527224108.167060@gmx.net> Message-ID: <20080528125918.GB24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 12:41:08AM +0200, hcat at gmx.net wrote: > Still having a simple "OTR: " or "OTR: " or > "OTR: " on the right side of the toolbar > would be nice because: > > a) you mostly care about what you will get on the next send. If you > type and look at the text box, you will notice a "not private" icon or > red text there, but probably not notice those when they are only > displyed at the top of the window. > b) I don't think multi-account chats are *that* common. I have quite a > few meta contacts with people who have 2-5 different accounts, but it > rarely happens that accounts get changed during conversations. I've checked in a change to move the OTR button to the toolbar (but keeping the menus). You'll have to enable "Show OTR button" in the plugin config (the default should now be "yes", but if you've run the CVS code already, you'll have it set to "no"). Tell me what you think. In any event, I'd change the menu to look like the ones in the menu bar. - Ian From mail at code.mmsources.de Wed May 28 09:26:49 2008 From: mail at code.mmsources.de (Michael Meier) Date: Wed, 28 May 2008 15:26:49 +0200 Subject: [OTR-dev] German translation for Pidgin-otr 3.2.0 Message-ID: <483D5D99.7090609@code.mmsources.de> Hello Ian, thank you for informing me about the upcoming release of pidgin-otr 3.2.0, so i could update the translation accordingly. However, i found one inconsistency. The text box for entering the secret/answer included the hint "Enter secret here" in pidgin-otr 3.1.0. Now it's just supposed to be left as an empty text box but because of these two gettext macros, the po header dummy entry is pulled in as replacement instead: gtk-dialog.c: 649 gtk_entry_set_text(GTK_ENTRY(entry), _("")); gtk-dialog.c: 557 gtk_entry_set_text(GTK_ENTRY(entry), _("")); http://data.mmsources.de/pidgin-otr3.2-localization.png Also, these two entries are not yet localized by gettext: gtk-dialog.c: 638 label_text = g_strdup_printf("Enter secret here:"); gtk-dialog.c: 500 label_text = g_strdup_printf("Enter question here:"); Please inform me when you changed this and if you change any more strings before release, so i can keep the translation up-to-date . I'm also subscribed to this mailing list. Regards, Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: de.po URL: From ian at cypherpunks.ca Wed May 28 11:07:24 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 11:07:24 -0400 Subject: [OTR-dev] German translation for Pidgin-otr 3.2.0 In-Reply-To: <483D5D99.7090609@code.mmsources.de> References: <483D5D99.7090609@code.mmsources.de> Message-ID: <20080528150724.GE24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 03:26:49PM +0200, Michael Meier wrote: > Hello Ian, > > thank you for informing me about the upcoming release of pidgin-otr > 3.2.0, so i could update the translation accordingly. > > However, i found one inconsistency. The text box for entering the > secret/answer included the hint "Enter secret here" in pidgin-otr 3.1.0. > Now it's just supposed to be left as an empty text box but because of > these two gettext macros, the po header dummy entry is pulled in as > replacement instead: > > gtk-dialog.c: 649 > gtk_entry_set_text(GTK_ENTRY(entry), _("")); > > gtk-dialog.c: 557 > gtk_entry_set_text(GTK_ENTRY(entry), _("")); > > http://data.mmsources.de/pidgin-otr3.2-localization.png > > > Also, these two entries are not yet localized by gettext: > > > gtk-dialog.c: 638 > label_text = g_strdup_printf("Enter secret here:"); > > gtk-dialog.c: 500 > label_text = g_strdup_printf("Enter question here:"); Fixed, thanks! > Please inform me when you changed this and if you change any more > strings before release, so i can keep the translation up-to-date . I'm > also subscribed to this mailing list. The ongoing discussions about the authentication dialog will almost certainly produce some new strings to be translated, so keep an eye on this list. - Ian From hcat at gmx.net Wed May 28 12:23:35 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Wed, 28 May 2008 18:23:35 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528121041.GA24571@thunk.cs.uwaterloo.ca> References: <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> Message-ID: <20080528162335.301970@gmx.net> > I like the concept, but have a few questions about the details. Sure! > I don't think it's enough. The appearance of "again" is *way* too > subtle, I think. Yeah I was thinking about this, too. There could be a "Note: This buddy is already autheticated." between the first text and the combo box. > The rest of the help text is now entirely absent, including the link to > the web-based help pages. Where is this link to be found in the original dialog? Anyway, why not add a normal [Help] button to the bottom left of the dialog for this? > I'm just worried about putting so much text into a combo box. > Especially in some other languages, this would make the box really, > really wide, no? This is a valid concern but I think we can get away with less text because of the detailed description below the combo box. Perhaps as simple as: - Question and Answer - Shared Secret - Fingerprint This should do for the combo box IMHO. Especially if you know what you are looking for, having to read less text for the various choices is nice. The details would be explained by the text below the combo as well as the input area below (which changes accordingly to the selected method). > I don't think "Send request" is the right thing to say here, though. > The word "request" appears nowhere else in the dialog. Well I was first thinking about a simple "Authenticate". Perhaps anyone else has a better idea. The "OK" button (while certainly not what the HIG wants) is not the biggest concern here, though. -Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From ian at cypherpunks.ca Wed May 28 13:15:50 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 13:15:50 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528162335.301970@gmx.net> References: <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> Message-ID: <20080528171550.GI24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 06:23:35PM +0200, hcat at gmx.net wrote: > > The rest of the help text is now entirely absent, including the link to > > the web-based help pages. > Where is this link to be found in the original dialog? Anyway, why not > add a normal [Help] button to the bottom left of the dialog for this? It's in the scrollable help text. We could easily add a help button, but you'd still be missing a lot of the text that's there now. I agree with pretty much everything else you've written, though. But it would be really, really useful if someone other than me actually wrote the code; I could do it, but probably not for a little while. Thanks! - Ian From hcat at gmx.net Wed May 28 15:40:05 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Wed, 28 May 2008 21:40:05 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528171550.GI24571@thunk.cs.uwaterloo.ca> References: <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> Message-ID: <20080528194005.115490@gmx.net> > It's in the scrollable help text. We could easily add a help button, > but you'd still be missing a lot of the text that's there now. I would just describe the selected auth method in 2-3 lines in the dialog and then link to a webpage with in-depths information and examples. Security is not a trivial matter and users should at least have a basic understanding of what they are doing, which is best done reading some introduction document but not fitting tons of information for 1st time users in every dialog etc. [This is re your other mail about the toolbar button:] > Tell me what you think. In any event, I'd change the menu to look like > the ones in the menu bar. I like it. It would be nice to be able to disable the menu integration optionally. Cheers, -Michael -- Super-Aktion nur in der GMX Spieleflat: 10 Tage f?r 1 Euro. ?ber 180 Spiele downloaden: http://flat.games.gmx.de From ian at cypherpunks.ca Thu May 29 10:00:18 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 29 May 2008 10:00:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528125918.GB24571@thunk.cs.uwaterloo.ca> References: <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> <20080527224108.167060@gmx.net> <20080528125918.GB24571@thunk.cs.uwaterloo.ca> Message-ID: <20080529140018.GC25808@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 08:59:18AM -0400, Ian Goldberg wrote: > I've checked in a change to move the OTR button to the toolbar (but > keeping the menus). You'll have to enable "Show OTR button" in the > plugin config (the default should now be "yes", but if you've run the > CVS code already, you'll have it set to "no"). > > Tell me what you think. In any event, I'd change the menu to look like > the ones in the menu bar. I've changed the menu on the toolbar button to match those in the menu bar. I also figured out how to make the informational items (buddy name and OTR status) non-selectable. Perhaps I'll give a quick go at reformatting the authenticate buddy dialog later this afternoon. - Ian From ian at cypherpunks.ca Thu May 29 17:21:56 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 29 May 2008 17:21:56 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528194005.115490@gmx.net> References: <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> <20080528194005.115490@gmx.net> Message-ID: <20080529212156.GP30190@yoink.cs.uwaterloo.ca> On Wed, May 28, 2008 at 09:40:05PM +0200, hcat at gmx.net wrote: > > It's in the scrollable help text. We could easily add a help button, > > but you'd still be missing a lot of the text that's there now. > I would just describe the selected auth method in 2-3 lines in the > dialog and then link to a webpage with in-depths information and > examples. Security is not a trivial matter and users should at least > have a basic understanding of what they are doing, which is best done > reading some introduction document but not fitting tons of information > for 1st time users in every dialog etc. > > [This is re your other mail about the toolbar button:] > > > Tell me what you think. In any event, I'd change the menu to look like > > the ones in the menu bar. > I like it. It would be nice to be able to disable the menu integration > optionally. OK, give it a try now. I've done both the button-in-the-toolbar and the updated authentication dialog (based on your mockup). Anyone else have any changes to suggest before letting the translators go at it? Thanks, - Ian From ldm at gmx.at Fri May 30 01:05:23 2008 From: ldm at gmx.at (Markus Krainz) Date: Fri, 30 May 2008 07:05:23 +0200 Subject: [OTR-dev] OTR third-party miranda plugin Message-ID: <200805300705.m4U75Z8h002072@paip.net> Hi! I testeted the miranda plugin and concluded that it has several serve bugs. Even closing and opening the message window confuses the otr session and leads in error messages and unsent messages that are so annoying that I found the program unusable. That is unfortunate, because a lot of my friends use Miranda and I think the deniability and the opportunistic encryption features render otr the best, if not the only usable im encryption. To cut a long story short, is there a new plugin version coming out soon? With regards, Markus From hcat at gmx.net Sat May 31 11:49:59 2008 From: hcat at gmx.net (hcat at gmx.net) Date: Sat, 31 May 2008 17:49:59 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080529212156.GP30190@yoink.cs.uwaterloo.ca> References: <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> <20080528194005.115490@gmx.net> <20080529212156.GP30190@yoink.cs.uwaterloo.ca> Message-ID: <20080531154959.250700@gmx.net> > OK, give it a try now. I've done both the button-in-the-toolbar and > the updated authentication dialog (based on your mockup). Nice! I really like it. > Anyone else have any changes to suggest A few random: - Would it be able to make the menu integration in chats default but optional? - Would it be possible to mark the fingerprints inside the auth dialog as selectable (to easily copy them)? - Perhaps resize the auth dialog according to the space needed (e.g. question&answer takes less space than fingerprint so the dialog could be smaller) Also, I tried to test some stuff while a buddy was offline and it seems he got a message about me trying to initiate a private connection with him or something. I also noticed that the status stays "Private" even after the buddy went offline. Does this make sense? I suppose supporting invisible mode for some protocols would be an issue but how about dropping "Private" when the buddy goes offline and if the user tries to establish another private chat, warn him that this will fail if the buddy is really offline (and not just invisible). Though maybe I'm overlooking something here. Cheers, -Michael -- Super-Aktion nur in der GMX Spieleflat: 10 Tage f?r 1 Euro. ?ber 180 Spiele downloaden: http://flat.games.gmx.de