July 2018 - cypherpunks-legacy

Secure erasing Info
by Richard Glaser 06 Jul '18

06 Jul '18

<MACENTERPRISE(a)LISTSERV.CUNY.EDU> FYI: Rendering Drives Completely Unreadable Can be Difficult ------------------------------------------------------- The National Association for Information Destruction has said it cannot endorse the use of wiping applications alone for ensuring that data have been effectively removed from hard drives. NAID executive director Bob Johnson said the only way to ensure that the data will be unreadable is to physically destroy the drives, and even that has to be done in certain ways to ensure its efficacy. Most major PC makers offer a drive destruction service for $20 or $30. Some hardware engineers say they understand why the drives have been created in a way that makes it hard to completely erase the data: customers demanded it because they were afraid of losing information they had stored on their drives. http://news.com.com/2102-1029_3-5676995.html?tag=st.util.print [Editor's Note (Pescatore): Cool, I want a "National Association for Information Destruction" tee shirt. How hard could it be to have an interlock feature - you can really, really clear the drive if you open the case, hold this button down while you delete? (Ranum): Peter Guttman, from New Zealand, did a terrific talk in 1997 at USENIX in which he showed electromicrographs of hard disk surfaces that had been "wiped" - you could still clearly see the 1s and 0s where the heads failed to line up perfectly on the track during the write/erase sequence. He also pointed out that you can tell more recently written data from less recently written data by the field strength in the area, which would actually make it much easier to tell what had been "wiped" versus what was persistent long-term store. The paper, minus the cool photos may be found at: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Hard disks, I've found, make satisfying small arms targets.] Here is Mac OS X software called "SPX" that uses the "Guttman" method of securely deleting data off a hard disk. If you want to donate old HD's this might be the best method for protecting your data that was on the HD other than physically destroying the HD's. http://rixstep.com/4/0/spx/ -- Thanks: Richard Glaser University of Utah - Student Computing Labs richard(a)scl.utah.edu 801-585-8016 _____________________________________________________ Subscription Options and Archives http://listserv.cuny.edu/archives/macenterprise.html ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Tor security advisory: hidden services can be located quickly
by Roger Dingledine 06 Jul '18

06 Jul '18

Versions affected: all stable versions, and all experimental versions up through 0.1.1.10-alpha. Impact: If you offer a Tor hidden service, an adversary who can run a fast Tor server and who knows some basic statistics can find the location of your hidden service in a matter of minutes to hours. Solution: You have three options: 1) Upgrade to Tor 0.1.1.12-alpha from the Tor download page [1]. You're all set, though be aware that this is an alpha release so there may be other bugs. You may also want to look through the release notes [2]. 2) Turn off your hidden service until the final 0.1.1.x release is out. It may be several months. 3) Stick with Tor 0.1.0.16 and manually configure a half dozen EntryNodes. See the FAQ entry [3] for some hints about how to do this. The details: Tor researchers Lasse ?verlier and Paul Syverson have confirmed that a previously theoretical attack on Tor works very well in practice. Specifically, they found that a malicious Tor server can locate a hidden service more quickly than was previously believed. The attack is simple: access the hidden service repeatedly, and keep track of who builds circuits through you shortly after each access. Because you can induce your victim to build a new circuit on demand, eventually one of his circuits will start at your node. To slow this attack, our latest experimental release implements a new feature called "guard nodes": it automatically chooses a handful of entry nodes and sticks with them for all circuits. This idea is adapted from the "helper node" concept published by Wright et al [4], but with improved reliability: rather than picking a set of entry nodes and refusing to access the Tor network if they all become unreachable, Tor's design dynamically picks new guards as needed, yet switches back to the old ones when they become reachable again. Therefore Tor users still have the same level of robustness as before, but the chance of a successful attack by a limited adversary is greatly reduced. More details will be presented on January 14 at Shmoocon [5] and January 26 at Black Hat Federal [6]. --Roger [1] http://tor.eff.org/download [2] http://archives.seul.org/or/talk/Jan-2006/msg00024.html http://archives.seul.org/or/talk/Jan-2006/msg00026.html [3] http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit [4] http://freehaven.net/anonbib/#wright03 [5] http://www.shmoocon.org/speakers.html#overlier [6] http://www.blackhat.com/html/bh-federal-06/bh-fed-06-speakers.html#Syverson ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[liberationtech] Behind Blue Coat: An Update From Burma
by Ron Deibert 06 Jul '18

06 Jul '18

Behind Blue Coat: An update from Burma Background Citizen Lab research into the use of commercial filtering products in countries under the rule of authoritarian regimes has previously documented the use of devices manufactured by U.S.-based Blue Coat Systems in Syria and Burma. In Behind Blue Coat: Investigations of commercial filtering in Syria and Burma, we identified Blue Coat devices in Burma through the error messages, hostnames and filtering behaviour on Burmese Internet service provider (ISP) Yatanarpon Teleport. Since the publication of Behind Blue Coat, it has been reported that the U.S. Commerce Department has launched an investigation to determine if the company had prior knowledge that its equipment was being used by the Syrian government.1 This action was launched following a call from three U.S. Senators for an investigation into Blue Coat and NetApp, another U.S. company whose equipment has been implicated in surveillance activities by the Syrian government.2 Additional evidence gathered by the Citizen Lab from Burma since the publication of that report has provided further confirmation that Blue Coatbs devices are presently in use in the country. A message displayed to users by Yatanarpon Teleport references Blue Coat in the URL and is consistent with how Blue Coat devices display notification messages to users. Combined with the evidence presented in Behind Blue Coat, these new findings present a strong case that Blue Coatbs devices are actively in use in Burma. More here: http://citizenlab.org/2011/11/behind-blue-coat-an-update-from-burma/ Ronald J. Deibert Director, The Canada Centre for Global Security Studies and The Citizen Lab Munk School of Global Affairs University of Toronto r.deibert(a)utoronto.ca http://deibert.citizenlab.org/ twitter.com/citizenlab _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[i2p] weekly status notes [jan 4]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, time for our first weekly status notes of 2005 * Index 1) Net status 2) 0.4.2.6 3) 0.5 4) jabber @ chat.i2p 5) ??? * 1) Net status Over the last week, things have been pretty interesting on the net - on nye, there were some comments posted to a popular website talking about i2p-bt and we've had a small burst of new users. At the moment there are between 120-150 routers on the net, though that peaked at 160 a few days ago. The network held its own though, with high capacity peers picking up the excess load without much disruption to other peers. Some users running without bandwidth limits on really fast links have reported throughput of 2-300KBps, while those with less capacity use the usual low 1-5KBps. I think I remember Connelly mentioning that he was seeing 300+ different routers over the course of a few days after new years, so there has been significant churn. On the other hand, we now have a steady 120-150 users online, unlike the previous 80-90, which is a reasonable increase. We still do *not* want it to grow too much yet though, as there are known implementation issues that still need to be done. Specifically, until the 0.6 release [1], we're going to want to stay below 2-300 peers to keep the number of threads at a reasonable level. However, if someone wants to help out implementing the UDP transport, we can get there much faster. In the last week, I've watched the stats put out by the i2p-bt trackers and there have been gigs of large files transferred, with some reports of 80-120KBps. IRC has had more bumps than usual since those comments were posted on that website, but its still on the order of hours between disconnect. (from what I can tell, the router that irc.duck.i2p is on has been running pretty close to its bandwidth limit, which would explain things) [1] http://www.i2p.net/roadmap#0.6 * 2) 0.4.2.6 There have been some fixes and new features added to CVS since the 0.4.2.5 release that we're going to want to roll out soon, including reliability fixes for the streaming lib, improved resiliance to IP address change, and the bundling of ragnarok's addressbook implementation. If you haven't heard of the addressbook or haven't used it, the short story is that it will magically update your hosts.txt file by periodically fetching and merging changes from some anonymously hosted locations (default being http://dev.i2p/i2p/hosts.txt and http://duck.i2p/hosts.txt) You won't need to change any files, touch any configuration, or run any extra applications - it'll be deployed inside the I2P router as a standard .war file. Of course, if you *do* want to get down and dirty with the addressbook, you are more than welcome to - see Ragnarok's site [2] for the details. People who already have the addressbook deployed in their router will need to do a little tap dancing during the 0.4.2.6 upgrade, but it'll work with all your old config settings. [2] http://ragnarok.i2p/ * 3) 0.5 Numbers, numbers, numbers! Well, as I've said before, the 0.5 release will be revamping how the tunnel routing works, and progress is being made on that front. For the last few days I've been implementing the new encryption code (and unit tests), and once they're working I'll post up a doc describing my current thoughts on how, what, and why the new tunnel routing will operate. I'm getting the encryption implemented for it now instead of later so that people can review what it means in a concrete sense, as well as find problems areas and suggestions for improvement. I'm hoping to have the code working by the end of the week, so maybe there'll be more docs posted this weekend. No promises though. * 4) jabber @ chat.i2p jdot has started up a new jabber server, and it seems to work pretty well for both one on one conversations and group chat. check out the info on the forum [3]. the i2p dev discussion channel will still be the irc #i2p, but its always nice to have alternatives. [3] http://forum.i2p.net/viewtopic.php?t=229 * 5) ??? Ok, thats about all I have to mention at the moment - I'm sure there's lots more going on that other people want to bring up though, so swing on by the meeting in 15m @ the usual place [4] and tell us whats up! =jr [4] irc://irc.{duck,baffled}.i2p/#i2p irc://iip/#i2p irc://irc.freenode.net/#i2p -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2wGXGnFL2th344YRAuAkAJwPh8frN6Caof0unduGzijXFyFDnwCfXD/8 ZQXQmqk6EIx184r2Zi7poZg= =+oCL -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [p2p-hackers] Whistle-blower site platform design
by Len Sassaman 06 Jul '18

06 Jul '18

On Thu, 23 Dec 2010, Ian G wrote: > If I think of the 3 whistleblower cases I'm mildly familiar with, there > is no commonality between the source protection aspects. I think this > might be something where whatever technical system you put in place, a > wise whistleblower would not be keen to trust it. Given that the > typical cost of being a whistleblower is probably minimum loss of income > for years, and loss of liberty likely, it might be a really high target. I think we have to assume that the whistleblowers who are inclined to use a web-based submission system are likely to lack the requisite skills to even begin an assessment of source protection measures. Several of the new leaksites have already been criticised for their security (Balkanleaks runs on Joomla, which is making people unhappy; Brusselsleaks is WordPress based, etc...), though I don't expect that to fully deter submissions. At the end of the day, the whistleblowers either trust the site operators to get their security right, or they don't. I view our challenge to be to provide as "off-the-shelf" a solution as possible, to both aid publishers in deploying a system that addresses the security concerns, and to provide a base of reference for how those security concerns can be handled (in addition to "what security concerns are present.") > If that view holds, it might be better kicked out of any technical > design for a publishing system. As I've said before, I think we need to think of these as complementary components. > OTOH, If you wanted to make source protection strong *and* technical > (e.g., uploading), then you might want to make it the same system for > both uploading and downloading. Hiding the source in a crowd of > downloaders is one benefit, and making the download protection high > profile may help to make the overall source/sink protection better. I've already been thinking along those lines, myself; I'm resisting discussing ideas I have for a specific solution to these challenges, since I do think we're lacking a coherent problem statement (though this thread is making progress on that front). That said, if we're able to provide a covert channel for submission as a product of the distribution scheme, I think we gain an important benefit. The idea of using information-theoretic PIR in the document distribution system intrigues me. Bi-directional PIR is something of an open problem, but should be feasible in a system where the model user downloads far more than they upload. In a Chor-based PIR scheme such as the one Pynchon uses, one can see the query bitstreams being repurposed as a submission channel. It's tricky, though, and I don't want to fixate on a potential solution before clarifying the issues. At the end of the day, these are two discrete problems. If we can compose the solutions so that a single product provides for the needs of both, with additional benefits, that's great -- but I don't think that composition is strictly necessary at this point. > 4. Gatekeeper role. It would seem that any pure technical system could > be flooded by junk. Typically a team is needed to analyse, filter, edit > and approve. Yes; I touched in this in my response to Joss. A fully automated system is not what we need here, imo; this isn't about simply dumping files onto an Eternity Service. > Some thoughts! Good thoughts! --Len. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [p2p-hackers] Whistle-blower site platform design
by Len Sassaman 06 Jul '18

06 Jul '18

On Thu, 23 Dec 2010, Ian G wrote: > If I think of the 3 whistleblower cases I'm mildly familiar with, there > is no commonality between the source protection aspects. I think this > might be something where whatever technical system you put in place, a > wise whistleblower would not be keen to trust it. Given that the > typical cost of being a whistleblower is probably minimum loss of income > for years, and loss of liberty likely, it might be a really high target. I think we have to assume that the whistleblowers who are inclined to use a web-based submission system are likely to lack the requisite skills to even begin an assessment of source protection measures. Several of the new leaksites have already been criticised for their security (Balkanleaks runs on Joomla, which is making people unhappy; Brusselsleaks is WordPress based, etc...), though I don't expect that to fully deter submissions. At the end of the day, the whistleblowers either trust the site operators to get their security right, or they don't. I view our challenge to be to provide as "off-the-shelf" a solution as possible, to both aid publishers in deploying a system that addresses the security concerns, and to provide a base of reference for how those security concerns can be handled (in addition to "what security concerns are present.") > If that view holds, it might be better kicked out of any technical > design for a publishing system. As I've said before, I think we need to think of these as complementary components. > OTOH, If you wanted to make source protection strong *and* technical > (e.g., uploading), then you might want to make it the same system for > both uploading and downloading. Hiding the source in a crowd of > downloaders is one benefit, and making the download protection high > profile may help to make the overall source/sink protection better. I've already been thinking along those lines, myself; I'm resisting discussing ideas I have for a specific solution to these challenges, since I do think we're lacking a coherent problem statement (though this thread is making progress on that front). That said, if we're able to provide a covert channel for submission as a product of the distribution scheme, I think we gain an important benefit. The idea of using information-theoretic PIR in the document distribution system intrigues me. Bi-directional PIR is something of an open problem, but should be feasible in a system where the model user downloads far more than they upload. In a Chor-based PIR scheme such as the one Pynchon uses, one can see the query bitstreams being repurposed as a submission channel. It's tricky, though, and I don't want to fixate on a potential solution before clarifying the issues. At the end of the day, these are two discrete problems. If we can compose the solutions so that a single product provides for the needs of both, with additional benefits, that's great -- but I don't think that composition is strictly necessary at this point. > 4. Gatekeeper role. It would seem that any pure technical system could > be flooded by junk. Typically a team is needed to analyse, filter, edit > and approve. Yes; I touched in this in my response to Joss. A fully automated system is not what we need here, imo; this isn't about simply dumping files onto an Eternity Service. > Some thoughts! Good thoughts! --Len. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[i2p] weekly status notes [jan 4]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, time for our first weekly status notes of 2005 * Index 1) Net status 2) 0.4.2.6 3) 0.5 4) jabber @ chat.i2p 5) ??? * 1) Net status Over the last week, things have been pretty interesting on the net - on nye, there were some comments posted to a popular website talking about i2p-bt and we've had a small burst of new users. At the moment there are between 120-150 routers on the net, though that peaked at 160 a few days ago. The network held its own though, with high capacity peers picking up the excess load without much disruption to other peers. Some users running without bandwidth limits on really fast links have reported throughput of 2-300KBps, while those with less capacity use the usual low 1-5KBps. I think I remember Connelly mentioning that he was seeing 300+ different routers over the course of a few days after new years, so there has been significant churn. On the other hand, we now have a steady 120-150 users online, unlike the previous 80-90, which is a reasonable increase. We still do *not* want it to grow too much yet though, as there are known implementation issues that still need to be done. Specifically, until the 0.6 release [1], we're going to want to stay below 2-300 peers to keep the number of threads at a reasonable level. However, if someone wants to help out implementing the UDP transport, we can get there much faster. In the last week, I've watched the stats put out by the i2p-bt trackers and there have been gigs of large files transferred, with some reports of 80-120KBps. IRC has had more bumps than usual since those comments were posted on that website, but its still on the order of hours between disconnect. (from what I can tell, the router that irc.duck.i2p is on has been running pretty close to its bandwidth limit, which would explain things) [1] http://www.i2p.net/roadmap#0.6 * 2) 0.4.2.6 There have been some fixes and new features added to CVS since the 0.4.2.5 release that we're going to want to roll out soon, including reliability fixes for the streaming lib, improved resiliance to IP address change, and the bundling of ragnarok's addressbook implementation. If you haven't heard of the addressbook or haven't used it, the short story is that it will magically update your hosts.txt file by periodically fetching and merging changes from some anonymously hosted locations (default being http://dev.i2p/i2p/hosts.txt and http://duck.i2p/hosts.txt) You won't need to change any files, touch any configuration, or run any extra applications - it'll be deployed inside the I2P router as a standard .war file. Of course, if you *do* want to get down and dirty with the addressbook, you are more than welcome to - see Ragnarok's site [2] for the details. People who already have the addressbook deployed in their router will need to do a little tap dancing during the 0.4.2.6 upgrade, but it'll work with all your old config settings. [2] http://ragnarok.i2p/ * 3) 0.5 Numbers, numbers, numbers! Well, as I've said before, the 0.5 release will be revamping how the tunnel routing works, and progress is being made on that front. For the last few days I've been implementing the new encryption code (and unit tests), and once they're working I'll post up a doc describing my current thoughts on how, what, and why the new tunnel routing will operate. I'm getting the encryption implemented for it now instead of later so that people can review what it means in a concrete sense, as well as find problems areas and suggestions for improvement. I'm hoping to have the code working by the end of the week, so maybe there'll be more docs posted this weekend. No promises though. * 4) jabber @ chat.i2p jdot has started up a new jabber server, and it seems to work pretty well for both one on one conversations and group chat. check out the info on the forum [3]. the i2p dev discussion channel will still be the irc #i2p, but its always nice to have alternatives. [3] http://forum.i2p.net/viewtopic.php?t=229 * 5) ??? Ok, thats about all I have to mention at the moment - I'm sure there's lots more going on that other people want to bring up though, so swing on by the meeting in 15m @ the usual place [4] and tell us whats up! =jr [4] irc://irc.{duck,baffled}.i2p/#i2p irc://iip/#i2p irc://irc.freenode.net/#i2p -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2wGXGnFL2th344YRAuAkAJwPh8frN6Caof0unduGzijXFyFDnwCfXD/8 ZQXQmqk6EIx184r2Zi7poZg= =+oCL -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

None
by Greg Broiles 06 Jul '18

06 Jul '18

> I don't follow the other list you mentioned, so I don't know what the > actual problem to solve is - my guess is that this is an anti-bot > protection measure, intended to make sure that only human participants can > engage in a conversation. Yep, that's it. > If that's the problem - or if it's similar - you'll also need to make the > puzzle difficult enough that > it's hard to brute-force or solve statistically - let's say you provide the > other party with 20 images, > 19 cats and 1 dog, and ask them to identify the dog. > > What keeps a bot from answering the question 20 times? Let's assume the > first arms-race countermeasure prevents answering the question more than > once by generating puzzles on-the-fly from known cat and dog images - so > the bot just picks an answer randomly, and keeps doing that until they hit. Oops... never thought of that. > Can God create a rock so big he can't lift it? No, just as he can't create round squares. What's that got to do with anything? > This sounds like maybe it's essentially a credentialling/ID problem, where > you're generating credentials on the fly based on a short-form Turing test. > Can you restate the problem so that instead of a Turing test it's a more > familiar multi-channel authentication process? (e.g., require new > participants to have "introductions" from existing participants, track > introductions, and remove the access for accounts found to be bots, or > found to have introduced bots .. or similar.) Well... one of the points of Freenet is to have anonymity (even if not cryptographically strong, just statistical anonimity). I don't know how well that can work with "introductions". [Maybe the public / private key proposals - which I haven't followed up closely - could me modified to be used as some sort of a pseudonym.] Mark

1 0

None
by Greg Broiles 06 Jul '18

06 Jul '18

> I don't follow the other list you mentioned, so I don't know what the > actual problem to solve is - my guess is that this is an anti-bot > protection measure, intended to make sure that only human participants can > engage in a conversation. Yep, that's it. > If that's the problem - or if it's similar - you'll also need to make the > puzzle difficult enough that > it's hard to brute-force or solve statistically - let's say you provide the > other party with 20 images, > 19 cats and 1 dog, and ask them to identify the dog. > > What keeps a bot from answering the question 20 times? Let's assume the > first arms-race countermeasure prevents answering the question more than > once by generating puzzles on-the-fly from known cat and dog images - so > the bot just picks an answer randomly, and keeps doing that until they hit. Oops... never thought of that. > Can God create a rock so big he can't lift it? No, just as he can't create round squares. What's that got to do with anything? > This sounds like maybe it's essentially a credentialling/ID problem, where > you're generating credentials on the fly based on a short-form Turing test. > Can you restate the problem so that instead of a Turing test it's a more > familiar multi-channel authentication process? (e.g., require new > participants to have "introductions" from existing participants, track > introductions, and remove the access for accounts found to be bots, or > found to have introduced bots .. or similar.) Well... one of the points of Freenet is to have anonymity (even if not cryptographically strong, just statistical anonimity). I don't know how well that can work with "introductions". [Maybe the public / private key proposals - which I haven't followed up closely - could me modified to be used as some sort of a pseudonym.] Mark

1 0

None
by Greg Broiles 06 Jul '18

06 Jul '18

> I don't follow the other list you mentioned, so I don't know what the > actual problem to solve is - my guess is that this is an anti-bot > protection measure, intended to make sure that only human participants can > engage in a conversation. Yep, that's it. > If that's the problem - or if it's similar - you'll also need to make the > puzzle difficult enough that > it's hard to brute-force or solve statistically - let's say you provide the > other party with 20 images, > 19 cats and 1 dog, and ask them to identify the dog. > > What keeps a bot from answering the question 20 times? Let's assume the > first arms-race countermeasure prevents answering the question more than > once by generating puzzles on-the-fly from known cat and dog images - so > the bot just picks an answer randomly, and keeps doing that until they hit. Oops... never thought of that. > Can God create a rock so big he can't lift it? No, just as he can't create round squares. What's that got to do with anything? > This sounds like maybe it's essentially a credentialling/ID problem, where > you're generating credentials on the fly based on a short-form Turing test. > Can you restate the problem so that instead of a Turing test it's a more > familiar multi-channel authentication process? (e.g., require new > participants to have "introductions" from existing participants, track > introductions, and remove the access for accounts found to be bots, or > found to have introduced bots .. or similar.) Well... one of the points of Freenet is to have anonymity (even if not cryptographically strong, just statistical anonimity). I don't know how well that can work with "introductions". [Maybe the public / private key proposals - which I haven't followed up closely - could me modified to be used as some sort of a pseudonym.] Mark

1 0