Opened 18 months ago

Last modified 11 hours ago

#23545 new defect

UX improvement: Tor Browser should handle bogus HSv3 addresses

Reported by: asn Owned by: tbb-team
Priority: Medium Milestone: Tor: unspecified
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tor-hs, prop224, ux-team, 034-triage-20180328, 034-removed-20180328
Cc: antonela, linda, gk, arthuredelstein, brade, mcs, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor27

Description

HS v3 addresses are big but also contain a checksum. This means that Tor Browser could catch mistyped addresses and warn the user.

With current master and current Tor browser, if you mistype an hsv3 address you go to the Unable to connect page:

Unable to connect

Firefox can’t establish a connection to the server at 4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqeflock.onion.

    The site could be temporarily unavailable or too busy. Try again in a few moments.
    If you are unable to load any pages, check your computer’s network connection.
    If your computer or network is protected by a firewall or proxy, make sure that Tor Browser is permitted to access the Web.

In the logs you can see a parsing error:

[warn] Invalid onion hostname [scrubbed]; rejecting

which is a bit generic.

I wonder what's the best way to offer better UX here. How should the user be warned?

Also how should we implement this? Should the Browser do the checksum check itself? Or should Tor do the checksum check and inform Tor Browser somehow?

How to do this best?

Child Tickets

Change History (13)

comment:1 Changed 18 months ago by cypherpunks

Keywords: ux-team added; ux removed

comment:2 Changed 18 months ago by cypherpunks

Keywords: tor-browser removed

Redundant: tbb-team is already the owner.

comment:3 Changed 18 months ago by gk

Cc: gk added; geko removed

I think tor doing the checksum check and informing the browser seems to be a good way as I can imagine other applications might want that feature as well. I can imagine that we patch the browser part showing some custom error page or amending the one currently shown.

Last edited 18 months ago by gk (previous) (diff)

comment:4 Changed 18 months ago by mcs

Cc: brade mcs added

comment:5 in reply to:  3 Changed 18 months ago by linda

Replying to gk:

I think tor doing the checksum check and informing the browser seems to be a good way as I can imagine other applications might want that feature as well. I can imagine that we patch the browser part showing some custom error page or amending the one currently shown.

+1, I think that showing a custom error page for .onion sites would be a good option.

comment:6 Changed 12 months ago by antonela

Cc: antonela added

comment:7 Changed 12 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

deferring to 0.3.4 on Tor's; this will need feature design. TB folks -- how should Tor tell you about this? With HTTP CONNECT tunneling it would be trivial, but for SOCKS we are pretty limited.

comment:8 in reply to:  7 Changed 12 months ago by gk

Replying to nickm:

deferring to 0.3.4 on Tor's; this will need feature design. TB folks -- how should Tor tell you about this? With HTTP CONNECT tunneling it would be trivial, but for SOCKS we are pretty limited.

What options could you think of (not sure what "limited" means here)?

comment:9 Changed 12 months ago by nickm

Keywords: 034-triage-20180328 added

comment:10 Changed 12 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:11 Changed 11 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:12 Changed 11 months ago by dmr

Cc: dmr added
Keywords: tor-hs added

comment:13 Changed 11 hours ago by pili

Sponsor: Sponsor27
Note: See TracTickets for help on using tickets.