July 2018 - cypherpunks-legacy

[IP] Google reduces search log retention to 18 months
by David Farber 06 Jul '18

06 Jul '18

http://googleblog.blogspot.com/2007/06/how-long-should-google-remember.html Posted by Peter Fleischer, Global Privacy Counsel Over the years webve taken many steps to protect our users' data and privacy. For example, we have resisted overly-broad government subpoenas; we've designed our services to give users a choice between personalized services and general services; and we've engineered our services to allow users to see and control how much data they wish to share with us. Recently, we took another important step to improve our privacy practices by announcing a new policy to anonymize our server logs after 18 to 24 months, becoming the first leading search company to publish a data retention policy. We also posted here to explain the factors that guided our decision to retain server log data for 18 to 24 months. The Article 29 Working Party, an advisory panel composed of representatives from all of the E.U.'s national data protection authorities, has sent us a letter in response to our commitment to anonymize server logs. In it, they're asking us to provide further information about our new policy, and to explain why we feel that the time period of 18 to 24 months is b proportionateb under European data protection principles. For some time, we've discussed many things with the Working Party, ranging from issues raised by Google products like Gmail and Google Desktop to industry-wide concerns, such as the challenges of protecting privacy in the Web 2.0 era. Webre pleased that this most recent letter from the Working Party acknowledges our ongoing engagement with the data protection community and, in particular, our "readiness to consult with it [the Working Party] in contrast with a relative lack of engagement by some of the other leading players in the search engine communityb. In the spirit of transparency, we're publishing our response to the Working Party's letter. The Internet is a global medium, and the principles at stake -- privacy, security, innovation and legal obligations to retain data -- have an impact beyond Europe, and outside of the realm of privacy. These principles sometimes conflict: while shorter retention periods are good for privacy, longer retention periods are needed for security, innovation and compliance reasons. We believe webve struck a reasonable balance between these various factors. Our policies are consistent with EU data protection laws, which acknowledge the need to set data retention periods that are proportionate and that enable companies like Google to comply with legal requirements. We have a legitimate interest in retaining search server logs for a number of reasons: * to improve our search algorithms for the benefit of users * to defend our systems from malicious access and exploitation attempts * to maintain the integrity of our systems by fighting click fraud and web spam * to protect our users from threats like spam and phishing * to respond to valid legal orders from law enforcement as they investigate and prosecute serious crimes like child exploitation; and * to comply with data retention legal obligations. After considering the Working Party's concerns, we are announcing a new policy: to anonymize our search server logs after 18 months, rather than the previously-established period of 18 to 24 months. We believe that we can still address our legitimate interests in security, innovation and anti-fraud efforts with this shorter period. However, we must point out that future data retention laws may obligate us to raise the retention period to 24 months. We also firmly reject any suggestions that we could meet our legitimate interests in security, innovation and anti-fraud efforts with any retention period shorter than 18 months. We are considering the Working Party's concerns regarding cookie expiration periods, and we are exploring ways to redesign cookies and to reduce their expiration without artificially forcing users to re-enter basic preferences such as language preference. We plan to make an announcement about privacy improvements for our cookies in the coming months. As we build new products and services, we look forward to continuing our discussion with the Article 29 Working Party and with privacy stakeholders around the world. Our common goal is to improve privacy protections for our users. ------------------------------------------- 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

[liberationtech] http://peoplesskype.org/
by Yosem Companys 06 Jul '18

06 Jul '18

The People's SkypeA phone-powered, distributed voice and voting system for the #Occupy Movement call 917-719-2006 Share on Tumblr <http://www.tumblr.com/share> <http://peoplesskype.org/img/1.png> <http://peoplesskype.org/img/2.png> The People's Mic works well for small General Assemblies, but in larger GAs, multiple echoes of the speaker's words is hard to follow. The People's Skype can help! Call & create a new Mic. Share the unique Mic PIN with others. Use phone speakerphones to create a distributed PA system. <http://peoplesskype.org/img/3.png> <http://peoplesskype.org/img/4.png> Listeners can vote by dialing on their phone's keypad. Hundreds of people can listen and vote at the same time. People's Skype can also help in special cases, like communicating across police barriers or kettled areas. <http://peoplesskype.org/img/5.png> <http://peoplesskype.org/img/6.png> Powered by Tropo <https://www.tropo.com/home.jsp> (the coolest), MongoDB<http://www.mongodb.org/> (also cool), & PHP //- - - - - Get the code - - - - - //<https://github.com/jrbaldwin/OWS-Globe-/blob/master/augmented_peoples_mic/t…> Bug Reports, Suggestions, Complaints, etc.? jrbaldwin--at--gmail--d0t--c0m Building Better Speech + Globe project by -- jrbaldwin<http://jrbaldwin.com/> -- Instructors: Melanie Crean + Chris Csikszentmihalyi Parsons, the New School for Design. Creative Commons License: [image: Creative Commons License]<http://creativecommons.org/licenses/by-nc-sa/3.0/> _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [linux-elitists] Monday 15 Dec: first all-Open Source System-on-Chip
by Seth David Schoen 06 Jul '18

06 Jul '18

Jason Spence writes: > - Really fast PKI crypto on a dedicated processor for ipsec type > stuff I don't think the TCG TPM is the really fast processor you're looking for; from all accounts I've heard, it's really rather slow. > - Provide a trusted "hypervisor" or "ring -1" environment from which > authorized code can spy on the operating system and make sure it's > not running any reverse engineering tools or known cracks before > the authorized code can install itself or download privileged data > like strictly licensed content or restricted documents, etc I don't think "spy on the operating system" is quite the right term. It might be better to say "prove that the relevant parts of the operating system, if any, are completely unmodified". There is no intrinsic value judgment and there is also no attempt to identify particular _ways_ of modifying the operating system as "bad". At the same time, you can also try to reduce the privilege of the operating system to affect certain things, so that it may not matter to certain secure operations whether the operating system is compromised or not. > - Protected cert store in hardware that is somehow immune or > resistent to tampering (I don't completely understand how this > can't be attacked by patching the nexus on the hard disk; I'm > learning more about it) There is an ingenious thing called a platform configuration register (PCR) that contains hashes of running code. The hardware is designed in a such a way that, if the PCRs are used at all, at least the first PCR will accurately reflect the code first loaded and to which control was first transferred. Because of the way the hardware is set up, if you load different code (a different or modified nexus, for example), the PCR values are guaranteed to be different. To put this a different way, the hardware has (minimal, but security-relevant) knowledge of what software is running. If different software is running -- for whatever reason -- the PCR values will be different. The encryption and decryption keys for the seal and unseal operation are derived by hashing the PCRs, and the PCRs are derived by hashing running code. There is supposed to be no way to get arbitrary values into PCRs (which is actually an oversimplification, but you can pretend it's true) and so you can choose not to use them at all, but you can't choose to load values into them that precisely correspond to the values they would have been loaded with if you had booted an operating environment other than the operating environment you actually did boot. Therefore, the _availability_ of a valid encryption or decryption key inside the TPM -- to make an unseal operation work properly -- depends on what software is really running. You can have many different operating environments installed on a single PC -- differing by a little or a while -- and in principle they cannot unseal one another's sealed data at all, because each one has its own family of PCR values that results when it's booted. > I write a worm. It's a nasty little bugger. It pokes around your > machine and your network for anything that looks like a credit card > number. It's allowed to install itself in the protected memory area > because it's ostensibly a popup blocker or spam blocker or something > and I got it certified by NGSCB or whoever'll be in charge of handing > out signatures. There is no central CA necessarily implied by NGSCB. Loading these applets should require some kind of user decision and should not be automatic based on presentation of a certificate. The trusted computing applets are not supposed to have direct access to any hardware (except that they can take input directly from the keyboard when no other process is doing so, and they can write output directly to the video framebuffer). That is the NGSCB model. So they can't themselves directly "poke around your machine and your network"; they would need to have an ordinary (unencrypted) user-space agent that does that. In priciple, it should be possible to detect and interfere with the operation of that agent by standard anti-virus or IDS techniques. If there is some reason that the user-space agent can't be disrupted or detected -- which I don't imagine is the case -- then you have a severe problem. But note that the trusted computing applet can't authenticate the identity of the user-space agent code. > It joins a p2p network of other worms which can't be spied upon > because the crypto keys are located in curtained memory and since your > debugger doesn't have access to curtained memory, you can't get a copy > of them. This part seems very possible. > You can't get a copy of the destination addresses that your > credit card numbers are being sent to either, because those are also > located in curtained memory. Since the worm applet needs to use regular operating system services to access the network, and since your computer is connected to a network you can observe, you should be able to see the IP addresses of the peers -- you can just run netstat, or you can run a sniffer, or a firewall that monitors connection requests. You can tell who the peers are. Of course, the worm can conceivably conceal where the _ultimate_ destination is, if the worm network is a store-and-forward kind of network. In fact, the attacker who wrote the worm can join the worm network in a way that looks like just another infected peer -- but unlike other peers, the worm author can decrypt the messages from all the other worms and make use of them. (But that can be done today. Just have worms join an IRC channel and post data there encrypted with some public key. The worm author can join the same channel -- pretending to be another infected victim -- and log what gets posted there, and then decrypt it with the corresponding private key.) > Oh yeah, and it'll fire up your modem > and wardial for fax machines and randomly fax the credit card numbers > around too, just because I like to be a pain in the ass. I'm told there is a scheme like this in Europe now where people are unwittingly calling the equivalent of 900 numbers. But remember that in NGSCB the code in curtained memory can't access the modem -- it needs to rely on a user-space agent to ask the OS to do that. The OS could still enforce a policy saying that the agent can't actually access the modem, or the agent could still be detected by an antivirus program. -- Seth David Schoen <schoen(a)loyalty.org> | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), | 464 U.S. 417, 445 (1984) _______________________________________________ linux-elitists http://zgp.org/mailman/listinfo/linux-elitists ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 0.97c removed an attachment of type application/pgp-signature]

1 0

Mining for kids: Children can't opt out of Pentagon
by Kurt Albershardt 06 Jul '18

06 Jul '18

recruitment database <http://www.vermontguardian.com/national/012006/Pentagon.shtml> Mining for kids: Children can't "opt out" of Pentagon recruitment database By Kathryn Casa | Vermont Guardian Parents cannot remove their children's names from a Pentagon database that includes highly personal information used to attract military recruits, the Vermont Guardian has learned. The Pentagon has spent more than $70.5 million on market research, national advertising, website development, and management of the Joint Advertising Market Research and Studies (JAMRS) database ? a storehouse of questionable legality that includes the names and personal details of more than 30 million U.S. children and young people between the ages of 16 and 23. The database is separate from information collected from schools that receive federal education money. The No Child Left Behind Act requires schools to report the names, addresses, and phone numbers of secondary school students to recruiters, but the law also specifies that parents or guardians may write a letter to the school asking that their children's names not be released. However, many parents have reported being surprised that their children are contacted anyway, according to a San Francisco-based coalition called Leave My Child Alone (LMCA). "We hear from a lot of parents who have often felt quite isolated about it all and haven't been aware that this is happening all over the country," said the group's spokeswoman, Felicity Crush. Parents must contact the Pentagon directly to ask that their children's information not be released to recruiters, but the data is not removed from the JAMRS database, according to Lt. Col. Ellen Krenke, a Pentagon spokeswoman. Instead, the information is moved to a suppression file, where it is continuously updated with new data from private and government sources and still made available to recruiters, Krenke said. It's necessary to keep the information in the suppression file so the Pentagon can make sure it's not being released, she said. Krenke said the database is compiled using information from state motor vehicles departments, the Selective Service, and data-mining firms that collect and organize information from private companies. In addition to names, addresses, Social Security numbers, and phone numbers, the database may include cell phone numbers, e-mail addresses, grade-point averages, ethnicity, and subjects of interest. ... ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- 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] Mining for kids: Children can't opt out of Pentagon recruitment
by David Farber 06 Jul '18

06 Jul '18

database X-Mailer: Apple Mail (2.746.2) Reply-To: dave(a)farber.net Begin forwarded message:

1 0

Re: Echelon papers leaked
by Travis H. 06 Jul '18

06 Jul '18

Two chapters are online here: http://www.fas.org/irp/eprint/sp/ -- "If I could remember the names of these particles, I would have been a botanist" -- Enrico Fermi -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.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] cloning of chip The Financial Times: US group implants electronic tags in workers]]
by Dave Farber 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: FOR IP: Re: [IP] The Financial Times: US group implants electronic tags in workers] Date: Sun, 12 Feb 2006 19:01:58 -0500 From: Valdis.Kletnieks(a)vt.edu To: dave(a)farber.net References: <43EFC85D.2060509(a)farber.net> On Sun, 12 Feb 2006 18:44:29 EST, Bob Rosenberg said: > "So far around 70 people in the US have had the implants, the company said." > > I don't believe I need to mention a litany of privacy concerns at the > moment. And to make things worse, somebody has already discovered how to skim and clone the VeriChip. http://cq.cx/verichip.pl The problem is, of course, that you can leave your ID badge at home when you go to the supermarket, or the movies - but leaving your arm at home isn't very workable. This makes a "skim, clone, and utilize" attack a lot *easier*. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD79NPh0VyAToQeqERAkhUAJ9Yr39oNbXDx+rsbQ5v2+CP3h91VgCgps/0 i0ol8rVZnYdIe7kjyottfmY= =8uL4 -----END PGP SIGNATURE----- ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- 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

RFID Clonable
by Brad Malin 06 Jul '18

06 Jul '18

Hi Dave, remember a couple of years ago when you said you wanted to clone and repeat RFIDs - apparently someone has built the system to it. -brad http://www.engadget.com/2006/07/24/verichips-human-implatable-rfid- chips-clo nable-sez-hackers/ VeriChip's human-implatable RFID chips clonable, sez hackers Posted Jul 24th 2006 4:14PM by Donald Melanson Filed under: Misc. Gadgets, Wireless In case anyone needed more proof that we're all living in a Philip K. Dick novel, a pair of hackers have recently demonstrated how human- implantable RFID chips from VeriChip can be easily cloned, effectively stealing the person's identity. Annalee Newitz and Jonathan Westhues showed off their handiwork at the HOPE Number Six conference in New York City this weekend, with Newitz herself playing the role of guinea pig, implanting a VeriChip RFID chip in her right arm. To clone the chip, Westhues first red Newitz's arm with a standard RFID reader, then scanned it again with a homebrew antenna connected to his laptop, which recorded the signal off the chip. He then used the same RFID reader to read the signal from his laptop, which promptly spit out Newtiz's supposedly unique ID. For its part, VeriChip has only said they haven't yet had a chance to review the evidence but still insist that "it's very difficult to steal a VeriChip." ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- 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] RFID Clonable
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[IP] Google reduces search log retention to 18 months
by David Farber 06 Jul '18

06 Jul '18

http://googleblog.blogspot.com/2007/06/how-long-should-google-remember.html Posted by Peter Fleischer, Global Privacy Counsel Over the years webve taken many steps to protect our users' data and privacy. For example, we have resisted overly-broad government subpoenas; we've designed our services to give users a choice between personalized services and general services; and we've engineered our services to allow users to see and control how much data they wish to share with us. Recently, we took another important step to improve our privacy practices by announcing a new policy to anonymize our server logs after 18 to 24 months, becoming the first leading search company to publish a data retention policy. We also posted here to explain the factors that guided our decision to retain server log data for 18 to 24 months. The Article 29 Working Party, an advisory panel composed of representatives from all of the E.U.'s national data protection authorities, has sent us a letter in response to our commitment to anonymize server logs. In it, they're asking us to provide further information about our new policy, and to explain why we feel that the time period of 18 to 24 months is b proportionateb under European data protection principles. For some time, we've discussed many things with the Working Party, ranging from issues raised by Google products like Gmail and Google Desktop to industry-wide concerns, such as the challenges of protecting privacy in the Web 2.0 era. Webre pleased that this most recent letter from the Working Party acknowledges our ongoing engagement with the data protection community and, in particular, our "readiness to consult with it [the Working Party] in contrast with a relative lack of engagement by some of the other leading players in the search engine communityb. In the spirit of transparency, we're publishing our response to the Working Party's letter. The Internet is a global medium, and the principles at stake -- privacy, security, innovation and legal obligations to retain data -- have an impact beyond Europe, and outside of the realm of privacy. These principles sometimes conflict: while shorter retention periods are good for privacy, longer retention periods are needed for security, innovation and compliance reasons. We believe webve struck a reasonable balance between these various factors. Our policies are consistent with EU data protection laws, which acknowledge the need to set data retention periods that are proportionate and that enable companies like Google to comply with legal requirements. We have a legitimate interest in retaining search server logs for a number of reasons: * to improve our search algorithms for the benefit of users * to defend our systems from malicious access and exploitation attempts * to maintain the integrity of our systems by fighting click fraud and web spam * to protect our users from threats like spam and phishing * to respond to valid legal orders from law enforcement as they investigate and prosecute serious crimes like child exploitation; and * to comply with data retention legal obligations. After considering the Working Party's concerns, we are announcing a new policy: to anonymize our search server logs after 18 months, rather than the previously-established period of 18 to 24 months. We believe that we can still address our legitimate interests in security, innovation and anti-fraud efforts with this shorter period. However, we must point out that future data retention laws may obligate us to raise the retention period to 24 months. We also firmly reject any suggestions that we could meet our legitimate interests in security, innovation and anti-fraud efforts with any retention period shorter than 18 months. We are considering the Working Party's concerns regarding cookie expiration periods, and we are exploring ways to redesign cookies and to reduce their expiration without artificially forcing users to re-enter basic preferences such as language preference. We plan to make an announcement about privacy improvements for our cookies in the coming months. As we build new products and services, we look forward to continuing our discussion with the Article 29 Working Party and with privacy stakeholders around the world. Our common goal is to improve privacy protections for our users. ------------------------------------------- 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