[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32256 [Applications/Tor Browser]: TorBrowser should advertise Onion Networking capability in the User-Agent: string
#32256: TorBrowser should advertise Onion Networking capability in the User-Agent:
string
--------------------------------------+--------------------------
Reporter: alecmuffett | Owner: tbb-team
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------+--------------------------
Comment (by gk):
Replying to [comment:14 alecmuffett]:
> Aside: I think you answered your own question when you said:
>
> >the user agent could sent this header with the first request
>
> ...because that word "first" means state-maintenance;
I am not sure whether "state-maintenance" is the proper term here given
that it is coming with some connotations that are probably not applying
here. The *browser* knows whether a request is a first request when
surfing to foo.com (or if that's too hand-wavy for you then it should not
be hard to get the browser into a state to make it known). And "first"
does not necessarily mean "first" in the whole browsing session but rather
something like "the first request to foo.com after entering 'foo.com' into
the URL bar and hitting RETURN". That means if you revisit foo.com later
on the first request to it will contain the onion capability bits again.
The server knows whether it's a first request or not by seeing the onion
capability bit or not (because the server admin *knows* that Tor Browser
is sending that bit on a first request or if a user has not denied to
visit that site over .onion (see below)) and can act accordingly, e.g. by
adding Alt-Svc headers or a Location header pointing to the .onion or by
adding an Onion-Location header etc.
> as with the "link onion-enabling stuff with the first dropping of a
session cookie" model, there are > three issues:
>
> - not all sites want to use cookies / track their users; what then, re:
state-tracking?
There is no need for that as I said above. If you for some reason really
have the need to track the user on a site as to whether they are in a
.onion context you should be easily able to use the Referer header. But
that should *not* be necessary.
> - by linking the onion-enablement to "first drop", there is no
opportunity to revisit or "nudge" the user towards onion
Sure there is, see above: anytime the user visits foo.com there is a
chance to revisit the decision as the onion capability bit is sent again
in the first request.
> and thirdly
>
> - by eliding the six bytes of {{{Tor/1}}} from the header, you make it
somewhat harder for people to implement stuff like:
>
> '''You are not Onion-Capable! We recommend that you run TorBrowser for
access to this site! '''
>
> ...which is potentially desirable for brand awareness :-)
That actually depends. Because if the server sent back an Onion-Location
header and the user declined to visit the onion and does not want so in
the future (for whatever reason) I expect the server to comply with that
wish and not throw a "You are not Onion-Capable" in the user's face every
time they visit that website. So, this use-case works perfectly well with
the idea of not sending the onion capability bit in every request with the
user agent: one could easily omit that bit entirely if the user made the
decision to not wanting to load that website (or any website, that is)
over .onion.
So, I think using the onion capability bit for *that* idea is not
necessarily a thing we should encourage.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32256#comment:16>
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