How about, instead, focus that energy into addressing the countless websites that are broken because of https everywhere? I've submitted my list of broken sites numerous times. On Nov 3, 2014 11:54 AM, <[email protected]> wrote:
> Send HTTPS-Everywhere mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.eff.org/mailman/listinfo/https-everywhere > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of HTTPS-Everywhere digest..." > > > Today's Topics: > > 1. "darkweb everywhere" extension (yan) > 2. Re: "darkweb everywhere" extension (yan) > 3. Re: "darkweb everywhere" extension (Maxim Nazarenko) > 4. Re: "darkweb everywhere" extension (Alex Xu) > 5. Re: "darkweb everywhere" extension (Nick Semenkovich) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 03 Nov 2014 05:09:15 +0000 > From: yan <[email protected]> > To: https-everywhere <[email protected]> > Subject: [HTTPS-Everywhere] "darkweb everywhere" extension > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > Hi all, > > Some people have requested for the "Darkweb Everywhere" extension [1] to > be integrated into HTTPS Everywhere. This is an extension for Tor > Browser that redirects users to the Tor Hidden Service version of a > website when possible. > > I'm supportive of the idea; however, I'm worried that since .onion > domain names are usually unrelated to a site's regular domain name, a > malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > defends against this by publishing a doc in their Github repo that cites > evidence for each ruleset [2]. > > What if, instead, we asked website owners to send an HTTP header that > indicates the Tor Hidden Service version of their website? Then HTTPS > Everywhere could cache the result (like HSTS) and redirect to the THS > version automatically in the future if the user opts-in. > > If this is something that EFF/Tor would be willing to advocate for, I > would be happy to draft a specification for the header syntax and > intended UA behavior. > > Thanks, > Yan > > > [1] https://github.com/chris-barry/darkweb-everywhere/ > [2] > > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > > > ------------------------------ > > Message: 2 > Date: Mon, 03 Nov 2014 05:48:03 +0000 > From: yan <[email protected]> > To: https-everywhere <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [HTTPS-Everywhere] "darkweb everywhere" extension > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > +tor-dev. tl;dr: Would be nice if there were an HTTP response header > that allows HTTPS servers to indicate their .onion domain names so that > HTTPS Everywhere can automatically redirect to the .onion version in the > future if the user chooses a "use THS when available" preference. > > I imagine the header semantics and processing would be similar to HSTS. > It would only be noted when sent over TLS and have the max-age and > include-subdomains fields. > > -yan > > yan wrote: > > Hi all, > > > > Some people have requested for the "Darkweb Everywhere" extension [1] to > > be integrated into HTTPS Everywhere. This is an extension for Tor > > Browser that redirects users to the Tor Hidden Service version of a > > website when possible. > > > > I'm supportive of the idea; however, I'm worried that since .onion > > domain names are usually unrelated to a site's regular domain name, a > > malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > > defends against this by publishing a doc in their Github repo that cites > > evidence for each ruleset [2]. > > > > What if, instead, we asked website owners to send an HTTP header that > > indicates the Tor Hidden Service version of their website? Then HTTPS > > Everywhere could cache the result (like HSTS) and redirect to the THS > > version automatically in the future if the user opts-in. > > > > If this is something that EFF/Tor would be willing to advocate for, I > > would be happy to draft a specification for the header syntax and > > intended UA behavior. > > > > Thanks, > > Yan > > > > > > [1] https://github.com/chris-barry/darkweb-everywhere/ > > [2] > > > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > > _______________________________________________ > > HTTPS-Everywhere mailing list > > [email protected] > > https://lists.eff.org/mailman/listinfo/https-everywhere > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 3 Nov 2014 15:14:07 +0300 > From: Maxim Nazarenko <[email protected]> > To: [email protected] > Cc: https-everywhere <[email protected]> > Subject: Re: [HTTPS-Everywhere] "darkweb everywhere" extension > Message-ID: > <CAKGkX-3Hn7ru= > [email protected]> > Content-Type: text/plain; charset=UTF-8 > > Sounds like a great idea. Even Facebook runs its hidden service nowadays... > > My two cents: > 1) The specification should be extensible, so other networks (such as > I2P) would be covered. > 2) Well-known locations might also be used (not sure if this is a good > idea). > 3) From an extension user viewpoint, preload list would be very nice. > > Best regards, > Maxim Nazarenko > > On 3 November 2014 08:09, yan <[email protected]> wrote: > > Hi all, > > > > Some people have requested for the "Darkweb Everywhere" extension [1] to > > be integrated into HTTPS Everywhere. This is an extension for Tor > > Browser that redirects users to the Tor Hidden Service version of a > > website when possible. > > > > I'm supportive of the idea; however, I'm worried that since .onion > > domain names are usually unrelated to a site's regular domain name, a > > malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > > defends against this by publishing a doc in their Github repo that cites > > evidence for each ruleset [2]. > > > > What if, instead, we asked website owners to send an HTTP header that > > indicates the Tor Hidden Service version of their website? Then HTTPS > > Everywhere could cache the result (like HSTS) and redirect to the THS > > version automatically in the future if the user opts-in. > > > > If this is something that EFF/Tor would be willing to advocate for, I > > would be happy to draft a specification for the header syntax and > > intended UA behavior. > > > > Thanks, > > Yan > > > > > > [1] https://github.com/chris-barry/darkweb-everywhere/ > > [2] > > > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > > _______________________________________________ > > HTTPS-Everywhere mailing list > > [email protected] > > https://lists.eff.org/mailman/listinfo/https-everywhere > > > ------------------------------ > > Message: 4 > Date: Mon, 03 Nov 2014 08:08:23 -0500 > From: Alex Xu <[email protected]> > To: [email protected], [email protected], > [email protected] > Subject: Re: [HTTPS-Everywhere] "darkweb everywhere" extension > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On 03/11/14 12:48 AM, yan wrote: > > +tor-dev. tl;dr: Would be nice if there were an HTTP response header > > that allows HTTPS servers to indicate their .onion domain names so that > > HTTPS Everywhere can automatically redirect to the .onion version in the > > future if the user chooses a "use THS when available" preference. > > > > I imagine the header semantics and processing would be similar to HSTS. > > It would only be noted when sent over TLS and have the max-age and > > include-subdomains fields. > > > > -yan > > > > yan wrote: > >> Hi all, > >> > >> Some people have requested for the "Darkweb Everywhere" extension [1] to > >> be integrated into HTTPS Everywhere. This is an extension for Tor > >> Browser that redirects users to the Tor Hidden Service version of a > >> website when possible. > >> > >> I'm supportive of the idea; however, I'm worried that since .onion > >> domain names are usually unrelated to a site's regular domain name, a > >> malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > >> defends against this by publishing a doc in their Github repo that cites > >> evidence for each ruleset [2]. > >> > >> What if, instead, we asked website owners to send an HTTP header that > >> indicates the Tor Hidden Service version of their website? Then HTTPS > >> Everywhere could cache the result (like HSTS) and redirect to the THS > >> version automatically in the future if the user opts-in. > >> > >> If this is something that EFF/Tor would be willing to advocate for, I > >> would be happy to draft a specification for the header syntax and > >> intended UA behavior. > >> > >> Thanks, > >> Yan > >> > >> > >> [1] https://github.com/chris-barry/darkweb-everywhere/ > >> [2] > >> > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > >> _______________________________________________ > >> HTTPS-Everywhere mailing list > >> [email protected] > >> https://lists.eff.org/mailman/listinfo/https-everywhere > >> > > > > _______________________________________________ > > HTTPS-Everywhere mailing list > > [email protected] > > https://lists.eff.org/mailman/listinfo/https-everywhere > > > > https://lists.torproject.org/pipermail/tor-talk/2014-May/032906.html > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 819 bytes > Desc: OpenPGP digital signature > URL: < > https://lists.eff.org/pipermail/https-everywhere/attachments/20141103/7ea26cfe/attachment-0001.sig > > > > ------------------------------ > > Message: 5 > Date: Mon, 3 Nov 2014 10:53:58 -0600 > From: Nick Semenkovich <[email protected]> > To: Alex Xu <[email protected]> > Cc: [email protected], https-everywhere > <[email protected]>, [email protected] > Subject: Re: [HTTPS-Everywhere] "darkweb everywhere" extension > Message-ID: > <CAJKgmrW5kuOxWLAe_3NVP3WCoy0pCdWu9E3Da6m=+ > [email protected]> > Content-Type: text/plain; charset="utf-8" > > This is a great idea! Any thoughts on extending parts of this to Chrome? > > I understand there are significant issues with Chrome & Tor, though I also > think making Tor more visible and accessible to end-users is a good goal. > > Some options: > - Flashing the HTTPSe icon when a .onion site is available (or showing > another symbol, etc.) > - Allow one-click to tor2web (this has some broader implications ... I > worry users would think they were somehow anonymous using tor2web) > > - Nick > > [1] > > https://blog.torproject.org/blog/google-chrome-incognito-mode-tor-and-fingerprinting > > On Mon, Nov 3, 2014 at 7:08 AM, Alex Xu <[email protected]> wrote: > > > On 03/11/14 12:48 AM, yan wrote: > > > +tor-dev. tl;dr: Would be nice if there were an HTTP response header > > > that allows HTTPS servers to indicate their .onion domain names so that > > > HTTPS Everywhere can automatically redirect to the .onion version in > the > > > future if the user chooses a "use THS when available" preference. > > > > > > I imagine the header semantics and processing would be similar to HSTS. > > > It would only be noted when sent over TLS and have the max-age and > > > include-subdomains fields. > > > > > > -yan > > > > > > yan wrote: > > >> Hi all, > > >> > > >> Some people have requested for the "Darkweb Everywhere" extension [1] > to > > >> be integrated into HTTPS Everywhere. This is an extension for Tor > > >> Browser that redirects users to the Tor Hidden Service version of a > > >> website when possible. > > >> > > >> I'm supportive of the idea; however, I'm worried that since .onion > > >> domain names are usually unrelated to a site's regular domain name, a > > >> malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere > only > > >> defends against this by publishing a doc in their Github repo that > cites > > >> evidence for each ruleset [2]. > > >> > > >> What if, instead, we asked website owners to send an HTTP header that > > >> indicates the Tor Hidden Service version of their website? Then HTTPS > > >> Everywhere could cache the result (like HSTS) and redirect to the THS > > >> version automatically in the future if the user opts-in. > > >> > > >> If this is something that EFF/Tor would be willing to advocate for, I > > >> would be happy to draft a specification for the header syntax and > > >> intended UA behavior. > > >> > > >> Thanks, > > >> Yan > > >> > > >> > > >> [1] https://github.com/chris-barry/darkweb-everywhere/ > > >> [2] > > >> > > > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > > >> _______________________________________________ > > >> HTTPS-Everywhere mailing list > > >> [email protected] > > >> https://lists.eff.org/mailman/listinfo/https-everywhere > > >> > > > > > > _______________________________________________ > > > HTTPS-Everywhere mailing list > > > [email protected] > > > https://lists.eff.org/mailman/listinfo/https-everywhere > > > > > > > https://lists.torproject.org/pipermail/tor-talk/2014-May/032906.html > > > > > > _______________________________________________ > > HTTPS-Everywhere mailing list > > [email protected] > > https://lists.eff.org/mailman/listinfo/https-everywhere > > > > > > -- > Nick Semenkovich > Laboratory of Dr. Jeffrey I. Gordon > Medical Scientist Training Program > School of Medicine > Washington University in St. Louis > https://nick.semenkovich.com/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.eff.org/pipermail/https-everywhere/attachments/20141103/96d2994b/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere > > ------------------------------ > > End of HTTPS-Everywhere Digest, Vol 53, Issue 1 > *********************************************** >
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
