Send tor-dev mailing list submissions to
tor-dev@xxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
or, via email, send a message with subject or body 'help' to
tor-dev-request@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
tor-dev-owner@xxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."
Today's Topics:
1. Re: Tor exit bridges (nusenu)
2. Re: [RFC] control-spec: Specify add/remove/view client auth
commands (client-side). (grarpamp)
3. Controller: text connection vs SNMP (grarpamp)
4. Re: Tor exit bridges (Matthew Finkel)
5. Solving World's Tor Users Being Blocked by Websites (was: Tor
exit bridges) (grarpamp)
----------------------------------------------------------------------
Message: 1
Date: Tue, 07 May 2019 18:00:00 +0000
From: nusenu <nusenu-lists@xxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Tor exit bridges
Message-ID: <22e90ef1-483b-e013-e7e3-72197c94d4bb@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
juanjo:Tor relays are public and easily blocked by IP. To connect to Tor
network users where Tor is censored have to use bridges and even PTs.
But, what happens on the exit? Many websites block Tor IPs so using
it to access "clearweb" is not possible. Should we allow and start
using "exit bridges"? In I2P we have not this problem since there is
no central IP list of relays.--
there is no need to extend to one more hope to achieve this
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html
https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190507/b69c09b1/attachment-0001.sig>
------------------------------
Message: 2
Date: Tue, 7 May 2019 18:15:09 -0400
From: grarpamp <grarpamp@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] [RFC] control-spec: Specify add/remove/view
client auth commands (client-side).
Message-ID:
<CAD2Ti2-+Ne6O5OTtmKqnuP_W8-WheTrmDbzuiTh7610QsV1ijA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
On 5/7/19, Suphanat Chunhapanya <haxx.pop@xxxxxxxxx> wrote:That's cool. But according to what dgoulet proposed, if we use both
ONION_CLIENT_AUTH_ADD
and ONION_SERVICE_AUTH_ADD. The latter will sound like it's an
authentication of the service not the client. At least for me :)
And or maybe that seem more like managing the
onion service ID itself too, rather than just authentication
for fetching or connecting to it.
Part of problem may be brain grouping of the underscores.
"onion" "client|service" "auth" "add|del|view"
"onion" "client|service auth" "add|del|view"
"onion client|service" "auth" "add|del|view"If you want the least specific left and the most specific right, I think
ONION_AUTH_CLIENT_ADD and
ONION_AUTH_SERVICE_ADD would be better.
Maybe your sense would be better...
"onion auth" for "client|service" do "add|del|view"
or if there's want to keep "onion" string as the MIB root...
"onion" re "auth" for "client|service" do "add|del|view"
Though seems mostly agreed on onion first and verb last,
so whatever works for people in the middle :)
------------------------------
Message: 3
Date: Tue, 7 May 2019 18:27:51 -0400
From: grarpamp <grarpamp@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: [tor-dev] Controller: text connection vs SNMP
Message-ID:
<CAD2Ti29cFwuRoUXjxaeNRB=vV3706+RQJVfeMVMsvrt_781dnw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Speaking of MIBs and management, was SNMP ever seriously
looked at back when desire for a control mechanism evolved?
If I recall, agent libs and clients weren't wished as middleware,
thus demurring to a text connection shell interface.
Though commercial routers have both, the shell connection is
usually richer and more capable, but harder to parse
(Juniper being more programmatic), and requires downstream
development to speak to each vendor's shell in automated fashion.
------------------------------
Message: 4
Date: Tue, 7 May 2019 22:27:35 +0000
From: Matthew Finkel <matthew.finkel@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Tor exit bridges
Message-ID:
<CAGF8hst+OGEzqYdaR=LxX7S1vTbeg7U+ipxZtd08XnAAgSJSmQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Tue, May 7, 2019 at 5:35 PM juanjo <juanjo@xxxxxxxxx> wrote:Tor relays are public and easily blocked by IP. To connect to Tor
network users where Tor is censored have to use bridges and even PTs.
But, what happens on the exit? Many websites block Tor IPs so using it
to access "clearweb" is not possible. Should we allow and start using
"exit bridges"? In I2P we have not this problem since there is no
central IP list of relays.
There is an old FAQ entry on this[0].
[0] https://2019.www.torproject.org/docs/faq.html.en#HideExits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190507/61f91b9a/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 7 May 2019 20:14:43 -0400
From: grarpamp <grarpamp@xxxxxxxxx>
To: tor-talk@xxxxxxxxxxxxxxxxxxxx, tor-access@xxxxxxxxxxxxxxxxxxxx
Cc: tor-relays@xxxxxxxxxxxxxxxxxxxx, tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: [tor-dev] Solving World's Tor Users Being Blocked by Websites
(was: Tor exit bridges)
Message-ID:
<CAD2Ti29EHrgAsxkrVJfMc-mcG4qPJN=eShOGRwJJgrhUeAV9MQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
On 5/7/19, nusenu <nusenu-lists@xxxxxxxxxx> wrote:
juanjo:Tor relays are public and easily blocked by IP. To connect to Tor
network users where Tor is censored have to use bridges and even PTs.
But, what happens on the exit? Many websites block Tor IPs so using
it to access "clearweb" is not possible. Should we allow and start
using "exit bridges"? In I2P we have not this problem since there is
no central IP list of relays.
there is no need to extend to one more hope to achieve this
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html
https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html
It's possible to augment such outbound
solution offerings even further by running
an OpenVPN termination service so users
can transport UDP between clearnet as well.
VPNGate.net project has an idea there too.
Even large regional IPv6 pools could be bought
and shared by operators and rotated through.
More tor relay operators should consider
some of the above options, whether as a
requested "bridge" service mechanism, or
listed in the consensus "contact" field, or
as more of a standalone VPNGate support,
or "ExitGate" project sort of arrangement.
Using only tor right now, a user needs to use a clearnet service
that does not scrape consensus, or one not fronted by services
doing similar to CloudFlare's spiteful default tor blocking policy,
or find a lucky exit within whatever geolocation game the clearnet
service uses, or get lucky through traditional vpn or proxy.
But those are only fun statistical hacks, not real long term solutions
to the underlying problem.
It's unfortunate that such braindead blocking, stupid policy regimes,
sites refusal to developing creative solutions [1] for so many world's
users legitimate privacy, info risk, anonymity needs... often results
in users accounts being locked out and escalated into forcing disclosure
of users private info and ID to sites to unlock them, thus exposing
users to ongoing long term fraud, cost, and stress when that info
(in most cases truly unnecessary to collect) is eventually shared
misused and stolen by both sites and criminals... or outright auto
deletion of user's valued account, built up social networks, etc...
all for doing nothing wrong, and harming no one or thing.
Death by DriveByExit :(
And really shameful to deny world's users the right to simply read
a website, be it social, commercial, information, etc or even sadly
their own tax-theft funded governmental public sites doing this
blocking too.
There are some related projects, best practice, as well...
https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor
https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access
Positive outreach and direct engagement by Tor community
is key here, and perhaps not enough of that is happening,
at least not publicly. It's a big enough issue that it really needs
a dedicated, active, allied, and even funded subproject...
a MegaProject that needs to happen.
[1] Such as forfeitable cryptocurrency and mailed-in cash
deposits refundable in time, increasing account priviledges
and features based on account age and activity, community
moderation and behaviour support within the sites, opensource
third party tracking-free local SecurImage style captcha throughout
a sites features, privacy preserving non-SMS non-Google/Apple
pure TOTP authenticator protocols, PGP recovery, letting
users simply *read* websites without any hindrance,
while utilizing these methods only for *write* operations,
etc and so many more ways you can envision...
Cc'd for awareness and inclusion. *Please remove tor-dev
and tor-relays, and move this to tor-talk or tor-access
for ongoing discussion and progress. Thanks.
------------------------------
Subject: Digest Footer
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
------------------------------
End of tor-dev Digest, Vol 100, Issue 8
***************************************
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev