- cypherpunks-legacy - lists.cpunks.org

Re: [serval-project-dev] Implementing a different routing protocol
by Fraser Cadger 06 Jul '18

06 Jul '18

Paul, Thank you very much for your fast reply! Your suggestion of using Rhizome instead of the MDP overlay is interesting, and definitely worth considering. Although I read a little about Rhizome on the Serval website I don't think I really appreciated it's capabilities. Also, when I installed the release version of Serval from Google Play, selecting Rhizome didn't appear to do anything (I'm not sure if this was an error or because the Rhizome could wasn't fully functioning then). Therefore, when I came to read the Serval code I decided to skip the Rhizome code to save time. Now it would seem as though this was a mistake, and your description of Rhizome in particular the journal concept sounds very interesting. I have been considering implementing some for of peer-to-peer/distributed approach for the actual streaming, due to the distribute nature of an ad-hoc/mesh network. In the envisaged networks node mobility will be permissible and this in addition to other dynamics calls for distributed approaches. The journal concept could be of great use here, with some tweaking as you mention. Using the p2p idea, I would envisage some form of peer/node selection for participation in the streaming, and then the use of my routing protocol to do the actual protocol. However, I have always intended interaction between the streaming application and routing layers, and so it is possible that the end result will lack the formal separation between overlay and 'underlay' routing found in traditional applications. I also like your suggestion of using Serval Maps for sharing location. In most geographic routing protocols there is something known as a location service which acts as a mechanism for sharing node locations so that nodes who are not in direct contact with each other can still find their locations. Initially, to test geographic routing, I was just planning on running five phones in a static scenario and checking locations manually, just to test geographic routing was possible. However, as my project is actually concerned with mobility I will eventually need to find a way of allowing nodes to share their locations. The visual aspect of Serval Maps also sounds appealing for, as you say, choosing which nodes you want to see a video. Having a graphical means of selecting nodes for streaming is definitely something we would like. One last question, I've had a quick look through the Serval code, and am I right in saying all of the Rhizome code is located in the serval-dna folder, or is there other Rhizome code elsewhere? About contributing code, I am happy to do that via the repository. Thanks again for your reply. Fraser On Nov 27, 2012 10:58 PM, "Paul Gardner-Stephen" <paul(a)servalproject.org> wrote: > Hello Fraser, > > Sounds like an interesting project. > > Jeremy has been doing the most work on the mesh routing parts of > Serval, so I expect that he will chime in with where things are in the > current state of the code. Note that routing is currently under > active development, so things are liable to change. > > Back to your actual goal, which is to stream multimedia content for > disaster recovery scenarios, this is something that we have been > thinking about from the earliest, and it is nice to hear that someone > is looking to work on it. > > Thinking about the general approach you are considering around greedy > routing, it may make more sense to use the Serval Rhizome > store-and-forward scheme as the basis, rather than the MDP/overlay > real-time routing. Rhizome understands the idea of a "journal" which > is really just a file that grows in successive versions. Nodes > receiving a journal can, in principle at least, pull just the new part > of the file. If the file has grown further in the meantime, then > another pull will occur. There would still be some tweaking > required using this approach, such as making Rhizome be more selective > about who it exchanges with so that it can be directed towards the > destination, but I think it would give you more resilient routing. The > tradeoff is likely to be increased latency, although I think that the > actual useful throughput would increase, because packet loss and > retransmission would be dealt with each hop. You would also be able > to use WiFi unicast packets, and thus the full WiFi bandwidth. > > You should also take a look at Serval Maps that provides functionality > for nodes to share their geographic location (via Rhizome), and that > could be used in place of adding geo tags to each packet. > > I guess overall I am envisaging a solution where Serval Maps provides > the geolocation information, and also possibly the user interface for > choosing which phone you want to see the video from. Then the video > or other content is pulled down via the improved Rhizome that you > would create. By using Rhizome, it doesn't matter if a link drops for > a short while, as the content will be cached on intermediate nodes, > and so it will deliver as soon as it is able. > > Anyway, happy to keep thinking through the options with you, and > looking forward to seeing what you create. > > We would prefer that you contribute any modifications you make back to > our repo so that everyone can benefit. We have a standard Harmony > Project issued contributor agreement that can facilitate that fairly > painlessly. > > Paul. > > On Wed, Nov 28, 2012 at 6:30 AM, Fraser Cadger <cadge01(a)googlemail.com> > wrote: > > Hi all, > > > > > > First of all, let me start by stating that I am very impressed with the > work > > of the Serval Project and the Serval app. I appreciate that it is still > > under development, but having experimented on several Android phones I > have > > found it really easy to use and effective. > > > > > > My name is Fraser Cadger and I am a third year PhD student at the > University > > of Ulster in Northern Ireland. My project is concerned with developing a > > framework to allow the streaming of multimedia content both live (i.e. > video > > call) and on-demand (recorded videos) in disaster recovery scenarios > using a > > mesh network of WiFi-enabled devices (currently this entails a testbed of > > six Android phones). As I am working with Android devices this obviously > > adds a layer of difficult when trying to implement ad-hoc networking. > After > > doing some searching I came across several different implementations of > > ad-hoc routing on Android, and after some experimentation the two I was > most > > interested in were Serval and Commotion (who I believe the Serval Project > > collaborates with). In the end I decided to work with the Serval app > because > > I felt that was the closest to what I was doing, and I also liked how it > > worked on the phones. > > > > > > Currently what I am interested in doing is implementing my own routing > > protocol (which is still under development) on the phones using Serval > as a > > base. That is to say, that I want to replace the modified BATMAN code > Serval > > uses for routing with the current version of my routing algorithm > > (originally written in C++ for ns-2 but re-writing in C should not be a > huge > > problem). Obviously I realise this will not be a simple as copying and > > pasting my code in and that is why I am sending this message. From > reading > > various comments in the code I understand that one of the main > modifications > > to Serval is to restrict broadcasting to link-local nodes (i.e. not > > network-wide broadcasting), if I have understand the code correctly that > is. > > The protocol I am developing is a variation of the greedy routing > protocol > > GPSR http://www0.cs.ucl.ac.uk/staff/b.karp/gpsr/gpsr.html . Both the > > original GPSR and my own protocol use limited broadcasting as well; > beacon > > (regular hello messages) are broadcast as far as one hop and nodes > maintain > > tables of neighbours who can be reached directly only. There is no > > conventional collection of routes; instead each node forwards a packet to > > their neighbour who best meets the criterion/criteria (generally > geographic > > location, i.e. located closest to the destination) one hop at a time. So > > packets are effectively passed from node to node without a formal route > > existing. This version of geographic routing is not perfect, and that is > why > > we are working on several modifications, but for now I am content to have > > some form of working geographic routing up and running. > > > > > > I have been reading through the code and trying to determine what parts I > > need to change and where to add my code. What I am looking for is the > point > > at which a node determines where to send a packet. I realise that this > will > > vary depending on the packet's origin, that is to say that when a node > > generates a new packet it will usually be treated differently from when > an > > intermediate node receives a packet from another node. Now, if I > understand > > correctly Serval's version of BATMAN does not use an explicit routing > table > > structure. I have came across a struct called subscriber defined in > > overlay_address.h, and from what I have read this seems to act as a > record > > of different nodes (destinations). Within the subscriber struct there is > an > > integer variable called reachable and this determines whether a node is > > reachable directly via unicast, broadcast, or must be reached > indirectly. If > > a node must be reached indirectly then there is a field called next_hop > > which if I understand correctly is a pointer to another struct (the > > intermediate node between ourselves and the destination). Is this > correct? > > Now, what I have noticed in the code is that sometimes next_hop contains > a > > pointer to another next_hop (i.e. next_hop->next_hop). What I'm guessing > > this means is that if there are multiple intermediate nodes (i.e. to > send a > > packet to node D node A needs to send it via B and C), then this is a > way of > > linking them as a route. So in essence, the subscriber struct contains > the > > route to a destination (by way of the next_hop attribute). > > > > > > For the actual routing, from reading the code I'm guessing that the > > 'overlay_route_recalc_node_metrics' function is used to determine > whether a > > destination can be reached directly or indirectly, and if indirectly it > will > > then assign the appropriate intermediate nodes as next_hop's. Therefore, > to > > create or change a route this function is called. Is this correct? > > > > > > In my case, I would like to do things slightly differently. As I am not > > doing end-to-end routing I do not need a list of destinations, instead > all I > > want is a list of 1-hop neighbours who can be accessed directly. Then > from > > that list I would determine which of these is the most suitable as the > next > > hop (obviously in my case this will require other stuff, for instance > adding > > GPS coordinates to the packet header and storing this in the subscriber > > field) and forward the packet to that node, and so on until the packet > has > > been delivered (or has to be dropped). > > > > > > The main questions I have are: > > > > > > Exactly where is a packet received and the node to which it should be > sent > > decided? > > > > i.e. if I want to decide which node to forward a packet to where should I > > decide this? > > > > I came across a method called 'overlay_mdp_receive' in mdp_client.c, is > this > > maybe what I'm looking for? > > > > Concerning the subscriber entity, is there an actual table/list/array of > > these b as I can't seem to find one? > > > > i.e. a list of neighbours/known nodes/destinations? > > > > > > I apologise if my questions and this email aren't very well-worded. > > Essentially what I'm looking for is some advice/guidance on exactly how > > routing (determining intermediate nodes for nodes which cannot be reached > > directly) and forwarding (looking at a received/originated packet and > > determining which node to send it to) is done. As I indicated earlier in > > this message, there are a few functions/structs I have stumbled across > that > > I think are relevant and I have made some guesses at what they are > doing, so > > I would appreciate if someone could correct/expand on my guesses. > > > > > > Any help/guidance I have would be greatly appreciated. It goes without > > saying that any code I develop myself I will happily share, and any > > issues/bugs I come across with Serval will be reported. > > > > > > Thank you for taking the time to read this message, I'm sorry it's a bit > on > > the long side but hopefully I've made myself clear. > > > > > > Regards, > > > > > > Fraser > > > > > > Ps. I realise this topic has been covered before, but I think some of the > > questions I am asking in this message are new. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Serval Project Developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/serval-project-developers/-/MgHT2-tr_dcJ > . > > To post to this group, send email to > > serval-project-developers(a)googlegroups.com. > > To unsubscribe from this group, send email to > > serval-project-developers+unsubscribe(a)googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/serval-project-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Serval Project Developers" group. > To post to this group, send email to > serval-project-developers(a)googlegroups.com. > To unsubscribe from this group, send email to > serval-project-developers+unsubscribe(a)googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/serval-project-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- 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: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
by bear 06 Jul '18

06 Jul '18

On Fri, 10 Sep 2004, Eugen Leitl wrote: >From: Joe Touch <touch(a)ISI.EDU> >>To clarify, this is not really "anonymous" in the usual sense. > >It does not authenticate the endpoint's identification, other than "same >place I had been talking to." > That's pseudonymity, not anonymity. >There's no difference between having no "name" and having a name you >cannot trust. I.e., I could travel under the name "anonymous" or "", or >under the name "A. Smith". If you don't know whether I am actually A. >Smith, the latter is identical to the former. This is just plain not true. When operating under a pseudonym, you are making linkable acts - linkable to each other even if not necessarily linkable to your own official identity. Anonymous actions or communications are those which cannot be linked to any other no matter how hard someone tries. We can expect the public to fail to grasp the distinction, but on this list "anonymous" is a very strong claim. Anonymity is *HARD* to do, not something that results from failing to check a credential. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

[Politech] DEA key logger used to eavesdrop in real time on alleged drug manufacturers [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

I've posted excerpts from the DEA PDFs at the link below and could post the PDFs themselves if there's sufficient interest. Previous Politech message, from way back in December 2000: http://www.politechbot.com/p-01545.html -Declan ---- http://news.com.com/8301-10784_3-9741357-7.html Feds use key logger to thwart PGP, Hushmail July 10, 2007 4:45 AM PDT A recent court case provides a rare glimpse into how some federal agents deal with encryption: by breaking into a suspect's home or office, implanting keystroke-logging software, and spying on what happens from afar. An agent with the Drug Enforcement Administration persuaded a federal judge to authorize him to sneak into an Escondido, Calif., office believed to be a front for manufacturing the drug MDMA, or Ecstasy. The DEA received permission to copy the hard drives' contents and inject a keystroke logger into the computers. That was necessary, according to DEA Agent Greg Coffey, because the suspects were using PGP and the encrypted Web e-mail service Hushmail.com. Coffey asserted that the DEA needed "real-time and meaningful access" to "monitor the keystrokes" for PGP and Hushmail passphrases. [...] _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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: [cryptography] OTR and deniability
by Ian G 06 Jul '18

06 Jul '18

On 19/07/11 1:59 PM, James A. Donald wrote: > On 2011-07-19 9:48 AM, Ian G wrote: >> OTR makes the same error. It takes a very interesting mathematical >> property, and extend it into the hard human world, as if the words carry >> the same meaning. Perhaps, once upon a time, in some TV court room >> drama, someone got away with lying about a document? From this, OTR >> suggests that mathematics can help you deny a transcript? It can't. It >> can certainly muddy the waters, it can certainly give you enough rope to >> hang yourself, but what it can't do is give some veneer of "it didn't >> happen." Not in court, not in the hard world of humans. > > OTR gives you the same deniability as a plaintext communicated person to > person. "He said ... she said" (I suspect a confusion here. A plaintext is a document, whereas "he said, she said" is witnessed or hearsay. They have wildly different effects in court, under interrogation.) > No more, and no less. > > But that is quite a lot of deniability. Actually, I suspect not. I humbly submit to the court that a plaintext document plus the presence of OTR is somewhat less deniable than a plaintext document by itself, which are both less deniable than a non-existing document. Perhaps we could lump this under the law of unexpected consequences? Part of the problem I have semantically with OTR is that it isn't OTR. The presence of a record means it is on the record. While OTR-the-product might be attempting to decrease the tamper-resistance qualities of the document, there is manifestly a document. And such presence tends to outweigh in real life any advantage gained by tampering. If it was truly OTR, it would turn off the record. That's what it means, the tape stops rolling, the typist stops typing. Probably we can't achieve precisly that, within the context of p2p communications without TCBs. But we can come close. There are possibilities: Counterparties can contract to delete the record afterwards, exposing themselves to civil claims if this is not done. Further, it might be possible to make declarations under penalties of perjury that the record has been deleted. Or, we could IPR it, or even invoke DMCA over it, and have the OTR application do the deed under a technological protection. I'm not suggesting that this be done; just that it seems to be evident that OTR doesn't take much in the way of steps to take something "off the record." What it does achieve, IMHO, is make it easier for a court to rule against a false repudiation. This is hard to see as an advantage to the users, who might be tempted to talk as if they can later deny the conversation. E.g., wikipedia, that notably deniable authority, says: "The primary motivation behind the protocol was providing deniability for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing." http://en.wikipedia.org/wiki/Off-the-Record_Messaging iang, the other other one _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
by bear 06 Jul '18

06 Jul '18

On Fri, 10 Sep 2004, Eugen Leitl wrote: >From: Joe Touch <touch(a)ISI.EDU> >>To clarify, this is not really "anonymous" in the usual sense. > >It does not authenticate the endpoint's identification, other than "same >place I had been talking to." > That's pseudonymity, not anonymity. >There's no difference between having no "name" and having a name you >cannot trust. I.e., I could travel under the name "anonymous" or "", or >under the name "A. Smith". If you don't know whether I am actually A. >Smith, the latter is identical to the former. This is just plain not true. When operating under a pseudonym, you are making linkable acts - linkable to each other even if not necessarily linkable to your own official identity. Anonymous actions or communications are those which cannot be linked to any other no matter how hard someone tries. We can expect the public to fail to grasp the distinction, but on this list "anonymous" is a very strong claim. Anonymity is *HARD* to do, not something that results from failing to check a credential. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

[Politech] DEA key logger used to eavesdrop in real time on alleged drug manufacturers [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

I've posted excerpts from the DEA PDFs at the link below and could post the PDFs themselves if there's sufficient interest. Previous Politech message, from way back in December 2000: http://www.politechbot.com/p-01545.html -Declan ---- http://news.com.com/8301-10784_3-9741357-7.html Feds use key logger to thwart PGP, Hushmail July 10, 2007 4:45 AM PDT A recent court case provides a rare glimpse into how some federal agents deal with encryption: by breaking into a suspect's home or office, implanting keystroke-logging software, and spying on what happens from afar. An agent with the Drug Enforcement Administration persuaded a federal judge to authorize him to sneak into an Escondido, Calif., office believed to be a front for manufacturing the drug MDMA, or Ecstasy. The DEA received permission to copy the hard drives' contents and inject a keystroke logger into the computers. That was necessary, according to DEA Agent Greg Coffey, because the suspects were using PGP and the encrypted Web e-mail service Hushmail.com. Coffey asserted that the DEA needed "real-time and meaningful access" to "monitor the keystrokes" for PGP and Hushmail passphrases. [...] _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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: [cryptography] OTR and deniability
by Ian G 06 Jul '18

06 Jul '18

On 19/07/11 1:59 PM, James A. Donald wrote: > On 2011-07-19 9:48 AM, Ian G wrote: >> OTR makes the same error. It takes a very interesting mathematical >> property, and extend it into the hard human world, as if the words carry >> the same meaning. Perhaps, once upon a time, in some TV court room >> drama, someone got away with lying about a document? From this, OTR >> suggests that mathematics can help you deny a transcript? It can't. It >> can certainly muddy the waters, it can certainly give you enough rope to >> hang yourself, but what it can't do is give some veneer of "it didn't >> happen." Not in court, not in the hard world of humans. > > OTR gives you the same deniability as a plaintext communicated person to > person. "He said ... she said" (I suspect a confusion here. A plaintext is a document, whereas "he said, she said" is witnessed or hearsay. They have wildly different effects in court, under interrogation.) > No more, and no less. > > But that is quite a lot of deniability. Actually, I suspect not. I humbly submit to the court that a plaintext document plus the presence of OTR is somewhat less deniable than a plaintext document by itself, which are both less deniable than a non-existing document. Perhaps we could lump this under the law of unexpected consequences? Part of the problem I have semantically with OTR is that it isn't OTR. The presence of a record means it is on the record. While OTR-the-product might be attempting to decrease the tamper-resistance qualities of the document, there is manifestly a document. And such presence tends to outweigh in real life any advantage gained by tampering. If it was truly OTR, it would turn off the record. That's what it means, the tape stops rolling, the typist stops typing. Probably we can't achieve precisly that, within the context of p2p communications without TCBs. But we can come close. There are possibilities: Counterparties can contract to delete the record afterwards, exposing themselves to civil claims if this is not done. Further, it might be possible to make declarations under penalties of perjury that the record has been deleted. Or, we could IPR it, or even invoke DMCA over it, and have the OTR application do the deed under a technological protection. I'm not suggesting that this be done; just that it seems to be evident that OTR doesn't take much in the way of steps to take something "off the record." What it does achieve, IMHO, is make it easier for a court to rule against a false repudiation. This is hard to see as an advantage to the users, who might be tempted to talk as if they can later deny the conversation. E.g., wikipedia, that notably deniable authority, says: "The primary motivation behind the protocol was providing deniability for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing." http://en.wikipedia.org/wiki/Off-the-Record_Messaging iang, the other other one _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[drone-list] Drone Summit: Why the FAA Should Regulate Drones
by Amie Stepanovich 06 Jul '18

06 Jul '18

I wanted to share with you all my speech at the Drone Summit last weekend. Here I explain why I believe that the FAA should regulate drones in the United States in order to protect privacy. I also highly recommend the other 3 speakers on my panel - Tom Barry, Jay Stanley, and Trevor Timm (you can select from the "latest videos" along the bottom of the screen). http://www.livestream.com/codepink/video?clipId=pla_868efa49-808b-46b7-83e4… Amie Stepanovich Associate Litigation Counsel Electronic Privacy Information Center 202.483.1140 x104 @astepanovich Defend Privacy. Support EPIC. http://www.epic.org/donate/ _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list 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. ----- 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

[RRE]Your Face Is Not a Bar Code
by Phil Agre 06 Jul '18

06 Jul '18

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). You are welcome to send the message along to others but please do not use the "redirect" option. For information about RRE, including instructions for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Your Face Is Not a Bar Code: Arguments Against Automatic Face Recognition in Public Places Phil Agre http://dlis.gseis.ucla.edu/pagre/ Version of 7 September 2001. 2600 words. Copyright 2001 by Phil Agre. You are welcome to forward this article in electronic form to anyone for any noncommercial reason. Please do not post it on any Web sites; instead, link to it here: http://dlis.gseis.ucla.edu/people/pagre/bar-code.html Given a digital image of a person's face, face recognition software matches it against a database of other images. If any of the stored images matches closely enough, the system reports the sighting to its owner. Research on automatic face recognition has been around for decades, but accelerated in the 1990s. Now it is becoming practical, and face recognition systems are being deployed on a large scale. Some applications of automatic face recognition systems are relatively unobjectionable. Many facilities have good reasons to authenticate everyone who walks in the door, for example to regulate access to weapons, money, criminal evidence, nuclear materials, or biohazards. When a citizen has been arrested for probable cause, it is reasonable for the police to use automatic face recognition to match a mug shot of the individual against a database of mug shots of people who have been arrested previously. These uses of the technology should be publicly justified, and audits should ensure that the technology is being used only for proper purposes. Face recognition systems in public places, however, are a matter for serious concern. The issue recently came to broad public attention when it emerged that fans attending the Super Bowl had unknowingly been matched against a database of alleged criminals, and when the city of Tampa deployed a face-recognition system in the nightlife district of Ybor City. But current and proposed uses of face recognition are much more widespread, as the resources at the end of this article demonstrate in detail. The time to consider the acceptability of face recognition in public places is now, before the practice becomes entrenched and people start getting hurt. Nor is the problem limited to the scattered cases that have been reported thus far. As the underlying information and communication technologies (digital cameras, image databases, processing power, and data communications) become radically cheaper over the next two decades, face recognition will become dramatically cheaper as well, even without assuming major advances in technologies such as image processing that are specific to recognizing faces. Legal constraints on the practice in the United States are minimal. (In Europe the data protection laws will apply, providing at least some basic rights of notice and correction.) Databases of identified facial images already exist in large numbers (driver's license and employee ID records, for example), and new facial-image databases will not be hard to construct, with or without the knowledge or consent of the people whose faces are captured. (The images need to be captured under controlled conditions, but most citizens enter controlled, video-monitored spaces such as shops and offices on a regular basis.) It is nearly certain, therefore, that automatic face recognition will grow explosively and become pervasive unless action is taken now. I believe that automatic face recognition in public places, including commercial spaces such as shopping malls that are open to the public, should be outlawed. The dangers outweigh the benefits. The necessary laws will not be passed, however, without overwhelming pressure of public opinion and organizing. To that end, this article presents the arguments against automatic face recognition in public places, followed by responses to the most common arguments in favor. Arguments against automatic face recognition in public places * The potential for abuse is astronomical. Pervasive automatic face recognition could be used to track individuals wherever they go. Systems operated by different organizations could easily be networked to cooperate in tracking an individual from place to place, whether they know the person's identity or not, and they can share whatever identities they do know. This tracking information could be used for many purposes. At one end of the spectrum, the information could be leaked to criminals who want to understand a prospective victim's travel patterns. Information routinely leaks from databases of all sorts, and there is no reason to believe that tracking databases will be any different. But even more insidiously, tracking information can be used to exert social control. Individuals will be less likely to contemplate public activities that offend powerful interests if they know that their identity will be captured and relayed to anyone that wants to know. * The information from face recognition systems is easily combined with information from other technologies. Industry often refers to face recognition as "facial recognition" because they regard faces as one modality of identification among many. Among the many "biometric" identification technologies, face recognition requires the least cooperation from the individual. Automatic fingerprint reading, by contrast, requires an individual to press a finger against a machine. (It will eventually be possible to identify people by the DNA-bearing cells that they leave behind, but that technology is a long way from becoming ubiquitous.) Organizations that have good reasons to identify individuals should employ whatever technology has the least inherent potential for abuse, yet very few identification technologies have more potential for abuse than face recognition. Information from face recognition systems is also easily combined with so-called location technologies such as E-911 location tracking in cell phones, thus further adding to the danger of abuse. * The technology is hardly foolproof. Among the potential downsides are false positives, for example that so-and-so was "seen" on a street frequented by drug dealers. Such a report will create "facts" that the individual must explain away. Yet the conditions for image capture and recognition in most public places are far from ideal. Shadows, occlusions, reflections, and multiple uncontrolled light sources all increase the risk of false positives. As the database of facial images grows bigger, the chances of a false match to one of those images grows proportionally larger. * Many social institutions depend on the difficulty of putting names to faces without human intervention. If people could be identified just from looking in a shop window or eating in a restaurant, it would be a tremendous change in our society's conception of the human person. People would find strangers addressing them by name. Prospective customers walking into a shop could find that their credit reports and other relevant information had already been pulled up and displayed for the sales staff before they even inquire about the goods. Even aside from the privacy invasion that this represents, premature disclosure of this sort of information could affect the customer's bargaining position. * The public is poorly informed about the capabilities of the cameras that are already ubiquitous in many countries. They usually do not realize, for example, what can be done with the infrared component of the captured images. Even the phrase "face recognition" does not convey how easily the system can extract facial expressions. It is not just "identity" that can be captured, then, but data that reaches into the person's psyche. Even if the public is adequately informed about the capabilities of this year's cameras, software and data sharing can be improved almost invisibly next year. * It is very hard to provide effective notice of the presence and capabilities of cameras in most public places, much less obtain meaningful consent. Travel through many public places, for example government offices and centralized transportation facilities, is hardly a matter of choice for any individual wishing to live in the modern world. Even in the private sector, many retail industries (groceries, for example) are highly concentrated, so that consumers have little choice but to submit to the dominant company's surveillance practices. * If face recognition technologies are pioneered in countries where civil liberties are relatively strong, it becomes more likely that they will also be deployed in countries where civil liberties hardly exist. In twenty years, at current rates of progress, it will be feasible for the Chinese government to use face recognition to track the public movements of everyone in the country. Responses to arguments in favor of automatic face recognition in public places * "All of the people in our database are wanted criminals. We don't store any of the images that our cameras capture, except when they match an image in the database. So the only people who have any cause for complaint are criminals." The problems with this argument are numerous: (1) We have to trust your word that the only people whose images are stored in the database are wanted criminals, and we have to trust your word that you throw away all of the images that fail to match the database. (2) You don't really know yourself whether all of the people in the database are criminals. Quality control on those databases is far from perfect, as the database of "felons" that was used to purge some Florida counties' electoral rolls in 2000 demonstrated. (3) Even if the only people in the database today are criminals, the forces pushing us down a slippery slope of every-expanding databases are nearly overwhelming. Once the system is established and working, why not add people with criminal records who have served their time? Then we could add alleged troublemakers who have been ejected from businesses in the past but have never been convicted of crimes, people who have been convicted of minor offenses such as shoplifting, people with court orders to stay away from certain places, missing persons, children whose parents are worried about them, elders whose children are worried about them, employees of the business where the system is operating, and other individuals who have signed contracts agreeing to be tracked. And once those people are added, it is then a short step to add many other categories of people as well. * "Public is public. If someone happens to notice you walking in the park, you have no grounds for complaint if they decide to tell someone else where you were. That's all we're doing. You don't have any reasonable expectation of privacy in a public place, and I have a free-speech right to communicate factual information about where you were." A human being who spots me in the park has the accountability that someone can spot them as well. Cameras are much more anonymous and easy to hide. More important is the question of scale. Most people understand the moral difference between a single chance observation in a park and an investigator who follows you everywhere you go. The information collected in the second case is obviously more dangerous. What is more, custom and law have always recognized many kinds of privacy in public. For example, the press cannot publish pictures of most people in personally sensitive situations that have no legitimate news value. It is considered impolite to listen in on conversations in public. Pervasive face recognition clearly lies at the morally most problematic end of this spectrum. The chance of being spotted is different from the certainty of being tracked. The phrase "reasonable expectation of privacy" comes from a US Supreme Court decision. The phrase has been widely criticized as useless, since reason that reasonable expectations of privacy in a situation can disappear as soon as someone starts routinely invading privacy in that situation. The problem is an often-exploited ambiguity in the word "expectation", which can mean either a prediction (with no logical implication that the world morally *ought* to hold conform to it) or a norm (with no logical implication that the world actually *will* conform to it). In arguing in favor of a ban on automatic face recognition in public places, one is not arguing for a blanket "right of privacy in public", which would be unreasonable and impractical. Rather, one is arguing for a right against technologically mediated privacy invasions of certain types. Technological mediation is key because of its continuous operation, standardized results, lack of other legitimate purposes, and rapidly dropping costs. The argument about free speech rights is spurious because the proposed ban is not on the transfer of information, but on the creation of certain kinds of electronic records. You still have the right to communicate the same information if you acquire it in other ways. * "Automatic face recognition stops crime. Police say they want it. And if it prevents one child from being killed then I support it." A free society is a society in which there are limits on what the police can do. If we want to remain a free society then we need to make a decision. Once a new surveillance technology is installed, it is nearly impossible to stop the slippery slope toward ever broader law enforcement use of it. The case of automatic toll collection makes this clear. Absent clear legal protections, then, we should assume from the beginning that any technology that captures personal information will be used for law enforcement purposes, and not only in cases where lives are immediately at stake. The potential for abuse should then be figured into our decision about whether the technology should be deployed at all. That said, it is hardly proven that face recognition stops crime, when face recognition is being added to a world that already contains many other crime-fighting technologies. The range of crime detection technologies available to the police has grown immensely in recent years, and even if one encountered a case where a crime was solved using a given technology it by no means follows that the crime would not have been solved equally well using some other technology. * "Privacy prevents the marketplace from functioning efficiently. When a company knows more about you, it can tailor its offerings more specifically to your needs. Of course if you ask people whether scary face recognition systems should be banned then they'll say yes. But you're asking the wrong question. The right question is whether people are willing to give up information in exchange for something of value, and most people are." This is a non sequitur. Few proposals for privacy protection prevent people from voluntarily handing information about themselves to companies with which they wish to do business. The problem arises when information is transferred without the individual's knowledge, and in ways that might well cause upset or harm if they became known. What distinguishes automatic face recognition from many other equally good identification technologies is that it can be used without the individual's permission (and therefore without the individual having agreed to any exchange). That is why it should be banned. * "A preoccupation with privacy is corrosive. Democracy requires people to have public personae, and excessive secrecy is unhealthy." Privacy does not equal secrecy. Privacy means that an individual has reasonable control over what information is made public, and what is not. Any decent social order requires that individuals be entrusted with this judgement. Even if particular individuals choose to become secretive in a pathological way, forcing them to change will not help the situation and is intrinsincally wrong anyway. As to the value of public personae, we should encourage the development of technologies that give people the option to appear publicly where and how they want. * "What do you have to hide?" This line is used against nearly every attempt to protect personal privacy, and the response in each case is the same. People have lots of valid reasons, personal safety for example, to prevent particular others from knowing particular information about them. Democracy only works if groups can organize and develop their political strategies in seclusion from the government, and from any established interests they might be opposing. This includes, for example, the identities of people who might travel through public places to gather for a private political meeting. In its normal use, the question "What do you have to hide?" stigmatizes all personal autonomy as anti-social. As such it is an authoritarian demand, and has no place in a free society. For more responses to bad arguments against privacy, see: http://dlis.gseis.ucla.edu/people/pagre/arguments.html News articles with background on face recognition. Facial-Recognition System Gets Millions in Federal Funds http://www.siliconvalley.com/docs/news/svfront/016044.htm Facial ID Systems Raising Concerns About Privacy http://washingtonpost.com/wp-dyn/articles/A12629-2001Jul31.html Facial-Recognition Tech Has People Pegged http://www.cnn.com/2001/TECH/ptech/07/17/face.time.idg/ Face Scanners Turn Lens on Selves http://wired.com/news/privacy/0,1848,45687,00.html Face-Recognition Systems Offer New Tools, but Mixed Results http://www.biometricgroup.com/a_press/NYTimes_May_2001.htm How Facial Recognition Software Finds Faces http://abcnews.go.com/sections/scitech/CuttingEdge/cuttingedge010706.html Law Enforcement Agencies Working on 3D Face Recognition Technology http://asia.cnn.com/TECH/computing/9909/24/3d.face.recognition.idg/ Face-Recognition Technology Raises Fears of Big Brother http://www.deseretnews.com/dn/view/0%2C1249%2C150015975%2C00.html Seeking Clues to Recognition ... in Your Face http://seattletimes.nwsource.com/news/health-science/html98/face_20000111.h… Smile, You're On Scan Camera http://www.wired.com/news/technology/0,1282,42317,00.html Other sites with background information on face recognition technology and its potential for privacy invasion. Electronic Privacy Information Center Face Recognition Page http://www.epic.org/privacy/facerecognition/ Coalition Declares December 24, 2001 to Be "World Subjectrights Day" http://wearcam.org/wsd.htm Facial Recognition Vendor Test 2000 http://www.dodcounterdrug.com/facialrecognition/DLs/FRVT_2000.pdf http://www.dodcounterdrug.com/facialrecognition/FRVT2000/frvt2000.htm Selected Facial Scan Projects http://www.facial-scan.com/selected_facial_scan_projects1.htm US government site for biometric technology (including face recognition) http://www.biometrics.org/ Facing the Truth: A New Tool to Analyze Our Expressions http://www.hhmi.org/bulletin/may2001/faces/ Biometrics: Face Recognition Technology http://www.sans.org/infosecFAQ/authentic/face_rec.htm Automatic Face and Gesture Recognition, Washington, 20-21 May 2002 http://degas.umiacs.umd.edu/pirl/fg2002/ the two dominant face recognition companies http://www.visionics.com/faceit/ http://www.viisage.com/ other companies http://www.visionspheretech.com/menu.htm http://www.symtrontech.com/ http://www.cognitec-ag.de/ http://www.c-vis.com/htdocs/english/facesnap/ http://www.neurodynamics.com/ http://www.imagistechnologies.com/ http://www.spiritcorp.com/face_rec.html http://www.bio4.co.uk/ http://www.bioid.com/ http://www.miros.com/solutions/face.htm http://www.keyware.com/ http://www.bionetrix.com/ Web pages about technical research projects on face recognition. directory of face recognition research http://www.cs.rug.nl/~peterkr/FACE/face.html Face Recognition and Detection http://home.t-online.de/home/Robert.Frischholz/face.htm DoD Counterdrug Program Face Recognition Technology Program http://www.dodcounterdrug.com/facialrecognition/Feret/feret.htm http://www.itl.nist.gov/iad/humanid/feret/feret_master.html Wearable Face Recognition and Detection http://www.gvu.gatech.edu/ccg/projects/face/ Identification of Faces From Video http://staff.psy.gla.ac.uk/~mike/videoproj.html Evaluation of Face Recognition Algorithms http://www.cs.colostate.edu/evalfacerec/ slides from an MIT course on human and artificial face recognition http://web.mit.edu/9.670/www/ Gesture Recognition Home Page (related technology) http://www.cybernet.com/~ccohen/ Articles about face-recognition controversies in various places, roughly in reverse chronological order. Borders stores first Borders says it "suspended any plans to implement" face recognition ... http://www.computerworld.com/storyba/0,4125,NAV47_STO63359,00.html ... then it denies that it ever had any such intention http://www.politechbot.com/p-02447.html Borders is planning to use face recognition to identify shop-lifters http://www.sundayherald.com/18007/ casinos Smart Cameras at Casinos Spark a Debate on Privacy http://www.uniontrib.com/news/metro/20010717-9999_1n17cameras.html Privacy Commissioner Reassures Public That Casinos Are Not Scanning All Patrons http://www.ipc.on.ca/english/whatsnew/newsrel/casino01.htm OPP uses secret cameras in casinos ("police are secretly scanning the faces of customers at all Ontario casinos") http://www.efc.ca/pages/media/2001/2001-01-16-a-torontostar.html Global Cash Access Signs New Contracts With 20 Gaming Properties (face-recognizing ATM machines in casinos) http://biz.yahoo.com/bw/010823/232101_3.html Smile! You're on Casino Camera http://wbbm.cbsnow.com/now/story/0,1597,274604-240,00.shtml Virginia Beach, Virginia Technology Helps Authorities Keep a Constant Eye on Public http://www.pilotonline.com/news/nw0827cam.html Beach May Scan Oceanfront Faces http://www.pilotonline.com/news/nw0706fac.html Huntington Beach, California Imagis and ORION Chosen to Install Biometrics by Huntington Beach Police http://cipherwar.com/news/01/imagis_big_brother.htm Jacksonville, Florida Police Snooper Camera Fight Still Alive http://www.jacksonville.com/tu-online/stories/083101/met_7161286.html Florida City Moves to Ban Face-Recognition System http://www.usatoday.com/life/cyber/tech/fcw2.htm Pinellas County, Florida Face Recognition System Will Be Used by Florida Sheriff's Office http://www.friendsofliberty.com/files/2001/07/27/02.htm Britain Think Tank Urges Face-Scanning of the Masses http://www.theregister.co.uk/content/6/20966.html face recognition technology in the UK http://www.urban75.com/Action/cctv.html http://www.sourceuk.net/articles/a00624.html Newham Council Launches "Face Recognition" in the UK http://www.newham.gov.uk/press/julythrunov98/facereg.html Joyrider, 14, Is First Tagging Guinea Pig http://www.thetimes.co.uk/article/0,,2-2001242628,00.html Colorado Colorado Governor Doesn't Want Face Recognition Technology Abused http://www.thedenverchannel.com/den/entertainment/stories/technology-8 7985620010719-070716.html Colorado Won't Use Facial Recognition Technology on Licenses http://www.thedenverchannel.com/den/entertainment/stories/technology-8 6955020010712-110740.html Colorado To Use Face Recognition Photos To Stop ID Theft http://www.newsbytes.com/news/01/167655.html Colorado to "Map" Faces of Drivers http://www.denverpost.com/Stories/0,1002,11%257E57823,00.html Minnesota Minnesota Adopts Visionics' FaceIt for Integrated Mug Shot Database System http://biz.yahoo.com/bw/010814/142123.html Super Bowl Face Scans Match Few Suspects http://www.sptimes.com/News/021601/TampaBay/Face_scans_match_few_.shtml ACLU Protests High-Tech Super Bowl Surveillance http://www.usatoday.com/life/cyber/tech/2001-02-02-super-bowl-surveillance.… Super Bowl Surveillance: Facing Up to Biometrics http://www.rand.org/publications/IP/IP209/IP209.pdf Feds Use Biometrics Against Super Bowl Fans http://www.theregister.co.uk/content/6/16561.html Cameras Scanned Fans for Criminals http://www.sptimes.com/News/013101/TampaBay/Cameras_scanned_fans_.shtml Tampa, Florida Facial Frisking in Tampa http://www.privacyfoundation.org/commentary/tipsheet.asp?id=46&action=0 complete directory of Tampa news articles through early August from the ACLU http://www.gate.net/~rwms/aclutampacam.html "Big Brother" Cameras on Watch for Criminals http://www.usatoday.com/life/cyber/tech/2001-08-02-big-brother-cameras.htm "They made me feel like a criminal" http://www.sptimes.com/News/080801/TampaBay/_They_made_me_feel_li.shtml Tampa Face-Recognition Vote Rattles Privacy Group http://www.newsbytes.com/news/01/168677.html Civil Rights or Just Sour Grapes? http://www.sptimes.com/News/080301/TampaBay/Civil_rights_or_just_.shtml Tampa City Council meeting which voted to keep the face recognition cameras http://www.ci.tampa.fl.us/appl_Cable_Communications_closed_captioning/ frmAgenda.asp Click. BEEP! Face Captured http://www.sptimes.com/News/071901/Floridian/Click_BEEP_Face_captu.shtml Tampa Gets Ready For Its Closeup http://www.time.com/time/nation/article/0,8599,167846,00.html Masked Protesters Fight Face Scans http://www.sptimes.com/News/071501/TampaBay/Masked_protesters_fig.shtml Tampa Puts Face-Recognition System on Public Street http://www.usatoday.com/life/cyber/tech/2001-07-13-tampa-surveillance.htm Congressional Leader Calls for Action on Ybor City Surveillance (Ybor City is a busy nightlife neighborhood of Tampa) http://www.wtsp.com/news/2001_07/12_ybor_cameras.htm ACLU Probes Police Use of Facial-Recognition Cameras in Florida City http://www.aclu.org/news/2001/n070601a.html http://freedom.house.gov/library/technology/aclu.asp Tampa Scans the Faces in Its Crowds for Criminals http://www.nytimes.com/2001/07/04/technology/04VIDE.html public radio report about the controversy http://www.npr.org/ramfiles/atc/20010702.atc.14.rmm Ybor Police Cameras Go Spy-Tech http://www.sptimes.com/News/063001/TampaBay/Ybor_police_cameras_g.shtml end ************************************************************************** Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: freematt(a)coil.com with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per week) Matthew Gaylor, (614) 313-5722 ICQ: 106212065 Archived at http://groups.yahoo.com/group/fa/ **************************************************************************

1 0

tour vegas
by Prinz Harvey L 06 Jul '18

06 Jul '18

1 0