[tor-dev] Request for feedback/victims: cfc
Hello, Inspired by https://trac.torproject.org/projects/tor/ticket/18361 I've been working on way to improve the situation. My "proof of concept" tech demo is what I consider good enough for use by brave people that aren't me, so I have put up an XPI package at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ The source: https://git.schwanenlied.me/yawning/cfc (Requires the Firefox SDK aka Jetpack to package). By default the addon will: * Rewrite the CloudFlare captcha error page with messages that reflect my perception of reality[0]. * Rewrite imgur ".gifv" links to ".gif". Under "Tools->Addons->Extensions" you can configure the addon to: * Automatically fetch a cached copy of pages hosted on CloudFlare infrastructure from archive.is. * Automatically fetch a cached copy of pages that present a CloudFlare captcha from archive.is. * Pop up a UI widget asking if you want to fetch a cached copy of the page from archive.is each time you encounter a captcha. * Disable the snarky error message replacement (Requires a restart to take effect, because I'm lazy). * Disable the gifv URL rewrite. TODO: * Support a user definable blacklist (eg: If you want to always use archive.is to access gawker.com or other clickbait bullshit, you should be able to easily do so). * Add more general quality of life things. * Think about making it work on Fenec (It currently will not because PopUpNotifications are handled differently, among other things). * Rewrite the internals to prepare for e10s. WARNING: * If archive.is is evil, they can track you across page fetches trivially, because this sort of use case is outside of Tor Browser's current threat model (Yes, CloudFlare/Google can also do the same thing currently, who do you trust more?). * PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL SHOULD NOT USE THIS. If you don't know how to install addons given as XPI files, you shouldn't be using this. This is only tested on 6.0a4 (Linux/64 bit). It *should* work on everything that isn't Orfox that's relatively modern, YMMV. Regards, -- Yawning Angel [0]: A very cynical/adversarial take on things. Opinions are my own, etc, and I don't care if you're offended. pgpS7slMkLTl3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
[I hate replying to myself.] On Wed, 23 Mar 2016 09:15:36 + Yawning Angel wrote: > My "proof of concept" tech demo is what I consider good enough for > use by brave people that aren't me, so I have put up an XPI package > at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ I noticed some dumb bugs and UI issues in the version I pushed so I changed a lot of things and uploaded a new version that should be better behaved. In particular: * It is now Content Script based, and does IPC so it may survive the transition to sandboxed/multiprocess firefox better. * It will always inject a button into the DOM instead of trying to display browser UI stuff (content scripts are supposed to have isolation...). * The UI selection pref is removed. * The ask on captcha option for behavior is removed, since a button always will be there to bypass it. * Loading lots of pages that end up displaying street signs *should* now behave correctly. The old release is under `./old` for posterity. Sorry for the inconvenience, -- Yawning Angel pgpUUD0w2JeqL.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
During the OONI survey to find instances of server-side Tor blocking, we found a few variations on CloudFlare captcha pages. They don't all say "Attention Required!". Apparently there is an option to customize the page, but few sites make use of it. Here are the regexes we used (excerpted from https://www.bamsoftware.com/git/ooni-tor-blocks.git): if status == 403: if server == "cloudflare-nginx" and re.search("Attention Required! \\| CloudFlare|One more step to access", body): return True, "403-CLOUDFLARE" if server == "cloudflare-nginx" and re.search("|", body): # A customized captcha page. return True, "403-CLOUDFLARE" if server == "cloudflare-nginx" and re.search("Access denied \\| [^ ]* used CloudFlare to restrict access", body): # With this one you don't get a captcha. May be controlled by the # site operator. return True, "403-CLOUDFLARE" if status == 503: if re.search("", body): return True, "503-CLOUDFLARE" I now think the 'server == "cloudflare-nginx"' tests are unnecessary. The last two patterns above don't even give you a captcha to solve, just deny access. You might want to limit your detection to 403 and 503 responses (or maybe exempt 200-series and 300-series responses). These are a couple of sites that used customized CloudFlare: https://4chan.org/ ("Verification Required") https://yelp.com/ ("You're not barking up the wrong tree...") yelp.com only started using CloudFlare a little while ago. It's a funny case, because they *also* implement a hard Tor blacklist. Once you get through the CloudFlare captcha 403, you get a 503 from a different system. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
Thank you, Yawning! This looks great. :) I think Kate was planning on writing up an official position of the Tor project on the CloudFlare situation. Amongst other things, it's expected to contain several strong arguments for convincing sites that the CAPTCHA does them no good and to make their CloudFlare configuration more Tor friendly. Or simply use another CDN like Akamai. After that appears, one could add a mailto: link alongside the cfc button, so that users could easily start a dialog with the site where they encounter a CloudFlare CAPTCHA. A mailto: link can have email header and body information like mailto:..@..?subject=Unreachable from Tor due to CloudFlare CAPTCA&body=.. And the body could contain some text derived from whatever Kate writes. In principle, the mailto: link's destination could determine the site's contact information from whois : https://stackoverflow.com/questions/8435678/whois-with-javascript If that's annoying, then simply placing a unix command like "whois [site] | grep Email" into the body along with some explanation should suffice. It's easy enough to do all this with a shell script of course, but if cfc moves towards many people using it then maybe encouraging people to email sites will help. Jeff On Wed, 2016-03-23 at 11:00 +, Yawning Angel wrote: > [I hate replying to myself.] > > On Wed, 23 Mar 2016 09:15:36 + > Yawning Angel wrote: > > My "proof of concept" tech demo is what I consider good enough for > > use by brave people that aren't me, so I have put up an XPI package > > at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ > > I noticed some dumb bugs and UI issues in the version I pushed so I > changed a lot of things and uploaded a new version that should be > better behaved. In particular: > > * It is now Content Script based, and does IPC so it may survive the >transition to sandboxed/multiprocess firefox better. > > * It will always inject a button into the DOM instead of trying to >display browser UI stuff (content scripts are supposed to have >isolation...). > >* The UI selection pref is removed. > >* The ask on captcha option for behavior is removed, since a button > always will be there to bypass it. > > * Loading lots of pages that end up displaying street signs *should* >now behave correctly. > > The old release is under `./old` for posterity. > > Sorry for the inconvenience, > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
Nice! Random thought: rather than "unreachable from Tor", "unreachable when using the internet safely." This is really about people wanting security, and these companies not wanting to grapple with what their customers want. On Wed, Mar 23, 2016 at 05:31:50PM +0100, Jeff Burdges wrote: | | Thank you, Yawning! This looks great. :) | | | I think Kate was planning on writing up an official position of the Tor | project on the CloudFlare situation. Amongst other things, it's | expected to contain several strong arguments for convincing sites that | the CAPTCHA does them no good and to make their CloudFlare configuration | more Tor friendly. Or simply use another CDN like Akamai. | | After that appears, one could add a mailto: link alongside the cfc | button, so that users could easily start a dialog with the site where | they encounter a CloudFlare CAPTCHA. | | A mailto: link can have email header and body information like | mailto:..@..?subject=Unreachable from Tor due to CloudFlare | CAPTCA&body=.. | And the body could contain some text derived from whatever Kate writes. | | In principle, the mailto: link's destination could determine the site's | contact information from whois : | https://stackoverflow.com/questions/8435678/whois-with-javascript | If that's annoying, then simply placing a unix command like "whois | [site] | grep Email" into the body along with some explanation should | suffice. | | It's easy enough to do all this with a shell script of course, but if | cfc moves towards many people using it then maybe encouraging people to | email sites will help. | | Jeff | | | | | On Wed, 2016-03-23 at 11:00 +, Yawning Angel wrote: | > [I hate replying to myself.] | > | > On Wed, 23 Mar 2016 09:15:36 + | > Yawning Angel wrote: | > > My "proof of concept" tech demo is what I consider good enough for | > > use by brave people that aren't me, so I have put up an XPI package | > > at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ | > | > I noticed some dumb bugs and UI issues in the version I pushed so I | > changed a lot of things and uploaded a new version that should be | > better behaved. In particular: | > | > * It is now Content Script based, and does IPC so it may survive the | >transition to sandboxed/multiprocess firefox better. | > | > * It will always inject a button into the DOM instead of trying to | >display browser UI stuff (content scripts are supposed to have | >isolation...). | > | >* The UI selection pref is removed. | > | >* The ask on captcha option for behavior is removed, since a button | > always will be there to bypass it. | > | > * Loading lots of pages that end up displaying street signs *should* | >now behave correctly. | > | > The old release is under `./old` for posterity. | > | > Sorry for the inconvenience, | > | > ___ | > tor-dev mailing list | > tor-dev@lists.torproject.org | > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev | | ___ | tor-dev mailing list | tor-dev@lists.torproject.org | https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- Don't miss out on my news, which comes out roughly once a quarter. http://adam.shostack.org/newthing.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
Yawning Angel wrote: Inspired by https://trac.torproject.org/projects/tor/ticket/18361 I've been working on way to improve the situation. Neat. In the thread someone mentions that it's possible to derive the answer for the old-style street number captchas using tesseract [1]. Interestingly, there is a version of tesseract in javascript [2]. This is probably not especially useful for the current "select all boxes that contain one pixel of street sign" Recaptcha system, but if there were a way to trigger the old behavior, these techniques could be used together. ~Griffin [1] https://trac.torproject.org/projects/tor/ticket/18361#comment:173 [2] http://tesseract.projectnaptha.com/ -- “Not having a clear goal leads to death by a thousand compromises.” ~ Mark Pincus ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
On Wed, Mar 23, 2016 at 12:33:15PM -0400, Adam Shostack wrote: > Nice! > > Random thought: rather than "unreachable from Tor", "unreachable when > using the internet safely." This is really about people wanting > security, and these companies not wanting to grapple with what their > customers want. Yes! Not random at all. When trying to succincly contrast current means to access and use registered-domain sites vs. onionsites I not infrequently slip into calling them the insecure web and the secure web respectively. aloha, Paul ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
On Wed, Mar 23, 2016 at 2:15 AM, Yawning Angel wrote: > My "proof of concept" tech demo is what I consider good enough for > use by brave people that aren't me, so I have put up an XPI package > at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ Very cool! > * If archive.is is evil, they can track you across page fetches >trivially, because this sort of use case is outside of Tor Browser's >current threat model (Yes, CloudFlare/Google can also do the same >thing currently, who do you trust more?). Because CloudFlare presents its captcha page under the target site's domain name, and the Google ReCAPTCHA iframe is embedded inside that, Tor Browser is designed to prevent tracking across visits to different CloudFlared sites. So in that sense the archive.is option allows more tracking. One possible solution could be for the extension to replace the HTML content inside a desired content page (say, https://imgur.com/some-page.html) with an iframe containing the archive.is version. The iframe would then be embedded under the desired first-party domain (e.g., imgur.com instead of archive.is) so that the page requests and caching are isolated to imgur.com. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc
On Wed, 2016-03-23 at 14:09 -0400, Paul Syverson wrote: > On Wed, Mar 23, 2016 at 12:33:15PM -0400, Adam Shostack wrote: > > Random thought: rather than "unreachable from Tor", "unreachable when > > using the internet safely." This is really about people wanting > > security, and these companies not wanting to grapple with what their > > customers want. > > Yes! Not random at all. When trying to succincly contrast current means > to access and use registered-domain sites vs. onionsites I not infrequently > slip into calling them the insecure web and the secure web respectively. Yes, that sounds reasonable. There would be a bunch of linguistic decisions like that. I suggested waiting until Kate finishes her CloudFlare FAQ specifically because she would already be making many relevant such decisions. I think the main technical question is : How hard is it to safely use whois from JavaScript? Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Request for feedback/victims: cfc-0.0.2
Hello, Thanks for the feedback so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] New version with changes some that add functionality, some code of quality stuff, hence a version bump to 0.0.2, especially since it'll probably be a bit before I can focus on tackling the TODO items. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160327/ Major changes: * Properly deregister the HTTP event listeners on addon unload. * Toned down the snark when I rewrite the CloudFlare captcha page, since I wasn't very nice. * Additional quality of life/privacy improvements courtesy of Will Scott, both optional and enabled by default. * (QoL) Skip useless landing pages (github.com/twitter.com will be auto-redirected to the "search" pages). * (Privacy) Kill twitter's outbound link tracking (t.co URLs) by rewriting the DOM to go to the actual URL when possible. Since DOM changes made from content scripts are isolated from page scripts, this shouldn't substantially alter behavior. * (Code quality) Use a pref listener to handle preference changes. TODO: * Try to figure out a way to mitigate the ability for archive.is to track you. The IFRAME based approach might work here, needs more investigation. * Handle custom CloudFlare captcha pages (In general my philosophy is to minimize false positives, over avoiding false negatives). Looking at the regexes in dcf's post, disabling the title check may be all that's needed. * Handle CloudFlare 503 pages. * Get samples of other common blanket CDN based Tor blocking/major sites that block Tor, and implement bypass methods similar to how CloudFlare is handled. * Look into adding a "contact site owner" button as suggested by Jeff Burdges et al (Difficult?). * Support a user specified "always use archive.is for these sites" list. * UI improvements. * More Quality of Life/Privacy improvements (Come for the Street Signs, stay for the user scripts). * I will eventually get annoyed enough at being linked to mobile wikipedia that I will rewrite URLs to strip out the ".m.". * Test this on Fennec. * Maybe throw this up on addons.mozilla.org. Regards, -- Yawning Angel pgpKqMog0USwp.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Request for feedback/victims: cfc-0.0.3
Thanks for the feedback/bug reports so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] This is the third release of the archive.is based captcha-be-gone extension for Tor Browser. Relative to 0.0.2, this has a minor bugfix that fixes URLs with trendy "@" signs in odd places by replacing the URI/URL parser (Eg: "https://medium.com/@blahblahblah";). I've been busy with other things so this was the only change, but medium.com is popular enough that it deserved a new XPI. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160418/ Regards, -- Yawning Angel pgpGzQ4vqk3ED.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
* Yawning Angel schrieb am 2016-03-27 um 08:12 Uhr: >* (QoL) Skip useless landing pages (github.com/twitter.com will be > auto-redirected to the "search" pages). When you're logged into Twitter, https://twitter.com/ shows you your stream of tweets. With the current version, a user can't see its own stream anymore. Can you redirect to the search page only for non-logged-in users? -- Jens Kubieziel http://www.kubieziel.de 21 ist nur die halbe Wahrheit signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Tue, 29 Mar 2016 10:09:15 +0200 Jens Kubieziel wrote: > * Yawning Angel schrieb am 2016-03-27 um 08:12 Uhr: > >* (QoL) Skip useless landing pages (github.com/twitter.com will > > be auto-redirected to the "search" pages). > > When you're logged into Twitter, https://twitter.com/ shows you your > stream of tweets. With the current version, a user can't see its own > stream anymore. Can you redirect to the search page only for > non-logged-in users? Probably since I should be able to see that you're logged in based on the request made (I never used twitter.com to view my own stream, just went to twitter.com/blahblahblah). That said, debugging/implementing something like that requires a twitter account, which I don't have anymore (Nuked because it's a waste of time, horrible medium, etc). For now, this feature can be disabled from the addon preferences. Regards, -- Yawning Angel pgpoB0_DxwzqR.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
I'm impressed with how much nicer the web gets with this. Thank you Yawning! :) On Sun, 2016-03-27 at 06:12 +, Yawning Angel wrote: >* (QoL) Skip useless landing pages (github.com/twitter.com will be > auto-redirected to the "search" pages). Ahh that's why that happened. lol >* (Privacy) Kill twitter's outbound link tracking (t.co URLs) by > rewriting the DOM to go to the actual URL when possible. Since > DOM changes made from content scripts are isolated from page > scripts, this shouldn't substantially alter behavior. Nice! > TODO: > > * Try to figure out a way to mitigate the ability for archive.is to >track you. The IFRAME based approach might work here, needs more >investigation. Interesting point. > * Handle custom CloudFlare captcha pages (In general my philosophy is >to minimize false positives, over avoiding false negatives). >Looking at the regexes in dcf's post, disabling the title check may >be all that's needed. I've noticed some hiccups with medium on the auto mode, like say https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7 It sometimes works if you hit refresh though. > * Look into adding a "contact site owner" button as suggested by Jeff >Burdges et al (Difficult?). Just noticed this minimalist whois client in node.js : https://github.com/carlospaulino/node-whoisclient/blob/master/index.js > * Support a user specified "always use archive.is for these sites" >list. > > * UI improvements. A task bar icon might find several uses: - A "View this page through archive.is" button for when CFC misses a CAPTCHA, or even if the CAPTCHA is not CloudFlare. - A "contact site button" that worked even after passing to archive.is. - A "Give me the CAPTCHA" button for those who configure CFC to automatically load archive.is. I'm using another browser profile for this last point currently. In fact, it fit perfectly into my existing pattern of browser profiles. Yet, browser profiles are not user-friendly, especially in TBB, so this would benefit people who do not use profiles. Wonderful extension! Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
Are there any more sites where CloudFalre appears on archive.is? https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/ https://archive.is/7u5P8 It's some particularly harsh CloudFlare configuration perhaps? Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Fri, 01 Apr 2016 18:21:10 +0200 Jeff Burdges wrote: > Are there any more sites where CloudFalre appears on archive.is? > > https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/ > https://archive.is/7u5P8 > > It's some particularly harsh CloudFlare configuration perhaps? Without knowing how archive.is works, and how CloudFlare works, it's hard to tell. Since archive.is sets "X-Forwarded-For", it's not particularly hard to figure out if a Tor user is the one requesting a snapshot. I requested a new snapshot and the captcha error page in the archive shows that the IP of my exit, so part of the ClouldFlare infrastructure at least peeks at the header. I'll probably add support for other (user-configurable?) cached content providers when I have time. The archive.is person doesn't seem to want to respond to e-mail, so asking them to optionally not set X-F-F, seems like it'll go absolutely nowhere. Regards, -- Yawning Angel pgpbdDFFzx9_I.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On 2016-04-01 18:06, Yawning Angel wrote: On Fri, 01 Apr 2016 18:21:10 +0200 Jeff Burdges wrote: Are there any more sites where CloudFalre appears on archive.is? https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/ https://archive.is/7u5P8 It's some particularly harsh CloudFlare configuration perhaps? Without knowing how archive.is works, and how CloudFlare works, it's hard to tell. Since archive.is sets "X-Forwarded-For", it's not particularly hard to figure out if a Tor user is the one requesting a snapshot. I requested a new snapshot and the captcha error page in the archive shows that the IP of my exit, so part of the ClouldFlare infrastructure at least peeks at the header. I'll probably add support for other (user-configurable?) cached content providers when I have time. The archive.is person doesn't seem to want to respond to e-mail, so asking them to optionally not set X-F-F, seems like it'll go absolutely nowhere. Regards, webcitation.org is an archive.is alternative. Potentially it doesn't forward request headers (?) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Sat, 02 Apr 2016 17:00:10 + ban...@openmailbox.org wrote: > webcitation.org is an archive.is alternative. Potentially it doesn't > forward request headers (?) It's not a request header set by the browser. archive.is is acting like a HTTP proxy and explicitly setting X-F-F. From the FAQ: But take in mind that when you archive a page, your IP is being sent to the the website you archive as though you are using a proxy (in X-Forwarded-For header). This feature allows websites (e.g shops or the sites with weather forecast) target your region, not mine. If there's an easy way to automate requests to other cache/archive services, I will integrate them when I have time[0]. As far as I've seen archive.is has a fairly principled stance on what they will and will not host (The takedown policies listed on webcitation.org don't particularly give me warm and happy feelings), so unless things become unworkable, I'm likely to leave it as the default for the foreseeable future. Regards, -- Yawning Angel [0]: cfc is FOSS, patches accepted. pgp2mzv5_3mJW.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Sat, Apr 02, 2016 at 07:19:30PM +, Yawning Angel wrote: > It's not a request header set by the browser. archive.is is acting > like a HTTP proxy and explicitly setting X-F-F. I wonder what would happen if the browser *also* set X-F-F...? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Sat, 2 Apr 2016 18:14:26 -0400 Ian Goldberg wrote: > On Sat, Apr 02, 2016 at 07:19:30PM +, Yawning Angel wrote: > > It's not a request header set by the browser. archive.is is acting > > like a HTTP proxy and explicitly setting X-F-F. > > I wonder what would happen if the browser *also* set X-F-F...? Unfortunately, it appears that archive.is tramples over X-F-F if it is already set. Maybe others will have better luck engaging with the operator(s) of archive.is than I have. Regards, -- Yawning Angel pgpHSqIn1dO_s.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request for feedback/victims: cfc-0.0.2
On Fri, Apr 01, 2016 at 06:06:18PM +, Yawning Angel wrote: > I'll probably add support for other (user-configurable?) cached content > providers when I have time. The archive.is person doesn't seem to want > to respond to e-mail, so asking them to optionally not set X-F-F, seems > like it'll go absolutely nowhere. This is some kind of meta-archive service. Their about page lists many web archives (some of the specialized): http://timetravel.mementoweb.org/about/ http://www.mementoweb.org/guide/quick-intro/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev