Opened 3 years ago

Last modified 5 days ago

#19251 new enhancement

TorBrowser might want to have an error page specific to when .onion links fail

Reported by: cypherpunks Owned by: tbb-team
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team
Cc: asn Actual Points:
Parent ID: #30025 Points:
Reviewer: Sponsor: Sponsor27-must

Description

When a webpage fails to load, it can be due to any number of factors. But when that page is served by an onion service, some of those factors have greater implications for security.

It would be cool to know if the failure is related to a malfunction in the local Tor instance, or due to nonlocal failures. If TBB can determine this, adding something to TBB to create .onion specific error messages with greater detail would be helpful.

Child Tickets

TicketTypeStatusOwnerSummary
#30090tasknewantonelaMake a list of potential .onion errors

Attachments (2)

O2A4.jpg (158.4 KB) - added by antonela 7 days ago.
1-errorpage.jpg (271.3 KB) - added by antonela 7 days ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 19 months ago by antonela

Cc: antonela added

comment:2 Changed 10 months ago by antonela

Cc: antonela removed
Keywords: ux-team added

comment:3 Changed 7 months ago by pili

Sponsor: Sponsor27

comment:4 Changed 6 months ago by gk

Sponsor: Sponsor27Sponsor27-must

Add Sponsor27-must items for Objective 2

comment:5 Changed 6 months ago by pili

Parent ID: #30025

Changed 7 days ago by antonela

Attachment: O2A4.jpg added

Changed 7 days ago by antonela

Attachment: 1-errorpage.jpg added

comment:6 Changed 7 days ago by antonela

We want to improve the way we communicate with users that there is an error trying to visiting an onion service. We have a good opportunity for sharing educational points and for being more transparent with users, offering them information about the kind of error they are experiencing.

We can provide more informative error messages indicating better whether the issue was on the service-side, on the client-side, or the network-side. We can do it without being overwhelming or patronizing but clear about the information we are spreading.

As asn mentioned, errors could happen in different layers:

  • Client Errors
  • Network Errors
  • Service Errors

To illustrate this complexity, we can use a diagram of the connection and show where the error happened. I thought about isabela's idea in #23486 and I think we can have a kind of step-by-step graph here as well.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/O2A4.jpg

So I came up with this concept. This layout is flexible enough to cover all the error scenarios we currently have in #30090.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/1-errorpage.jpg

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?


TODO

  • UI: Make the UI for each error scenario.
  • Content: Define the content for each page. This information also needs to have an entry at support.tpo.org and tb-manual? Onion services documentation?. We will need to l10nize it.
  • User Testing: Once this reaches a nightly, I'd like to share with our testing pool of users for feedback.

comment:7 Changed 7 days ago by asn

Cc: asn added

comment:8 in reply to:  6 Changed 6 days ago by asn

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.

Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.

comment:9 Changed 5 days ago by clash

Something like the Cloudflare error pages might be a nice idea since they serve the same purposes.

https://community.cloudflare.com/t/connection-breakage-between-cloudflare-and-the-server/57148

It would be nice to be able to isolate where the error occurred both as a client and as a host.

Maybe a "flow" could be represented in those icons like Cloudflare does with the double sided arrows.

Note: See TracTickets for help on using tickets.