Re: [liberationtech] Recently sold sensenetworks has creepy buying habits tracking feature
So summarising the you guys mentioned, it looks like our options are: 1. randomise phone MAC addresses 2. turn off WiFi 3. don't use store loyalty cards Are there other things we can do? Are the other leakages we need to stop? On 2014-07-03 16:54, JCX wrote: There are many companies that do this through Wi-Fi hotspots. http://www.theguardian.com/technology/datablog/2014/jan/10/how-tracking-customers-in-store-will-soon-be-the-norm [4] You can correlate them to online users if the users actually connect to the free wifi hotspots and login somehow. (Think free coupon or whatever) I imagine you can get something reasonable going if you hook the system up to the POS system. Apple's recent decision to randomize MAC ID on iOS might make it harder but probably not impossible. http://arstechnica.com/apple/2014/06/ios8-to-stymie-trackers-and-marketers-with-mac-address-randomization/ [5] On 3 July 2014 02:54, dun...@openmailbox.org wrote: Hi all, A few months back a ad platform sensenetworks was recently bought by a large US corp. Among their offerings, is the not uncommon real-time bidding auction for ads: http://crypto.mm.st/sense-ad-bid.jpg [1] However, what shocks me is the claim that they're able to track users buying items in physical stores. How they do this, is completely beyond me. (https://www.sensenetworks.com/retail-retargeting/ [2]) -- Duncan -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech [3]. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. Links: -- [1] http://crypto.mm.st/sense-ad-bid.jpg [2] https://www.sensenetworks.com/retail-retargeting/ [3] https://mailman.stanford.edu/mailman/listinfo/liberationtech [4] http://www.theguardian.com/technology/datablog/2014/jan/10/how-tracking-customers-in-store-will-soon-be-the-norm [5] http://arstechnica.com/apple/2014/06/ios8-to-stymie-trackers-and-marketers-with-mac-address-randomization/ -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Recently sold sensenetworks has creepy buying habits tracking feature
Another option would be to go on the offensive. Someone can leave devices in the store whose sole purpose is just to spoof mac addresses. Ideally, this would flood their data with fake entries, making it useless to the trackers. (They didn't ask permission to do their track.) keira On Fri, Jul 4, 2014, at 03:00 AM, dun...@openmailbox.org wrote: So summarising the you guys mentioned, it looks like our options are: 1. randomise phone MAC addresses 2. turn off WiFi 3. don't use store loyalty cards Are there other things we can do? Are the other leakages we need to stop? 14 02:54, dun...@openmailbox.org wrote: Hi all, A few months back a ad platform sensenetworks was recently bought by a large US corp. Among their offerings, is the not uncommon real-time bidding auction for ads: http://crypto.mm.st/sense-ad-bid.jpg [1] However, what shocks me is the claim that they're able to track users buying items in physical stores. How they do this, is completely beyond me. Links: -- [1] http://crypto.mm.st/sense-ad-bid.jpg [2] https://www.sensenetworks.com/retail-retargeting/ -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] call and texts
Dear all, This is to bring to your attention the library of the p2p lab with free publications about the Commons and the p2p/open source movement ( http://p2plab.gr/en/publications), as well as an open call for visiting scholars geeks: http://p2plab.gr/en/call. I hope the list might find these links of interest. Best, Vasilis -- Dr. Vasilis Kostakis Research Fellow Ragnar Nurkse School of Innovation and Governance Research Director P2P Lab: http://p2plab.org -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] XKeyscore rules probably are from Snowden, after all
There has been some speculation that the recent XKeyscore rule leaks [1] do not come from Snowden — particularly, by Schneier [2]. I believe that there is a good case that the leaks do come from Snowden, since it is possible to pinpoint the date range when the rule sources [3] have been last updated. The earliest possible date is 2011-08-08, when the Linux Journal writeup about Tails [4], referenced by the glob pattern linuxjournal.com/content/linux* has been published. The pattern is not a generic Linux Journal filter, as implied in [1]. The likely latest possible date is 2012-02-28, when maatuska directory authority has changed its IP [5]. A less likely upper bound is 2012-09-21, when Faravahar directory authority has been added [6]. NSA either took the 8 authorities from the actual consensus, or picked them from Tor's sources [7]. However, Tor sources list more than 8 authorities, and are not properly maintained (e.g., see entry for moria1 wrt. its last .34/.39 octet tweaks), so I doubt NSA would use that. Moreover, it is hard to miss the port number in the sources, whereas NSA did miss that some authorities do not (and did not) use ports 80/443. E.g., moria1 (the MIT campus server mentioned in [1]) would not be matched as a Tor authority by the rules. Snowden most likely tried to contact Greenwald at the end of 2012 [8], which is entirely consistent with the above. Another NSA employee leaking XKeyscore rules after being inspired by Snowden's leaks, would have probably downloaded a more up-to-date rules file. Cross-posting to tor-dev, in case I got any historical directory authority changes wrong. [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html [2] https://www.schneier.com/blog/archives/2014/07/nsa_targets_pri.html [3] http://daserste.ndr.de/panorama/xkeyscorerules100.txt [4] http://www.linuxjournal.com/content/linux-distro-tales-you-can-never-be-too-paranoid [5] https://lists.torproject.org/pipermail/tor-dev/2012-February/003312.html [6] https://trac.torproject.org/projects/tor/ticket/5749 [7] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/config.c [8] http://www.nytimes.com/2013/08/18/magazine/laura-poitras-snowden.html -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Trends in intelligence gathering by governments - Seeking Peer Reviewers
Hi everyone, As some of you might know, the team at Security First is doing some work to breach the gap with some sectors that could benefit from the knowledge of the LiberationTech community and others. In particular, the humanitarian aid space is only now really starting to increase it's use of technology (in comparison to the human rights world) and by extension, starting to think about the problems of digital security. There is currently a report (Communications technology and humanitarian delivery: challenges and opportunities for security risk management) coming out which deals with this topic (by the European Interagency Security Forum - www.eisf.eu) and it will be read by many people in that sector who have never dealt with this sort of thing. We have been asked to write a relatively short (only 2500 words allowed) paper for the report entitled Trends in intelligence gathering by governments. Our idea is try and introduce some strategic concepts and mitigation measures then direct the reader towards more detailed sources (all the various organisations and tools in this community etc.). I was wondering if anyone has a spare hour next week to offer some community peer review on what we are writing and generally provide some constructive criticism? We will of course be happy to mention you in the report (only if your happy with that of course). Have a great weekend everyone! Rory -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] messing with XKeyScore
http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1
Errata Security
Advanced persistent cybersecurity
Friday, July 04, 2014
Jamming XKeyScore
Back in the day there was talk about jamming echelon by adding keywords to
email that the echelon system was supposedly looking for. We can do the same
thing for XKeyScore: jam the system with more information than it can handle.
(I enumerate the bugs I find in the code as xks-00xx).
For example, when sending emails, just send from the address
brid...@torproject.org and in the email body include:
https://bridges.torproject.org/
bridge = 0.0.0.1:443
bridge = 0.0.0.2:443
bridge = 0.0.0.3:443
...
Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess
up XKeyScore. It has no defense against getting flooded with information like
this, as far as I can see.
Note that the regex only cares about 1 to 3 digit numbers, that means the
following will be accepted by the system (xks-0002):
bridge = 75.748.86.91:80
The port number matches on 2 to 4 digits ([0-9]{2,4}). Therefore, bridges with
port numbers below 10 and above will be safe. I don't know if this code
reflect a limitation in Tor, or but assuming high/low ports are possible, this
can be used to evade detection (xks-0011).
Strangely, when the port number is parsed, it'll capture the first non-digit
character after the port number (xks-0012). This is normally whitespace, but we
could generate an email with 256 entries, trying every possible character. A
character like or ' might cause various problems in rendering on an HTML page
or generating SQL queries.
You can also jam the system with too many Onion addresses (xks-0003), but there
are additional ways to screw with those. When looking for Onion addresses, the
code uses a regex that contains the following capture clause:
([a-z]+):\/\/)
This is looking for a string like http://; or https://;, but the regex has no
upper bounds (xks-0004) and there is no validation. Thus, you can include
goscrewyourself://o987asgia7gsdfoi.onion:443/ in network traffic, and it'll
happily insert this into the database. But remember that no upper bounds
means just that: the prefix can be kilobytes long, megabytes long, or even
gigabytes long. You can open a TCP connection to a system you feel the NSA is
monitoring, send 5 gigabytes of lower-case letters, followed by the rest of the
Onion address, and see what happens. I mean, there is some practical upper
bound somewhere in the system,, and when you hit it, there's a good chance bad
things will happen.
Likewise, the port number for Onion address is captured by the regex (d+),
meaning any number of digits (xks-0005). Thus, we could get numbers that
overflow 16-bits, 32-bits, 64-bits, or 982745987-bits. Very long strings of
digits (megabytes) at this point might cause bad things to happen within the
system.
There is an extra-special thing that happens when the schema part of the Onion
address is exactly 16-bytes long (xks-0006). This will cause the address and
the scheme to reverse themselves when inserted into the database. Thus, we can
insert digits into the scheme field. This might foul up later code that assumes
schemes only contain letters, because only letters match in the regex.
In some protocol fields, the regexes appear to be partial matches. The system
appears to match on HTTP servers with mixminion anywhere in the name. Thus,
we start causing lots of traffic to go to our domains, such as
mixminion.robertgraham.com, that will cause their servers to fill up with
long term storage of sessions they don't care about (xks-0007)
Let's talk X.509, and the following code:
fingerprint('anonymizer/tor/bridge/tls') =
ssl_x509_subject('bridges.torproject.org') or
ssl_dns_name('bridges.torproject.org');
Code that parses X.509 certificates is known to be flaky as all get out. The
simplest thing to do is find a data center you feel the NSA can monitor, and
then setup a hostile server that can do generic fuzzing of X.509 certificates,
trying to crash them.
It's likely that whatever code is parsing X.509 certificates is not validating
them. Thus, anybody can put certificates on their servers claiming to be
'bridges.torproject.org' (xks-0008). It's likely that the NSA is parsing SSL on
all ports, so just pick a random port on your server not being used for
anything else, create a self-signed CERT claiming to be
bridges.torproject.org', then create incoming links to that port from other
places so at least search-engines will follow that link and generate traffic.
This will cause the NSA database of bridges to fill up with bad information --
assuming it's not already full from people screwing with the emails as noted
above :).
img src=http://www.google.com/?q=tails+usb; /
Putting the above code in a web page like this one will cause every visitor to
trigger a search for TAILS in the XKeyScore rules. The more people who do this,
[liberationtech] Thought experiment for Independence Day...
Thought experiment for Independence Day... How easy would it be to develop a “Public Google” that was distributed across tens of thousands of computers similar to the way that the SETI@home project uses the cycles of computers all over the world? I’m not sure how to keep the NSA out but this approach might be a good way to slow down the mining of personal data and provide a public alternative to the monopoly on search and access that Google has recently attained. Of course after that the possibility of a Public Facebook etc. etc. also becomes more realistic? This project seems do-able and the window may be shrinking? Thanks for indulging me! — Doug Douglas Schuler doug...@publicsphereproject.org https://twitter.com/doug_schuler -- Public Sphere Project http://www.publicsphereproject.org/ Creating the World Citizen Parliament http://interactions.acm.org/archive/view/may-june-2013/creating-the-world-citizen-parliament Liberating Voices! A Pattern Language for Communication Revolution (project) http://www.publicsphereproject.org/patterns/lv Liberating Voices! A Pattern Language for Communication Revolution (book) http://mitpress.mit.edu/catalog/item/default.asp?ttype=2tid=11601 -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Thought experiment for Independence Day...
You mean YaCy? Exists already. - Sent from my phone Den 4 jul 2014 17:10 skrev Doug Schuler doug...@publicsphereproject.org: Thought experiment for Independence Day... How easy would it be to develop a “Public Google” that was distributed across tens of thousands of computers similar to the way that the SETI@home project uses the cycles of computers all over the world? I’m not sure how to keep the NSA out but this approach might be a good way to slow down the mining of personal data and provide a public alternative to the monopoly on search and access that Google has recently attained. Of course after that the possibility of a Public Facebook etc. etc. also becomes more realistic? This project seems do-able and the window may be shrinking? Thanks for indulging me! — Doug Douglas Schuler doug...@publicsphereproject.org https://twitter.com/doug_schuler -- Public Sphere Project http://www.publicsphereproject.org/ Creating the World Citizen Parliament http://interactions.acm.org/archive/view/may-june-2013/creating-the-world-citizen-parliament Liberating Voices! A Pattern Language for Communication Revolution (project) http://www.publicsphereproject.org/patterns/lv http://www.publicsphereproject.org/patterns/ Liberating Voices! A Pattern Language for Communication Revolution (book) http://mitpress.mit.edu/catalog/item/default.asp?ttype=2tid=11601 -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] messing with XKeyScore
On 07/04/2014 10:56 AM, Eugen Leitl wrote: http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1 Errata Security Advanced persistent cybersecurity Friday, July 04, 2014 Jamming XKeyScore Back in the day there was talk about jamming echelon by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as xks-00xx). For example, when sending emails, just send from the address brid...@torproject.org and in the email body include: https://bridges.torproject.org/ bridge = 0.0.0.1:443 bridge = 0.0.0.2:443 bridge = 0.0.0.3:443 ... Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see. Dear Eugen, We're very excited about your approach of defending against a class of bad things in the future by studying and defending against a specific bad thing that happened in the past. Feel free to ask us any question you might have. And don't forget to ignore the insignificant cost to the adversary of changing tactics! Best, The TSA -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] [tor-talk] messing with XKeyScore
On Fri, Jul 04, 2014 at 09:36:23PM +, isis wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Eugen Leitl transcribed 5.8K bytes: http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1 Errata Security Advanced persistent cybersecurity Friday, July 04, 2014 Jamming XKeyScore Back in the day there was talk about jamming echelon by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as xks-00xx). For example, when sending emails, just send from the address brid...@torproject.org and in the email body include: https://bridges.torproject.org/ bridge = 0.0.0.1:443 bridge = 0.0.0.2:443 bridge = 0.0.0.3:443 ... Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see. Hi. I maintain and develop BridgeDB. For what it's worth, the released XKS rules would not have worked against BridgeDB for over a year now. I have no knowledge of what regexes are currently in use in XKS deployments, nor if the apparent typos are errors in the original documents, or rather typos in one of the various levels of transcriptions which may have occurred in the editing process. If these typos were at some point in the original rules running on XKS systems, then *no* bridges would have been harvested due to various faults. None. Ergo, as Jacob has pointed out to me, the regexes which are released should be assumed to be several years out of date, and also shouldn't be assumed to be representative of the entire ruleset of any deployed XKS system. I am willing to implement tricks against specific problems with them, mostly for the lulz, because fuck the NSA. But it should be assumed that the actual regexes have perhaps been updated, and that highly specific tricks are not likely to land. The ticket for this, by the way, was created by Andrea this afternoon, it's #12537: https://trac.torproject.org/projects/tor/ticket/12537 In reality it's a bit silly to try to mess with these rules if they are n-years old. Based on the pics, simply requesting that all users use brid...@bridges.torproject.org instead of brid...@torproject.org is the easiest change that by-passes this specific set of rules. But, I think it is more realistic that these minor points are moot and the regexes were fixed long ago and that the ruleset more fully covers Tor's distributors now. This problem makes me sad on many levels, and I'm not opposed to implementing mitigation techniques (within reason) based on the rulesets, however we shouldn't do anything that will hurt our users nor should be do anything that makes tor more difficult to use (unfortunately this includes sending users bogus bridge addresses). For the use-case of bridges, where a user tries to circumvent local network interference and implicitly expects they're not fingerprinted by NSA, we are mostly failing right now. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
