Feature #16528

Allow Pidgin to use SRV records

Added by hefee 2019-03-05 16:48:52 . Updated 2019-03-13 11:55:53 .

Status:
Confirmed
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2019-03-05
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Instant Messaging
Deliverable for:

Description

A lot of jabber servers use SRV DNS records to provide the correct server of the jabber server from a jabber UID. The current Proxy setting within Tails SOCKS5 make it impossible to resolve those SRV records, because the Tails network does not resolve those requests.
At my work fixing Feature #16348, it looks like I found a working solution:
Use SOCKS4 without “Remote-DNS over SOCKS4”.

Subtasks

History

#1 Updated by hefee 2019-03-05 16:50:45

  • Assignee changed from hefee to anonym

Please prioritize and select the target version for this feature. As I don’t know how import such a feature would be.

#2 Updated by hefee 2019-03-05 16:51:10

#3 Updated by intrigeri 2019-03-06 08:08:37

  • Subject changed from Allow jabber clients to use SRV records to Allow Pidgin to use SRV records
  • Status changed from New to Confirmed
  • Assignee changed from anonym to hefee
  • QA Check set to Info Needed
  • Affected tool set to Instant Messaging

I think I might be misunderstanding something: I would expect (as anonym on Feature #16348#note-30) that enabling remote DNS resolution solves this problem, while disabling it creates this problem, because our local system resolver (tor) does not support SRV records. But the description and your testing reports on Feature #16348 say exactly the opposite. Can you please check which one is actually the case, without spending time on researching the problem further?

#4 Updated by intrigeri 2019-03-06 08:25:14

> Please prioritize and select the target version for this feature. As I don’t know how import such a feature would be.

FYI anonym is not in charge of this sort of analysis, because having all the info & big picture in mind to do it is explicitly part of the kind of work he’d better+rather not do these days.

Benefit of fixing this problem: just like what we have for email with the Thunderbird new account setup wizard, one would only have to tell their XMPP address in order to configure their XMPP account, as opposed to needing to know/find/guess low-level and non-obvious technical details. Now, I would expect that most XMPP users on Tails have their XMPP account config persistent, so it’s a one-time benefit; and contrary to email, there’s only one low-level setting that needs guessing. Finally, XMPP is not exactly super popular these days — except in a small number of countries such as Germany, I’m told — and I don’t expect many Tails users to use it (see e.g. the very low number of folks in the “tails” MUC); so for example, instead of polishing the XMPP UX, spending time on supporting the protocols most people use nowadays on mobile devices would bring waaaay bigger benefits.

Cost of fixing this problem:

  • for brand new persistent Pidgin config: I expect it’s a one or two lines change, super cheap
  • for pre-existing persistent Pidgin config: assuming the user managed to make it work by entering the correct “Connect server”, we can probably leave them as-is, which is good because programmatically modifying ~/.purple/*.xml is not my idea of fun. One will need to actually test that whatever change we do here won’t break these accounts, but I’m confident it won’t. Now, these users won’t benefit from the improvement next time they set up another XMPP account but I say whatever, the cost of fixing that use case greatly outweigh the benefits.

My conclusion: I think it’s worth giving the cheapest possible solution a try while we have the problem space in mind, checking that it passes the test suite, and finally testing that it does not break existing accounts. But if this ever becomes more complicated than planned and a can of worms opens, most likely it’ll be time to give up (and avoid the sunken costs fallacy). And if this can’t be done soonish, forget it for now: we have plenty of other UX improvements on our plate, many of them with a much lower cost/benefit.

#5 Updated by intrigeri 2019-03-08 14:56:02

  • Assignee deleted (hefee)
  • QA Check deleted (Info Needed)

#6 Updated by hefee 2019-03-13 11:25:35

  • Description updated

intrigeri wrote:
> Benefit of fixing this problem: just like what we have for email with the Thunderbird new account setup wizard, one would only have to tell their XMPP address in order to configure their XMPP account, as opposed to needing to know/find/guess low-level and non-obvious technical details. Now, I would expect that most XMPP users on Tails have their XMPP account config persistent, so it’s a one-time benefit; and contrary to email, there’s only one low-level setting that needs guessing. Finally, XMPP is not exactly super popular these days — except in a small number of countries such as Germany, I’m told — and I don’t expect many Tails users to use it (see e.g. the very low number of folks in the “tails” MUC); so for example, instead of polishing the XMPP UX, spending time on supporting the protocols most people use nowadays on mobile devices would bring waaaay bigger benefits.

Keep in mind it is a DNS record, so it may change over time, if the server provider move their Jabber server. So it is not the one time I need the data scenario like in Thunderbird.

That is all strange. I now checked it again with the new build. And I got the expected result, that no setting is able to resolve the SRV entries, as everything is torified in Tails.

> Cost of fixing this problem:
>
> * for brand new persistent Pidgin config: I expect it’s a one or two lines change, super cheap

well but if we should have different settings for new users than for persistent, we would need to make sure, that we handle both cases in future.

#7 Updated by intrigeri 2019-03-13 11:55:53

  • Priority changed from Normal to Low

> Keep in mind it is a DNS record, so it may change over time, if the server provider move their Jabber server. So it is not the one time I need the data scenario like in Thunderbird.

Right, I had missed this! It’s indeed much less likely that an email provider changes the hostname of their POP/IMAP/SMTP servers, precisely because there’s no mechanism like XMPP has to do so without requiring users updating their config.

> That is all strange. I now checked it again with the new build. And I got the expected result, that no setting is able to resolve the SRV entries, as everything is torified in Tails.

I understand that we have no cheap solution on the table anymore to the problem this ticket is about, so this ticket is now mostly equivalent to “support SRV DNS queries”. Solving that broader problem is seriously more involved and I think we have plenty of cheaper ways to improve UX much more ⇒ lowering priority (after hesitating to reject). Let’s hope the root cause of the problem is resolved in Tor itself some day.

#8 Updated by intrigeri 2019-03-14 13:59:13