User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130201185534 Steps to reproduce: 1. Start two instances of Thunderbird (I did it on separate computers) 2. Add the same XMPP account on both installations. 3. See the clients battle over which default XMPP resource "Thunderbird" should be the active one. Actual results: Thunderbird logs in to the XMPP server with identical resource names from two connections, which in XMPP means that the users wishes to replace the previous connection for that resource (in this case "Thunderbird"). Since both clients think they're the active one, an eternal battle of the resource ensues. Expected results: This is the proper behaviour whenever assigning a specific resource for one's client. However, the default behaviour should be to generate a random string to use as Resource (long enough to avoid collisions). * The resource field should be empty by default. * Whenever the resource field is empty, a new resource name should be generated (preferrably on client startup, NOT mere network reconnects, preferrably NOT only on software installation) * The resource field should be put under some sort of "Advanced" setting form. Resources are possibly a security risk (defaulting to "Thunderbird" can let people look for Thunderbird-specific vulnerabilities for example). A known resource ID for a specific client may also be a security risk if it never changes. Thus a resource should be [pseudo]randomly generated for every session (like when Thunderbird starts). The resource is there to reconnect conversations on temporary network failures. On bigger breaks, like turning the computer off or closing Thunderbird, the client may assume the user considers the current instant messaging conversations over.
OS: Linux → All
Hardware: x86_64 → All
Summary: Resource collision should be avoided with random resource names → XMPP resource collision should be avoided with random resource names
Component: Instant Messaging → XMPP
Product: Thunderbird → Chat Core
Version: 17 → trunk
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 955307
You need to log in before you can comment on or make changes to this bug.