July 2018 - cypherpunks-legacy

RE: A liitle late but I just saw this...
by Joe St Sauver 06 Jul '18

06 Jul '18

Hi, I happened to see your recent posting, and since I'm interested in the cyberwar issue (including having served as co-chair of the DOE "Human Factors" breakout group charged with considering cyberwar and cyber terrorism for the DOE Cyber Security Research Needs for Open Science meeting, see session 4 of http://cybersecurity.colostate.edu/ panels/ ). With that for context... I'm not sure folks fully understand how strategic cyberwar might/will actually be waged. In my opinion, cyberwar will not rely primarily on malware-based attacks. :-; That process is too uncertain, too slow, too-readily thwarted and would have insufficient penetration or coverage. So how might cyberwar happen? Let me give you three examples: 1) We are already experiencing a sort of cyberwar, although because it began gradually, and has become a chronic phenomenon, no one acknowledges the negative impact and damage it continually causes to our economy -- and that is spam. What a perfect attack eh? How much time is wasted filtering and deleting spam? How many business-critical messages get blocked or overlooked? How many resources are diverted from other potentially productive uses? What a great way of promoting illegal use of controlled substances, too, thereby helping to subvert the nation's war on drugs. And yet, because this is an attack of a trillion mosquitos rather than a frontal attack by a roaring bear, we don't even acknowledge it as an attack, and there's no way to definitively tie this attack to a hostile government -- absolute deniability! 2) Tactical cyberwar would certainly include attacks against control systems; if you're interested you can see my take on this issue at http://www.uoregon.edu/~joe/scadaig/infraguard-scada.ppt (or .pdf) 3) Full-blown strategic cyberwar, worst case, would involve things like high altitude electromagnetic pulse-induced damage to terrestrial networks and power distribution grids, while simultaneously degrading or destroying non-radiation-hardened satellites aloft. If you're interested, please also feel free to see my talk, "Planning for Certain High Risk Security Incidents," http://www.uoregon.edu/~joe/highrisk/high-risk.ppt (or .pdf) from the fall 2007 Internet2 Member Meeting in San Diego, where I urge adoption of a program of hardening critical assets to resist H-EMP. Feel free to drop me a note if you have any questions, Regards, Joe St Sauver, Ph.D. (joe(a)oregon.uoregon.edu) http://www.uoregon.edu/~joe/ ------------------------------------------- Archives: http://v2.listbox.com/member/archive/247/=now RSS Feed: http://v2.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com ----- 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

[Dewayne-Net] re: Enemies at The Firewall
by dewayne＠warpspeed.com 06 Jul '18

06 Jul '18

[Note: This comment comes from reader Joe St. Sauver. DLH]

1 0

[IP] Re: Enemies at The Firewall
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

None
by None 06 Jul '18

06 Jul '18

<HTML>=0D=0A<HEAD>=0D=0A<META=20NAME=3D"GENERATOR"Content=3D"">=0D=0A<TITLE= >Untitled</TITLE>=0D=0A</HEAD>=0D=0A<BODY=20text=3D#000000=20vLink=3D#80008= 0=20aLink=3D#ff0000=20link=3D#ff0000=20bgProperties=3Dfixed=20=0D=0AbgColor= =3D#ffffff=20background=3D"">=0D=0A<A=20href=3D"http://www.forexvoice.co= m"><IMG=20alt=3D""=20hspace=3D0=20=0D=0Asrc=3D"http://www.forexvoice.com/lo= go2sm.jpg"=20align=3Dbaseline=20border=3D0></A>=0D=0A<FONT= =20face=3DVerdana=20size=3D1>Forexvoice=20Squawk=20Box=20=0D=0ADelivers=20L= ive=20Audio=20Forex=20Rates=20Direct=20to=20Your=20PC=2024=20hrs=20a=20=0D= =0ADay=20=20=20=20=20=20=20=20=20=0D=0A=0D=0A<A=20hr= ef=3D"http://www.forexvoice.com"><IMG=20alt=3D""=20hspace=3D0=20=0D=0Asrc= =3D"http://www.forexvoice.com/squawk.jpg"=20align=3Dbaseline=20border=3D0><= /A>=0D=0A =0D=0A<P=20class=3DMsoNormal><SPAN=20lang=3DEN-GB= ><A=20=0D=0Ahref=3D"http://www.forexvoice.com/"><FONT=20=0D=0Asize=3D1>http= ://www.forexvoice.com</A>=0D=0A<P=20class=3DMsoNormal><SP= AN=20lang=3DEN-GB><A=20href=3D"mailto:sales@forexvoice.com"><FONT=20=0D=0Ac= olor=3D#0000ff=20size=3D1>sales(a)forexvoice.com</A><SPAN=20=0D=0Astyl= e=3D"mso-spacerun:=20yes"><FONT=20size=3D1> =20=0D=0A=20= =0D=0A<P=20class=3DMsoNormal><SPAN=20lang=3DEN-GB><o:p></O:P><FO= NT=20=0D=0Asize=3D1>=0D=0A<SPAN=20lang=3DEN-GB=20=0D= =0Astyle=3D"FONT-SIZE:=2012pt;=20FONT-FAMILY:=20'Times=20New=20Roman';=20ms= o-fareast-font-family:=20'Times=20New=20Roman';=20mso-ansi-language:=20EN-G= B;=20mso-fareast-language:=20EN-US;=20mso-bidi-language:=20AR-SA"><FONT=20s= ize=3D1>This=20=0D=0Amessage=20and=20any=20attachment=20are=20confidential= =20and=20may=20be=20privileged=20=0D=0Aor otherwise=20protected=20from= =20disclosure. =20If=20you=20are=20not=20the=20intended=20=0D=0Arecipi= ent, please=20telephone=20or=20email=20the=20sender=20and=20delete=20thi= s=20message=20and=20=0D=0Aany attachment=20from=20your=20system. = =20If=20you=20are=20not=20the=20intended=20recipient=20=0D=0Ayou=20must = not=20copy=20this=20message=20or=20attachment=20or=20disclose=20the=20conte= nts=20to=20any=20=0D=0Aother person.=0D=0A</BODY></HTM= L> ------=_NextPart_000_0005_01C06B5E.74675200 Content-Type: text/plain Forexvoice Squawk Box Delivers Live Audio Forex Rates Direct to Your PC 24 hrs a Day http://www.forexvoice.comsales@forexvoice.com This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person. ------=_NextPart_000_0005_01C06B5E.74675200 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <HTML>=0D=0A<HEAD>=0D=0A<META=20NAME=3D"GENERATOR"Content=3D"">=0D=0A<TITLE= >Untitled</TITLE>=0D=0A</HEAD>=0D=0A<BODY=20text=3D#000000=20vLink=3D#80008= 0=20aLink=3D#ff0000=20link=3D#ff0000=20bgProperties=3Dfixed=20=0D=0AbgColor= =3D#ffffff=20background=3D"">=0D=0A<A=20href=3D"http://www.forexvoice.co= m"><IMG=20alt=3D""=20hspace=3D0=20=0D=0Asrc=3D"http://www.forexvoice.com/lo= go2sm.jpg"=20align=3Dbaseline=20border=3D0></A>=0D=0A<FONT= =20face=3DVerdana=20size=3D1>Forexvoice=20Squawk=20Box=20=0D=0ADelivers=20L= ive=20Audio=20Forex=20Rates=20Direct=20to=20Your=20PC=2024=20hrs=20a=20=0D= =0ADay=20=20=20=20=20=20=20=20=20=0D=0A=0D=0A<A=20hr= ef=3D"http://www.forexvoice.com"><IMG=20alt=3D""=20hspace=3D0=20=0D=0Asrc= =3D"http://www.forexvoice.com/squawk.jpg"=20align=3Dbaseline=20border=3D0><= /A>=0D=0A =0D=0A<P=20class=3DMsoNormal><SPAN=20lang=3DEN-GB= ><A=20=0D=0Ahref=3D"http://www.forexvoice.com/"><FONT=20=0D=0Asize=3D1>http= ://www.forexvoice.com</A>=0D=0A<P=20class=3DMsoNormal><SP= AN=20lang=3DEN-GB><A=20href=3D"mailto:sales@forexvoice.com"><FONT=20=0D=0Ac= olor=3D#0000ff=20size=3D1>sales(a)forexvoice.com</A><SPAN=20=0D=0Astyl= e=3D"mso-spacerun:=20yes"><FONT=20size=3D1> =20=0D=0A=20= =0D=0A<P=20class=3DMsoNormal><SPAN=20lang=3DEN-GB><o:p></O:P><FO= NT=20=0D=0Asize=3D1>=0D=0A<SPAN=20lang=3DEN-GB=20=0D= =0Astyle=3D"FONT-SIZE:=2012pt;=20FONT-FAMILY:=20'Times=20New=20Roman';=20ms= o-fareast-font-family:=20'Times=20New=20Roman';=20mso-ansi-language:=20EN-G= B;=20mso-fareast-language:=20EN-US;=20mso-bidi-language:=20AR-SA"><FONT=20s= ize=3D1>This=20=0D=0Amessage=20and=20any=20attachment=20are=20confidential= =20and=20may=20be=20privileged=20=0D=0Aor otherwise=20protected=20from= =20disclosure. =20If=20you=20are=20not=20the=20intended=20=0D=0Arecipi= ent, please=20telephone=20or=20email=20the=20sender=20and=20delete=20thi= s=20message=20and=20=0D=0Aany attachment=20from=20your=20system. = =20If=20you=20are=20not=20the=20intended=20recipient=20=0D=0Ayou=20must = not=20copy=20this=20message=20or=20attachment=20or=20disclose=20the=20conte= nts=20to=20any=20=0D=0Aother person.=0D=0A</BODY></HTM= L> ------=_NextPart_000_0005_01C06B5E.74675200-- ------=_NextPart_000_0004_01C06B5E.74675200--

1 0

REAL ID: A few brief comments on the requirements
by Richard Forno 06 Jul '18

06 Jul '18

After skimming through the REAL ID document just-released, here are a few comments. Source document: http://www.dhs.gov/xlibrary/assets/nprm_realid.pdf >As discussed below and in section II.E.6 of the NPRM, the recommended >architecture for implementing these data exchanges does not create >a national >database, because it leaves the decision of how to conduct the >exchanges in >the hands of the States. Moreover, no Federal agency will operate >the data >exchanges affecting non-commercial driverbs licensing. Translation: "REAL ID will not reside in a single database, but rather in a collaborative (clustered) environment, with each state's database constituting one portion of that environment (cluster.) And it's not a 'national' or 'federal' database because no Federal agency will operate it." Splitting hairs here, aren't we? A rose by any other name...... >DHS believes that protecting the privacy of the personal information >associated with implementation of the REAL ID Act is critical to >maintaining >the public trust that Government can provide basic services to its >citizens >while preserving their privacy. Then to solidify the trust we're being asked to place in our government, DHS could start by calling this what it really is when you look past its wrappings and bureaucratic mumbo-jumbo: a National ID Card. >Further, in almost all cases there is no way to verify >independently from >documents presented that an address is a personbs principal >address. A >mortgage statement or lease may indicate that a person owns or >rents property >in a particular place, and while the landlord or bank holding the >mortgage >could verify this, it does not establish that this is the personbs >principal >residence, just that the ownership or rental is legitimate. In >addition, the >cost to States of verifying a multitude of documents presented to >establish >address, such as utility bills, leases, mortgages, or other >documents, is >potentially significant. In spite of these limitations, there is a >need for >some reliability in the information presented for principal >residence, as >evidenced by the experience of the 9/11 hijackers and how they >obtained >Virginia driverbs licenses (see section II.D.3). Therefore, DHS is 49 >proposing that the States require each applicant to present at >least two >documents that include his or her name and current principal >residence. >However, the States will retain the flexibility to determine for >themselves >precisely which documents, or combination of documents, an >applicant must >present to satisfy this requirement and how a State will validate >or verify >this information. The proposed regulation would require States to >establish a >written policy identifying acceptable documents and how, or if, >they will be >independently validated or verified. The proposal would also >require that >States provide this information to DHS as part of their initial >certification >package and whenever this Translation: "While it's really difficult, if not impossible, to verify independently someone's domicile address, it's important to ensure accurate location information on subjects listed in this new National ID database to prevent another 9/11 from happening. But because it's such a hard requirement to get our hands around -- Americans are just so darn free and mobile -- a utility bill or bank statement probably would be good enough....especially for government work." >The primary benefit of REAL ID is to improve the security and >lessen the >vulnerability of federal buildings, nuclear facilities, and >aircraft to >terrorist attack. Memo to DHS: Reinforced cockpit doors fixed the primary vulnerability responsible for 9/11 and were a long-overdue countermeasure. And exactly how many members of the American public and/or visiting tourists just 'drop by' a nuclear facility that you need to confirm their IDs before granting entry? Are you saying that this is the case, and I can walk right into my local nuclear power plant and see the atoms in action? If so, you've got much bigger problems to worry about than verifying my ID. >The potential ancillary benefits of REAL ID are numerous, as it >would be >more difficult to fraudulently obtain a legitimate license and >would be >substantially more costly to create a false license. These other >benefits >include reducing identity theft, unqualified driving, and fraudulent >activities facilitated by less secure driverbs licenses such as >fraudulent >access to government subsidies and welfare programs, illegal >immigration, >unlawful employment, unlawful access to firearms, voter fraud, and >possibly >underage drinking and smoking. DHS assumes that REAL ID would >bring about >changes on the margin that would potentially increase security and >reduce >illegal behavior. Because the 109 size of the economic costs that >REAL ID >serves to reduce on the margin are so large, however, a relatively >small >impact of REAL ID may lead to significant benefits. Let's not forget making it easier for identity theft to occur via a closed networked cluster of databases containing very private information and the likely ability (abuse) to use this de facto National ID card for marketing purposes or other purposes not even remotely-related to the primary benefits you cited earlier. And this beauty, which is, quite literally, the LAST paragraph of this 160+ page document: >(a) States that issue driverbs licenses and identification cards >that do not >satisfy the standards of this Part after May 11, 2008, must ensure >that such >driverbs licenses and identification cards-- (1) Clearly state, on >their face >in bold lettering, as well as in the machine readable zone if the card >contains one, that they may not be accepted by any Federal agency >for Federal >identification or other official purpose; and > >161 (2) Have a unique design or color indicator that clearly >distinguishes >them from driverbs licenses and identification cards that meet the >standards >of this Part. Meaning if you value your privacy and refuse to carry a REAL ID or if your state decides that REAL ID indeed is the cost-prohibitive sham for security that it is and decides to not play with DHS' desire to create a National ID card, its citizens will be branded with the post-9/11 version of the "Scarlett Letter" to let all who see their ID card know that they're "different" --- or at least not "one of the good guys." Stigmatized. Branded. Marked. Ostracized. Segregated. Will we have separate bathrooms, too? REAL ID *must* be stopped. For many reasons. -rf ------------------------------------------- Archives: http://v2.listbox.com/member/archive/247/@now Powered by Listbox: http://www.listbox.com ----- 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

[IP] REAL ID: A few brief comments on the requirements
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [p2p-hackers] P2P Authentication
by Kerry Bonin 06 Jul '18

06 Jul '18

Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do "anything" and still catch a user "doing something they're not supposed to", it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: >Matthew Kaufman wrote: > >>I think what you're asking here is "is it possible to design a p2p >>network >>such that the peers must be running the official code that does the >>right >>thing, instead of running some subverted code that does something >>'wrong'?" >> >> >Matthew, > >Very eloquently put. Yes, this is exactly what I was asking. >We supply the client as well as the server and we just need to make >sure that any client that joins the >network is our client and not a 'rogue'. > >>The one exception is that you *can* in some cases design the network >>such >>that peers that don't behave "properly" are shunned or dropped by the >>rest >>of the network, assuming that such behavior is detectable. For >>instance, in >>a distributed file store, you could store test data and see if it sticks >>around... If it doesn't, that peer is "cheating". >> >> >We have a way (we think) of authenticating the stream put out by a >peer, so we can catch a 'rogue' client this >way, but it seems more logical to prevent someone from logging into >the network in the first place. > >Thanks for your help, >Frank. >_______________________________________________ >p2p-hackers mailing list >p2p-hackers(a)zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

Re: [p2p-hackers] P2P Authentication
by Kerry Bonin 06 Jul '18

06 Jul '18

Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do "anything" and still catch a user "doing something they're not supposed to", it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: >Matthew Kaufman wrote: > >>I think what you're asking here is "is it possible to design a p2p >>network >>such that the peers must be running the official code that does the >>right >>thing, instead of running some subverted code that does something >>'wrong'?" >> >> >Matthew, > >Very eloquently put. Yes, this is exactly what I was asking. >We supply the client as well as the server and we just need to make >sure that any client that joins the >network is our client and not a 'rogue'. > >>The one exception is that you *can* in some cases design the network >>such >>that peers that don't behave "properly" are shunned or dropped by the >>rest >>of the network, assuming that such behavior is detectable. For >>instance, in >>a distributed file store, you could store test data and see if it sticks >>around... If it doesn't, that peer is "cheating". >> >> >We have a way (we think) of authenticating the stream put out by a >peer, so we can catch a 'rogue' client this >way, but it seems more logical to prevent someone from logging into >the network in the first place. > >Thanks for your help, >Frank. >_______________________________________________ >p2p-hackers mailing list >p2p-hackers(a)zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

Re: [ZS] Re: [FoRK] Reminder: ZSF launch event tomorrow! Please help spread the?word?if you can!
by Bryce Lynch 06 Jul '18

06 Jul '18

On Fri, Nov 16, 2012 at 11:20 AM, Dirk Bruere <dirk.bruere(a)gmail.com> wrote: > My biggest worry about BC is that at some point the algorithm will be > hacked and BC rendered worthless. > I keep looking at stuff like DWave quantum computers Whether or not DWave's products are true quantum computers is still a matter of debate due to the specifics of the architecture (quantum annealing != quantum-entangled bits). Secondly, if and when true quantum CPUs are developed, a lot bigger fish than Bitcoin are in line to be fried. Among them, the encrypted communication links used by global banks, multinational corporations, and large governments. Don't forget cracking the keys on pilfered encrypted data, either (you can bet your bottom $unit_of_currency that people want to find out what's really in the file wikileaks-insurance-20120222.tar.bz2.aes). Also, the Bitcoin protocol was designed so that the message digest and cryptographic algorithms could be swapped out if need be. There are at least six categories of algorithms at this time that would fit that particular bill, and no doubt more will spring up. -- The Doctor [412/724/301/703] [ZS (MED)] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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

[Freedombox-discuss] Half a bag of chocolate for the FreedomBox!
by Markus Sabadello 06 Jul '18

06 Jul '18

Hello, I have recently been to 2 conferences where I talked about the FreedomBox. * European Identity Conference (EIC): I was in a workshop about "Life Management Platforms", and I explained the FreedomBox concept to the audience. This was a very corporate kind of conference, but guess what, there was actually a lot of talk about decentralization! See my blog post here<http://blog.projectdanube.org/2012/04/freedombox-at-the-european-identity-c…> . * Internet Identity Workshop (IIW): I brought 4 Guruplugs and did a demo of what a FreedomBox COULD enable. See my blog post here<http://blog.projectdanube.org/2012/05/freedombox-at-the-internet-identity-w…> for a description and some screenshots of the demo. At IIW, it is customary that at the end of each day, participants award each other wine and chocolate for special achievements. And well, I got (half) a bag of chocolate for the FreedomBox demo. At the two events, I mentioned consistently that I am not speaking for FreedomBox "officially", but that I had been observing it for a while. I'd really love to get more closely involved, perhaps I could even make it to the June Hackfest (but it's a long and expensive flight, don't know). Specifically, I'd like to do the following: 1. Start a discussion on how the FreedomBox could fit into some communities I am in touch with, especially the Personal Data Ecosystem<http://personaldataecosystem.org/> (PDE) and Vendor Relationship Management<http://blogs.law.harvard.edu/vrm/> (VRM). PDE is about giving individuals control over their personal data. Uhm, it's also about new business opportunities, something like a "fair trade for data". VRM is about giving you the means to manage your relationships with the vendors/suppliers you deal with in your life. 2. On the technical side, figure out the path to building the custom demo software from IIW on top of the existing FreedomBox stack, i.e. integrate it with Plinth, Santiago, etc. Find attached the chocolate :) Markus -- Project Danube: http://projectdanube.org Personal Data Ecosystem Consortium: http://personaldataecosystem.org/ _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- 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