Opened 7 years ago

Closed 7 years ago

#10882 closed enhancement (fixed)

New server-side Globe should attempt to run full fingerprints through SHA-1 on client side if possible

Reported by: karsten Owned by: rndm
Priority: Medium Milestone:
Component: Metrics/Globe Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

  • If JavaScript is available, the browser-part of Globe computes the SHA-1 of any 40 hex chars given as input and sends that to the Globe server. It uses a different parameter than the non-JavaScript version of Globe though, say, "search2=<str>", so that Globe server can distinguish.
  • If JavaScript is not available, Globe browser simply sends the search paramter as "search=<str>" to the Globe server.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by karsten

The Globe server, if asked for "search2=<str>", simply forwards the request to the Onionoo server. Nothing to worry about here, Onionoo will handle the case of <hash> being a SHA-1 fingerprint (if the user put in their original fingerprint) or the SHA-1 of the SHA-1 fingerprint (if the user put in a fingerprint hash).

If the Globe server is asked for "search=<str>", it performs the same check as the JavaScript Globe would have done. If it detects 40 hex chars, it computes the SHA-1 and sends it to Onionooo. Otherwise it simply forwards to Onionoo. When Onionoo replies, Globe server checks if the response contains a single bridge with the hashed fingerprint being the SHA-1 that Globe server computed. In this case the <str> part that it was given was a non-hashed fingerprint. If so, Globe server includes a warning that users shouldn't put in their original fingerprint and suggests to use the fingerprint hash instead in the future.

comment:2 Changed 7 years ago by karsten

In fact, the JavaScript version of Globe browser could perform the same check as Globe server when receiving a response. It could teach users not to put in their original fingerprint, because who knows, maybe next time they're searching using a non-JavaScript browser. Also, they might wonder why the displayed fingerprint is different from what they typed in.

comment:3 in reply to:  2 ; Changed 7 years ago by rndm

Replying to karsten:

In fact, the JavaScript version of Globe browser could perform the same check as Globe server when receiving a response. It could teach users not to put in their original fingerprint, because who knows, maybe next time they're searching using a non-JavaScript browser. Also, they might wonder why the displayed fingerprint is different from what they typed in.

The current implementation does the fingerprint check + hash and replaces the search input value and form action path (to redirect the form data to the search2 route). After that it triggers the form submit and the browser requests a result using the updated data.

The problem is that I can't store the old "unhashed" fingerprint over a page load.
I could solve this by moving rendering of search results to the client (if JS is enabled).

Another way would be to tell the server to display a note that it used a hashed fingerprint and link to the "how do I search for my bridge" page. This note appears every time someone uses a 40char hex query.

What do you think would be the better way? If you got any suggestions on how to solve this differently please tell me.

comment:4 in reply to:  3 Changed 7 years ago by karsten

Replying to rndm:

The current implementation does the fingerprint check + hash and replaces the search input value and form action path (to redirect the form data to the search2 route). After that it triggers the form submit and the browser requests a result using the updated data.

The problem is that I can't store the old "unhashed" fingerprint over a page load.

Hmm, not sure if this suggestion solves anything, but could the JavaScript inside the client's browser check and hash what's in the search input field, write the hashed version to a hidden search2 input field, clear the search input field, make the request, and write the original search back to the search input field?

I could solve this by moving rendering of search results to the client (if JS is enabled).

That sounds like duplicating a lot of work. Let's see if we can solve this with less code.

Another way would be to tell the server to display a note that it used a hashed fingerprint and link to the "how do I search for my bridge" page. This note appears every time someone uses a 40char hex query.

The "how do I search for my bridge" link should ideally be displayed in any case. People should read it before typing in anything into the search bar. Yes, maybe that's an idealistic thought.

The note that somebody shouldn't have put in their original fingerprint should only be displayed if they did just that. For browsers without JavaScript, the server can check whether a fingerprint hashed by itself matches a hashed fingerprint in Onionoo's response, and then display the warning. Browsers with JavaScript can do this check themselves and without storing the original fingerprint anywhere.

What do you think would be the better way? If you got any suggestions on how to solve this differently please tell me.

I don't know! It's quite possible that my plan doesn't make sense, or that I didn't describe it well. If the above doesn't make sense, let's talk on #tor-dev tonight or tomorrow and make a better plan.

comment:5 Changed 7 years ago by rndm

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.