Re: [tor-bugs] #10882 [Globe]: New server-side Globe should attempt to run full fingerprints through SHA-1 on client side if possible

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10882: New server-side Globe should attempt to run full fingerprints through SHA-1
on client side if possible
-----------------------------+------------------
     Reporter:  karsten      |      Owner:  rndm
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Globe        |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+------------------

Comment (by karsten):

 Replying to [comment:3 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10882#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs