Ralf Skyper Kaiser spake unto us the following wisdom: > > > 1. Do not allow non-private chats > > > > I don't know what this means. > > ...if OTR plugin is available then do not allow non-encrypted private > messages.
Oh, OTR. This is a problem for the OTR plugin. We started discussions wit the OTR people to bring it into Pidgin proper, but they disappeared and it has never happened. Until it does, it's not something we can do anything about. > > 4. Feature to select CAfile storage location > > > > This is already provided, as a compile-time option. > > This is not feasible to the average user. (point taken, developers know how > to use pidgin securely. everyone else should go to hell?) That's not what I said. So ... you started with a list of demands with no justification, you apparently ignored or disregarded existing functionality, and as we attempt to refine the situation you resort to ego-bribery and reductio ad absurdum. It makes it hard to take you seriously. You may have some good points, but they're hard to find past the noise. So, if we assume charitably that your cat sat on the keyboard and made you look like a jerk, your response before that point probably said "I would like a runtime option, because while I want the store to be exclusive and immutable, I want the store to be non-exclusive and mutable." At which point I say ... what are you trying to solve? Give me a use case and we can talk about options. I don't see any reason why putting certificates in the predefined store is inferior to changing the location of the store at runtime, and since you seem to be concerned about users accidentally changing options, I'd say the former is preferable to the latter. Justify. > > > 5. Force client to disable logging > > > > This is not an "option", but can easily be achieved by marking > > ~/.purple/logs unwriteable by the user. > > > Option should be available cross-platform and without OS specific hacks. That's cross-platform and not OS-specific, you can even do the same thing on Windows ... assuming you're using Windows and still pretending to be concerned about security (?). I agree that it's inelegant. However, I don't really get what you're trying to accomplish, if a simple option to turn off logging is not sufficient, and you want an option to turn off the option that turns off logging. Justify. > > > 6. Inform server that user is using lockdown (so that server can > > reject > > > all clients which do not). > > > > This is not useful, as a client can readily lie. > > This is not the point. The client can also circumvent your no-logging idea > by putting up a camera and filming his screen. > > The point is that it takes reasonable effort and prevents _accidental_ > client misconfiguration. I ... still don't get this. > > > 7. Once lockdown option is enabled the user should not be able to > > > change any of the above options until lockdown is disabled again > > > (e.g. gray out the option). Disconnect when lockdown option > > > changes and reconnect to all servers. > > > > I don't see what this buys. We're unlikely to implement it. > > Prevents accidental misconfiguration by the user. A server rule could > create a rule to only let clients connect that are in lockdown. This would > ensure against these accidental misconfigurations: > > 1. User has logging disabled > 2. User is authenticating against server supplied/server-trusted cert (and > not one of the 600+ CA's out there) > 3. User can not send unencrypted private messages > etcetcetc. So maybe you're just saying something very confusing here. You don't want an option that locks down the preferences, you want an option that automatically sets a variety of security preferences to "known good" settings? Your initial description sounded like you wanted an option to disable further configuration tweaks, regardless of what the current configuration is. If your assertion is, instead, that there should be a "secure everything" global option, then I'd say this is a reasonable idea, but your specific implementation is not great. I'd be more inclined to have a dropdown box in a security tab with a couple of options. Maybe: * Secure all communications, untrusted local storage * Secure all communications, trusted local storage * Require encrypted server connections * Allow insecure connections * Custom settings The first locks down everything you've asked for, the second does the same but allows logging, the third enforces "Use SSL/TLS Encryption" for every connection but makes no other security-related demands, the fourth enforces "Use SSL/TLS if available", and the final setting lets each preference do its own thing. My pushback on this is that the complexity of implementation is pretty high, and I don't really think the benefit is that large. I wouldn't implement it, but if somebody handed it to me and it was good, I would probably take it. > > This is a disingenuous and misplaced statement. I assume you're > > trying to bribe egos. However, a) Pidgin is already used by many > > millions of users, b) the "much larger user base" is a small fraction > > of those millions consisting of (for example) certain financial > > companies, a small number of privacy-concerned tech-savvy individuals, > > etc. > > I think there is a use case for such a feature. There is currently no easy > to use and secure IM client on the market. That is a very different statement from "ZOMG U WILL BE SO POPULAR!!". > History (last 2-3 years, and recent PRISM leaks) have shown that > governments (and I'm not just talking about the US here) are intercepting > SSL traffic on a massive scale (see the DigiNotar-Iran incident, The > Blackberry-Etisalar incident, the PRISM case, ...etc etc etc). > > This has been made possible because of lax security implementation - not > just in pidgin but across the board. You don't have to convince me that governments suck and cannot be trusted. Ethan _______________________________________________ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support