----- Forwarded message from Damian Johnson <atagar(a)torproject.org> -----
Date: Sat, 3 Aug 2013 16:16:31 -0700
From: Damian Johnson <atagar(a)torproject.org>
To: tor-dev(a)lists.torproject.org, tor-reports(a)lists.torproject.org
Subject: [tor-dev] Damian's Status Report - July 2013
Reply-To: tor-dev(a)lists.torproject.org
Hi all. This month was mostly spent on non-tor work including a server
migration, bad service outage at work, and a full week of cleaning my
apartment. Still, plenty of spiffy news in stem land...
======================================================================
Remote Descriptor Fetching
======================================================================
Major feature for this month was the addition of a module to remotely
fetch tor descriptors...
https://stem.torproject.org/api/descriptor/remote.htmlhttps://lists.torproject.org/pipermail/tor-dev/2013-July/005156.html
This works much like tor itself does, downloading descriptor content
from directory authorities and mirrors. With it we can now easily script
against the present state of the tor network without piggybacking on a
live tor instance.
Curious what you can use it for? See our present monitors for some ideas...
https://lists.torproject.org/pipermail/tor-dev/2013-July/005209.htmlhttps://gitweb.torproject.org/atagar/tor-utils.git/tree
This also included a little work with Nick on the spec and tor side...
* Dropped the unimplemented microdescriptor query from the spec. (#9271)
* Noting the max queryable fingerprints/hashes in spec. (#9282)
* We're getting a high failure rate on the downloads we make. A little
more investigation is needed on my part to help narrow this down. (#9379)
======================================================================
Other news includes...
* Revised the appearance of stem's frontpage. The blue buttons were pretty
jarring, so switched to something that matches the rest of the page...
http://www.atagar.com/transfer/stem_frontpage/before.pnghttp://www.atagar.com/transfer/stem_frontpage/after.png
* Added Slackware to our download page. Many thanks to Markus for adding us
to SlackBuilds!
http://slackbuilds.org/repository/14.0/python/stem/
* Worked with Sreenatha to port Tor Weather to stem. Unfortunately Weather
does not presently have an active maintainer so I'm not sure how we will
proceed on this front. (#8264)
https://lists.torproject.org/pipermail/tor-dev/2013-July/005111.html
* The Munich dev meeting has attracted quite a few potential volunteers. After
discussing prospective projects with seros I tidied up our volunteer page.
Changes included...
* Added Christian's Globe project
https://lists.torproject.org/pipermail/tor-commits/2013-August/060124.html
* Dropped Thandy
https://lists.torproject.org/pipermail/tor-commits/2013-July/059830.html
* Merged TorStatus into the entry for Atlas
https://lists.torproject.org/pipermail/tor-commits/2013-July/060003.html
* General page corrections
https://lists.torproject.org/pipermail/tor-commits/2013-August/060125.html
* Our automated Jenkins test runs ran into another regression in tor that
caused it to segfault. (#9298)
* STREAM events mishandled IPv6 addresses. (caught and patched by soult, #9181)
* Thread with Pierre about TorPylle which turned into a discussion with Nick
regarding future language direction for the tor codebase. I'm looking
forward to seeing where it goes!
https://lists.torproject.org/pipermail/tor-dev/2013-July/005161.html
* We just finished with midterms for Google Summer of Code. Chang
unfortunately did not pass, but the other projects are going well.
* Sorted out travel arrangements for the GSoC mentor summit. Nick and I will
be going, and Moritz is presently on the waitlist.
* Code reviewed ra's rttprober. He provided some great feedback for which I
still owe him a reply.
https://lists.torproject.org/pipermail/tor-dev/2013-July/005183.html
Cheers! -Damian
_______________________________________________
tor-dev mailing list
tor-dev(a)lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
Opposition, disgust, revulsion, ridicule toward al-qaeda
is perfectly cypherpunkian. Never, ever unanimous nor
what's acceptable without merciless, obnoxious, off-topic
digression argument. "Fuck that to death." - A Sage
"Cypherpunks" -- the name, the adventure, the rise and
fall, and multiple rebirths and splits and plagiarisms --
has been subjected to as much irrational ridicule and
exploitation as hyper-plagiarized "al-qaeda."
"Cryptography" list is a bastard of a bastard of a bastard
of cypherpunks, each iteration trying to act snooty
about villanous cryptography and failing repeatedly to
hide its cypherpunkian malice.
There are thousands of vile and sappy posts in the
cpunk archives as with the "fucked to death and still
going" internet. Crud begets crud. Delete the crud and
there's nothing left of the shit-hole except the gargantuan
cesspools on Wayback and Wikipedia and Tor "hidden
services" and blacknet and undernet and intel.net and
virulent cheating, lying and fucking users and each
other.
Extra good shit:, big data crud is growing exponentially,
a golden bowl of explosive fertilizer likely leading to
global cyberwar over who runs the cess.
Never ask for permission, never give it.
Cross-sub everybody and spy them secretly.
----- Forwarded message from Jason Geffner <jason(a)crowdstrike.com> -----
Date: Tue, 6 Aug 2013 14:12:33 -0500
From: Jason Geffner <jason(a)crowdstrike.com>
To: tor-talk(a)lists.torproject.org
Cc: cameron(a)crowdstrike.com
Subject: [tor-talk] Tortilla
Organization: CrowdStrike, Inc.
X-Mailer: Microsoft Outlook 15.0
Reply-To: tor-talk(a)lists.torproject.org
I'd like to announce the availability of Tortilla, a free open-source tool
that allows users to securely, anonymously, and transparently route all
TCP/IP and DNS traffic through Tor.
Though the Tor client natively supports transparent proxying on Linux-based
systems, Tortilla allows Tor users to use Windows for transparent proxying.
Unlike other similar solutions, Tortilla does not rely on API hooks (and as
such does not allow malware to circumvent the Tor tunnel) and does not
require extra hardware, a VPN, or an extra Tor gateway virtual machine.
The whitepaper for Tortilla which describes the design goals, architecture,
and usage instructions is available at
https://media.blackhat.com/us-13/US-13-Geffner-Tor...-All-The-Things-WP.pdf
The source code is available at https://github.com/CrowdStrike/Tortilla
A pre-built distribution (compatible with 32-bit and 64-bit versions of
Windows XP through Windows 8) is available at
http://www.crowdstrike.com/community-tools
Tortilla is still in beta, but I'd be pleased to answer any questions you
may have about it.
Please note that Tortilla is produced independently from the Tor(r)
anonymity software and carries no guarantee from The Tor Project about
quality, suitability or anything else.
Sincerely,
Jason Geffner
Sr. Security Researcher, CrowdStrike
--
tor-talk mailing list - tor-talk(a)lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
----- Forwarded message from Tor Pids <torpids(a)yahoo.com> -----
Date: Tue, 06 Aug 2013 20:40:11 +0200
From: Tor Pids <torpids(a)yahoo.com>
To: tor-relays(a)lists.torproject.org
Subject: Re: [tor-relays] VPS Hardware Specification & Advice
Reply-To: tor-relays(a)lists.torproject.org
Hi,
i just saw this post on the web archive and felt I can contribute
something here so I finally registered. Maybe this reply will not be
correctly recognized to the thread, sorry.
The VPS specs you posted should be more than enough - but the price is
too expensive!
I currently run about 20 Tor relays on cheap VPS all around the world:
http://globe.rndm.de/#/search/query=torpids
Basically I just care for the bandwidth/included traffic when choosing
a VPS. 256MB RAM is enough, disk space doesn't matter at all. Tor
doesn't scale that well with CPU cores so 1 core is ok. For only 1 or
2 of my VPS the CPU is the bottleneck (at about 20-30MBit/s), but most
are fast enough. Most cheap VPS are based on the OpenVZ virtualization
which limits you to their old kernel and sometimes they limit the
number of tcp connections (see "cat /proc/user_beancounters"). KVM or
Xen virtualisation is better because you have more control on the VM.
Most VPS providers add up the incoming and outgoing bandwidth, meaning
that you might be able to just send about 500GB with your 1TB plan.
For example with a VPS from www.jiffybox.de for 15€ per month it is
possible to push more than 1TB PER DAY(!) (and not per month as with
the 18€ plan you mentioned). OVH just released a server for £2,99 per
month with unlimited 100MBit/s as well:
https://www.ovh.co.uk/dedicated_servers/kimsufi.xml
Other typical offers are like 10TB for 10$ or 20MBit/s unlimited for 3€.
Good places to find cheap VPS deals:
http://www.lowendbox.com/ and http://lowendtalk.com/categories/offershttp://www.wjunction.com/46-vpshttp://www.webhostingtalk.com/forumdisplay.php?f=104
Best,
Torpids
_______________________________________________
tor-relays mailing list
tor-relays(a)lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
----- Forwarded message from Caleb James DeLisle <calebdelisle(a)lavabit.com> -----
Date: Mon, 05 Aug 2013 14:55:22 -0400
From: Caleb James DeLisle <calebdelisle(a)lavabit.com>
To: Michael Rogers <michael(a)briarproject.org>
Cc: liberationtech <liberationtech(a)lists.stanford.edu>
Subject: Re: [liberationtech] CJDNS hype
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
Reply-To: liberationtech <liberationtech(a)lists.stanford.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
On 08/05/2013 01:26 PM, Michael Rogers wrote:
> Hi Caleb,
>
> On 03/08/13 01:33, Caleb James DeLisle wrote:
>> We could spend a long time discussing locally effective attacks on social networks and not be any closer to agreement.
>
>> Instead I think it's worth asking who your attacker is... I find that when people don't stop to ask who the attacker is, what he wants and what resources he can apply on the attack, they end up with a default assumption that the attacker is everywhere and has infinite resources.....
>
>> If you can give me a clear picture of the person who would use this attack, what they want from the attack and what resources they can bring to bear on the problem, I might be able to speak more to the issue.
>
> Excellent point! The adversary I have in mind looks something like this:
>
> * Can create adversarial nodes * Can persuade a limited proportion of users to make direct connections to adversarial nodes
Infecting existing nodes is cheaper than knocking on doors asking people
to connect to your evil nodes because your reputation doesn't suffer when
the trick is discovered.
> * Can co-ordinate the behaviour of all adversarial nodes * Can create low-latency, high-bandwidth connections between adversarial nodes
It doesn't cover whether adversarial nodes are geographically
dispersed or not. If they are then the the attack is significantly
more expensive.
> * Can't monitor or tamper with direct connections between non-adversarial nodes * Can't break standard crypto primitives * Aims to degrade the performance of cjdns for some or all users
This is good from a capabilities standpoint but it doesn't cover
motive which is hugely important to threat modeling. If someone has
significant resources and their motive is "to cause mayhem", securing
infrastructure against them is not really possible which is why
traditional antiterrorism efforts seem incoherent.
Causing localized network disruption is trivial in any ethernet,
you simply answer ARP or DHCP packets. This is done by some malware
but the motive is to carry out a MiTM attack and trick the victim
into installing the malware binary which is disguised as an update.
With cjdns you would not have the ability to MiTM so the same style
attack would just cause a localized network outage.
Another motive for localized DoS is to force users to an unencrypted
channel. If every time the police use encrypted radio you jam it,
they may be tricked into using unencrypted channels. The main defense
against this is not to have an insecure backup.
Also note that localized network outages can be caused by wire cutters
and/or wifi jammers so a protocol attack may never be the most effective
approach.
>
>>> What heuristics do you have in mind?
>
>
>> Given a set of known evil nodes, find the longest common route prefix(es) which contain all of the evil nodes. The last node along each common prefix is probably an edge.
>
> How would you find a set of known evil nodes?
cat-and-mouse games which is why I don't like this approach.
You could send forwarded packets to nodes to whom you know a direct
path and then send them a direct packet asking if they got the
forwarded packet. You have to try it a few times to be sure the
endpoint is not fooling you and there are still more ways to detect
and work around it.
It's not something I'm interested in ever implementing so it's not
really worth further discussion.
>
>>> People have put years of research effort into designing automatic Sybil defenses. The solutions they've come up with (SybilGuard, SybilLimit, Gatekeeper, SybilInfer) are complex and heavyweight, and they depend on assumptions about the structure of the social network - in other words they're not off-the-shelf solutions that you could just drop into cjdns later if the need arises.
>
>
>> They operate under different constraints.
>
> Could you elaborate on the differences? The systems I mentioned are designed for use in P2P networks where the edges are based on real-world social relationships and there's no central authority. Isn't that similar to the cjdns setting?
I suppose it is because the same information can be derived, albeit
with some complexity. In cjdns the path through the social network
which is represented by any given node is expressed in the label so
you get it for free.
>
>> Everybody knows paths to those who are the numerically closest to themselves no matter the physical distance. Since addresses are spread randomly throughout the network, it means that anyone given node is directly reachable from a few nodes in each physical locality of the network.
>
> Let's consider what happens as the network grows. On average, each node is pointed to by t routing table entries, where t is the size of a node's routing table. As the network grows, the t entries pointing to a given node will be spread more thinly across the network, unless we increase t in direct proportion to the number of nodes. Increasing t like that won't scale indefinitely, but for the sake of argument let's assume it will scale well enough for whatever size cjdns grows to.
>
> So wherever we start from, there's some nearby node that knows a switching path to the destination. However, the length of that switching path will increase (on average) as the network grows. Even if we had a magic oracle that told us the shortest path to any destination, that path would still be longer on average in a large network than a small network.
>
> Therefore if some proportion of the nodes are adversarial, the probability of hitting an adversarial node on the way from a randomly chosen source to a randomly chosen destination will increase as the network grows.
It's all true but it's worth noting that in order to maintain the same
proportion of evil nodes in a growing network, the evil net must grow
as well which brings us back to motive. If somebody is willing and able
to invest a significant amount of money into setting up evil nodes then
he must want something.
It seems more realistic that the evil nodes would be compromised good
nodes, an attack which which scales better.
>
>>> If the attacker creates a Sybil region of social space that's larger than the non-Sybil region, and you try to ensure that your routing table contains a diverse sampling of the whole social space, then your routing table will tend to contain more Sybils than non-Sybils.
>
>
>> The number of nodes and the way they're organized doesn't help. They're all behind a common label prefix (the path to the sybil edge) and that label prefix would cause them to be seen as a cluster.
>
> Unfortunately it's not that simple. You're assuming that from the point of view of a given node, all the Sybils are behind a single edge (an attack edge, in SybilGuard terminology). But a given Sybil may be reachable via multiple attack edges. That's why SybilGuard and its descendents are so complex: before sampling the network to look for clusters, they have to ensure that there's only a single way for samples to reach each node.
With cjdns there are multiple ways to reach a node but only one best
way so that's mostly a solved problem.
A non-adversarial way to look at this proposal is it attempts to avoid
over-reliance on a single network link. Each edge would just appear as
a link with a disproportionate number of nodes relying on it.
You should check out the network, I think you'd find some interesting
discussions in the dark irc network (irc.hypeirc.net) #hyperboria and
#cjdns you might also find some people interested in helping with briar ;)
Thanks,
Caleb
>
> Cheers, Michael
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJR//UaAAoJECYAmptlsgnWHtMP/07m2NN2A+vk9isBn9eOzkyN
GcjgJFL0VbcRQXU/sSQnzowcfoGT2bDy2IkscrjrIZYULbzJMGTurkfQK8+t/ZDH
MVCouz6T/p8XVhPjQ8s/sq/JEIS3roV4sE/Qrt+P7vZp7Dv6vL69gAmf+OSTmgLY
K8R1NY9BQD1wv16pwSUfyaccsoftxE3GytKCxMkW4jqa8ENUIDWEJ5qrsbesSTdy
Tl0zaypC2Z1teud8G1plxV7sQvTQjjeV7+RXG39icTdkteyZQr8wcqo/69FUI6yb
MXc2fBYLjnQjr6yJFSZPvhCnD8AR5TLwZC6Oi2x3TbYsBNXqjGxr73y/gRsX/SEv
mHXWCzIa3MIWStVQZTDuM4edLi6ab2ZViMueospfs/sfptMiJkDpPjom8HvHgNZh
9tjScCPZKiOqYU44DYNkCeNKKbuABukkEGh5S0KafSg0YiV4qrogLsfata2+AXjy
joa3YydwcCkjZ2wa5A3LIZV8qwLFVdQ9Y+6dIMOe1xqBF7Cd/5KOtFMpglXU0pdF
tIFxnILYc3B5w71wADDGnC69+iOde3Wv8NVgqmSplu94nq1UKQO4MzQB2hiiMgE9
XG+xBNpqJH0MpTgoH0zSwcdaw5z2E94MQ+stSDi2Ll19pmoTQHIDKcSdnT6Q/UPP
XUOK2ZWn3eP24w9F4Ao9
=Pohw
-----END PGP SIGNATURE-----
--
Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
----- Forwarded message from Josh Steiner <josh(a)vitriolix.com> -----
Date: Tue, 6 Aug 2013 11:06:10 -0700
From: Josh Steiner <josh(a)vitriolix.com>
To: Guardian Dev <guardian-dev(a)lists.mayfirst.org>
Subject: [guardian-dev] BREACH: SSL is pwnd
in summary, you need to turn off gzip to mitigate this for now:
http://breachattack.com/https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
At last week's Black Hat conference, researchers announced the BREACH
attack<http://breachattack.com/>,
a new attack on web apps that can recover data even when secured with SSL
connections. The BREACH
paper<http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seco…>
(PDF)
contains full details (and is a good and fairly easy read).
Given what we know so far, we believe that *BREACH may be used to
compromise Django's CSRF protection*. Thus, we're issuing this advisory so
that our users can defend themselves.
BREACH takes advantage of vulnerabilities when serving compressed data over
SSL/TLS. Thus, to protect yourself from BREACH, you should disable
compression of web responses. Depending on how your application is
deployed, this could take a couple forms:
1. Disabling Django's GZip
middleware<https://docs.djangoproject.com/en/dev/ref/middleware/#module-django.middlew…>
.
2. Disabling GZip compression in your web server's config. For example,
if you're using Apache you'd want to disable
mod_deflate<http://httpd.apache.org/docs/2.2/mod/mod_deflate.html>;
in nginx you'd disable the gzip module<http://wiki.nginx.org/HttpGzipModule>
.
Additionally, you should make sure you disable TLS compression by adjusting
your server's SSL
ciphers<http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/>
.
We plan to take steps to address BREACH in Django itself, but in the
meantime we recommend that all users of Django understand this
vulnerability and take action if appropriate.
Posted by *Jacob Kaplan-Moss* on August 6, 2013
_______________________________________________
Guardian-dev mailing list
Post: Guardian-dev(a)lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To Unsubscribe
Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org
Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org
You are subscribed as: eugen(a)leitl.org
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
http://www.nsa.gov/about/cryptologic_heritage/center_crypt_history/news/ind…
The theme for the 2013 symposium, to be held on
October 17-18 at the Johns Hopkins Applied Physics
Laboratory's Kossiakoff Conference Center (just west
of Laurel, Maryland) is "Technological Change and
Cryptology: Meeting the Historical Challenges."
The conference will include sessions on "A Tribute to Alan
Turing," a "Roundtable on Cyber History," "Bletchley Park,"
"COMINT and the Civil War," "The Cryptologic Legacy of
the Great War Era," "SIGINT and the Vietnam War Era,"
and "A Technological Advantage: Historical Perspectives
on Cryptologic Research and Development."
In all there will be 21 separate sessions and over 70
presentations. Speakers will include scholars such as
David Kahn and cryptologic pioneers such as Whitfield
Diffie. All symposium sessions are unclassified.
A complete agenda and registration information will be
available on this site in mid-August.
For more information, please contact the Center for Cryptologic
History at 301-688-2336 or via email at
<mailto:history@nsa.gov>history(a)nsa.gov.
----- Forwarded message from Steven Aftergood <saftergood(a)fas.org> -----
Date: Tue, 06 Aug 2013 06:48:11 -0700
From: Steven Aftergood <saftergood(a)fas.org>
To: eugen(a)leitl.org
Subject: Secrecy News -- 08/06/13
Reply-To: saftergood(a)fas.org
X-Mailer-LID: 1
X-Mailer-RecptId: 399049
X-Mailer-SID: 1866
X-Mailer-Sent-By: 2
Format Note: If you cannot easily read the text below, or you prefer to
receive Secrecy News in another format, please reply to this email to let
us know.
SECRECY NEWS
from the FAS Project on Government Secrecy
Volume 2013, Issue No. 72
August 6, 2013
Secrecy News Blog: http://blogs.fas.org/secrecy/
** MILITARY TESTS DATA MINING OF SOCIAL MEDIA FOR SPECIAL OPS
** U.S. TRADE POLICY, AND MORE FROM CRS
MILITARY TESTS DATA MINING OF SOCIAL MEDIA FOR SPECIAL OPS
The U.S. military has been investigating the use of sophisticated data
mining tools to probe social media and other open sources in order to
support military operations against money laundering, drug trafficking,
terrorism and other threats. But the window for doing so may be closing as
the social media landscape changes, according to an internal assessment.
U.S. Special Operations Command (SOCOM) National Capital Region (NCR)
conducted a series of experiments over the past year under the rubric
"QUANTUM LEAP" that was intended to test "non-traditional" tools and
techniques to advance the SOCOM mission.
An after-action report on the first experiment said it "was successful in
identifying strategies and techniques for exploiting open sources of
information, particularly social media, in support of a counter threat
finance mission." Counter threat finance refers to efforts to disrupt an
adversary's finances. A copy of the SOCOM NCR report was obtained by
Secrecy News. See "Project QUANTUM LEAP: After Action Report," 12
September 2012:
http://www.fas.org/irp/eprint/quantum.pdf
"Major lessons learned were the pronounced utility of social media in
exploiting human networks, including networks in which individual members
actively seek to limit their exposure to the internet and social media...,"
the report said.
The QUANTUM LEAP project, which did not utilize classified intelligence,
relied heavily on participation by private sector firms identified in the
report, who demonstrated tools they had developed "to enhance the ability
to discover relationships, human networks, and geospatial features" from
open source data.
A tool called Social Bubble permitted the search of Twitter-related
content "to explore human networks associated with the [counter threat
finance] scenario and enabled identification of various entities...
associated with the moneylaundering network." A tool called Recon was used
to reconstruct source documents from a raw data stream. Another tool
served to "collect large quantities of data from the 'deep web', or sources
which are accessible via the internet but not necessarily indexed or linked
via a world wide web page." And another called Semantica "is capable of
ingesting structured and semi-structured data and displaying it in a
'triplet' format, e.g. two entities and a relationship, such as [A is owned
by B]."
"More than 200 additional open-source tools and sources were identified
relevant to counter threat finance," the SOCOM report said.
The report said that as valuable as the opportunity created by new
techniques for data mining of open sources appears to be, it may prove to
be transient.
"We are currently in a 'window' of opportunity for exploitation of social
media sources for application to CTF [counter threat finance] or other
SOCOM NCR missions. This window could be as narrow as 18-24 months before
the social media phenomenon transforms. This future transformation is
unknown and could offer additional opportunities, or existing opportunities
could be closed, but the only thing that is certain is that there will
continue to be rapid change."
There are also unresolved legal issues.
"Legal review of the appropriate use and application of social media data
is in its infancy. Social media is transforming notions of privacy and
distinctions between personally identifiable information (PII) and
self-reported public information will have to be established by precedent
in case law," the report said.
"Almost all information relevant to the QUANTUM LEAP experiment has a
locative context [revealing the location of the source]. Location based
services (LBS) are becoming integrated into every facet of our lives and
are becoming much more accepted. There is a cultural/generational component
to acceptance of LBS in social media," the report said.
SOCOM Public Affairs did not respond to requests for comment or further
information about the project, and the report describing the effort
(labeled "draft") has not been formally released. However, the report was
kept unclassified, facilitating its dissemination and discussion among the
interested public.
Meanwhile, the future of SOCOM National Capital Region is itself
uncertain, as Congress has thus far declined to authorize or appropriate
funds that were requested for it in the coming fiscal year.
"The Committee remains unclear about the function, purpose, and costs
associated with the operations, infrastructure, and facilities for this
entity [SOCOM National Capital Region] both in the interim phase and the
final end-state," according to a June 2013 report of the House
Appropriations Committee. "Further, the Committee has received conflicting
information over the course of the last year as to the purpose of this
entity."
Project QUANTUM LEAP derives its name and inspiration from an initiative
in the late 1990s to incorporate advanced technologies into Naval Special
Warfare capabilities. That earlier Project QUANTUM LEAP was described in
"Stimulating Innovation in Naval Special Warfare by Utilizing Small Working
Groups" by Thomas A. Rainville, Master's Thesis, March 2001.
http://www.fas.org/irp/eprint/rainville.pdf
U.S. TRADE POLICY, AND MORE FROM CRS
New and newly updated Congressional Research Service reports that Congress
has withheld from online public distribution include the following.
Trade Promotion Authority (TPA) and the Role of Congress in Trade Policy,
August 2, 2013:
http://www.fas.org/sgp/crs/misc/RL33743.pdf
Trade Adjustment Assistance (TAA) and Its Role in U.S. Trade Policy,
August 5, 2013:
http://www.fas.org/sgp/crs/misc/R41922.pdf
Trade Adjustment Assistance for Firms: Economic, Program, and Policy
Issues, August 5, 2013:
http://www.fas.org/sgp/crs/misc/RS20210.pdf
African Growth and Opportunity Act (AGOA): Background and Reauthorization,
August 2, 2013:
http://www.fas.org/sgp/crs/row/R43173.pdf
International Crises and Disasters: U.S. Humanitarian Assistance Response
Mechanisms, August 1, 2013:
http://www.fas.org/sgp/crs/row/RL33769.pdf
Chemical Facility Security: Issues and Options for the 113th Congress,
August 2, 2013:
http://www.fas.org/sgp/crs/homesec/R42918.pdf
Health Care for Veterans: Answers to Frequently Asked Questions, August 1,
2013:
http://www.fas.org/sgp/crs/misc/R42747.pdf
The MF Global Bankruptcy, Missing Customer Funds, and Proposals for
Reform, August 1, 2013:
http://www.fas.org/sgp/crs/misc/R42091.pdf
_______________________________________________
Secrecy News is written by Steven Aftergood and published by the
Federation of American Scientists.
The Secrecy News Blog is at:
http://www.fas.org/blog/secrecy/
To SUBSCRIBE to Secrecy News, go to:
http://blogs.fas.org/secrecy/subscribe/
To UNSUBSCRIBE, go to
http://blogs.fas.org/secrecy/unsubscribe/
OR email your request to saftergood(a)fas.org
Secrecy News is archived at:
http://www.fas.org/sgp/news/secrecy/index.html
Support the FAS Project on Government Secrecy with a donation:
https://members.fas.org/donate
_______________________
Steven Aftergood
Project on Government Secrecy
Federation of American Scientists
web: www.fas.org/sgp/index.html
email: saftergood(a)fas.org
voice: (202) 454-4691
twitter: @saftergood
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
