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