Bug #15387

The Mozilla auto_config database requires an unusable CAPTCHA for Torified requests

Added by anonym 2018-03-07 15:01:39 . Updated 2019-02-13 15:06:17 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-03-07
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

I’ve noticed that the Mozilla configuration database (https://live.mozillamessaging.com/autoconfig/v1.1/) often presents a CAPTCHA when the request originates from Tor so the fetchFromISO method fails. We should ask if Mozilla can be more Tor-friendly.

That CAPTCHA is not displayed in the GUI so the user cannot do anything about it.

Subtasks

Related issues

Related to Tails - Bug #15788: Rethink our patches with Thunderbird 60 Resolved 2018-08-14
Related to Tails - Feature #6156: Upstream secure Thunderbird autoconfig wizard In Progress 2016-05-19

History

#1 Updated by anonym 2018-03-07 15:02:19

  • Description updated

#2 Updated by anonym 2018-03-07 15:48:05

  • Subject changed from The Mozilla auto_config database blocks Tor to The Mozilla auto_config database presents CAPTCHA for Torified requests

#3 Updated by anonym 2018-03-13 21:25:04

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 40

Good news! I managed to solve it by making said HTTP fetch respect general.useragent.override. Presumably this is just Cloudflare’s (which is the cause of this CAPTCHA (surprise!)) usual scrutiny of everything originating from the Tor network.

What remains is to make TorBirdy set the pref accordingly (currently it sets it to the empty string, which actually is part of causing this problem).

#4 Updated by intrigeri 2018-03-28 09:37:11

  • Subject changed from The Mozilla auto_config database presents CAPTCHA for Torified requests to The Mozilla auto_config database requires an unusable CAPTCHA for Torified requests
  • Description updated

#5 Updated by anonym 2018-03-28 09:37:41

  • Type of work changed from Communicate to Code

#6 Updated by intrigeri 2018-03-28 13:07:13

  • Target version deleted (Tails_3.7)

Feel free to de-assign yourself (and ideally: improve the description + flag as Easy, but don’t block on this) if you want.

#7 Updated by intrigeri 2018-03-28 13:07:38

(According to Help Desk, users don’t suffer from this enough to complain about it.)

#8 Updated by Anonymous 2018-08-16 11:26:10

  • related to Bug #11619: Torbirdy patches need updating added

#9 Updated by Anonymous 2018-08-16 11:26:17

  • related to deleted (Bug #11619: Torbirdy patches need updating)

#10 Updated by Anonymous 2018-08-16 11:26:30

  • related to Bug #15788: Rethink our patches with Thunderbird 60 added

#11 Updated by Anonymous 2018-08-17 06:29:07

  • related to Feature #6156: Upstream secure Thunderbird autoconfig wizard added

#12 Updated by anonym 2019-02-13 15:06:17

  • Status changed from In Progress to Rejected
  • Assignee deleted (anonym)
  • % Done changed from 40 to 0

anonym wrote:
> Good news! I managed to solve it by making said HTTP fetch respect general.useragent.override.

Turns out I was wrong; “said HTTP fetch” already respected that pref (my fix would only insist on it an extra time :)). This casts doubt over all my conclusions for this issue, which I think was temporary for whatever reason. I cannot reproduce, no matter the useragent string or whatever. Rejecting.