[liberationtech] Seed Grants for Tech Challenge for Atrocity Prevention
This might be of interest to some on this list. Lina -- Forwarded message -- From: *NPCC GGIS* g...@npccny.orgjavascript:_e(%7B%7D,'cvml','g...@npccny.org'); Date: Wednesday, February 5, 2014 Subject: Seed Grants for Tech Challenge for Atrocity Prevention To: lina.srivast...@gmail.comjavascript:_e(%7B%7D,'cvml','lina.srivast...@gmail.com'); [image: NPCC logo]http://r20.rs6.net/tn.jsp?f=001EMWUSYBx3BhhhqZ5wJ3KM0oom71O3g1cFuxGZuvVzx-S1NQsw1TmGxHJ1cPi5tF9gBt_ADrH1_NVaAJu5j473mu3ZSlvT5_P-ebRMw1Ol3Xglb7c9ZWvoS2aILed4QXo0xXwEjbnB2u_vYyCWipYhRHVRKlHuzJKDy0mS5IZ0eY=c=bIRYW1ycv7ChZpDlMHTkpNsYp8p4LFpLaCR4k2vn4flpg6ostEC6Zw==ch=Rseb00WfNFz8GzxzwUFtpMxcc89YyTAYj-B4Rgnb7Y9ZJnAGDneJag== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Government Grants Information Service Funding Alert* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Grant/Contract Name:* Seed Grants for Tech Challenge for Atrocity Prevention *Deadline: * March 10, 2014 *Funding Amount: *5 awards anticipated. Estimated Total Program Funding: $150,000; Award Ceiling: $50,000 *Eligibility: *qualified U.S. and non-U.S., nonprofit or for-profit non-governmental organizations (NGOs), and international organizations (PIO or IO). *Agency: *U.S. Agency for International Development *Grant ID: *RFA-OAA-14-61 *CFDA#: *98.001 *Summary: *Over the past year, USAID and Humanity United have jointly administered the Tech Challenge for Atrocity Prevention, a prize contest that sought innovative ideas for applying technology to five specific issues related to atrocity prevention. Discrete problems focused on by the Tech Challenge included: how to identify and spotlight intentional or unintentional third party enablers of atrocities; how to better model or forecast the likelihood of atrocity events; how to safely document and transmit evidence of atrocities; how to enable secure communication among and between at-risk communities; and how to better obtain and verify information in hard-to-access areas. The Tech Challenge utilized three different solver platforms (OpenIDEO, InnoCentive and TopCoder) to conduct each of the separate component challenges. Four of the five component challenges were ideation challenges, meaning they solicited ideas rather than prototypes, while one of the challenges sought and tested algorithms. External judges selected the winners for all of the contests. Cash prizes were disbursed to the winners of four of the five challenges via the platforms, usually for 1st, 2nd and 3rd place winners, while the fifth challenge's platform advised against monetary awards for winners. The United States Agency for International Development (USAID) is launching a Seed Grants Program to provide support for implementation of innovative technology applications for broader atrocity prevention or response efforts. *Link: * http://www.grants.gov/web/grants/view-opportunity.html?oppId=250855http://r20.rs6.net/tn.jsp?f=001EMWUSYBx3BhhhqZ5wJ3KM0oom71O3g1cFuxGZuvVzx-S1NQsw1TmG2hA-dBuxJ431xRChN7qy-6dgL_W9hj4tXqib6n4jILn5fKxhwrY1a2ctr3ZVtzRH73c50CR9ZWIn7uxP1FYDb3xQ5CGPv6tse0KbSCCL6vU007_ncYkGJBF8TjJI4gBtxfsHPg0WYm_bmdQIvipuXExYwmoym-YW2YiZD_dK0ZqJshafZjcOYg_KpTfeILWMQ==c=bIRYW1ycv7ChZpDlMHTkpNsYp8p4LFpLaCR4k2vn4flpg6ostEC6Zw==ch=Rseb00WfNFz8GzxzwUFtpMxcc89YyTAYj-B4Rgnb7Y9ZJnAGDneJag== http://visitor.constantcontact.com/do?p=unm=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7 http://www.constantcontact.com/index.jsp?cc=news01 This email was sent to lina.srivast...@gmail.com by g...@npccny.org | Update Profile/Email Addresshttp://visitor.constantcontact.com/do?p=oom=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7 | Instant removal with SafeUnsubscribehttp://visitor.constantcontact.com/do?p=unm=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7(tm) | Privacy Policy http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp. Nonprofit Coordinating Committee of New York | 135 West 36th Street, 15th Floor | New York | NY | 10018-7173 -- Lina Srivastava -- linasrivastava.com | twitter http://twitter.com/lksriv | linkedinhttp://www.linkedin.com/in/linasrivastava -- 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] uVirtus Linux, encrypted OS for Syria: a security review
On Fri, Feb 7, 2014 at 2:37 AM, Sahar Massachi sa...@brandeis.edu wrote: The fact that there's a naked sudo hole is brutal. Forgive me if I misunderstand the problem, but how could *anyone* ship a distribution with a passwordless sudo? That seems like it requires deliberate malice to even set up. Careful here: Tails had passwordless sudo prior to v0.11, less than 2 years ago. So either unlimited local root access is not such a big deal, or recommendation to use Tails is short-sighted — in either case the report has a problem. I suggest that the report author sweeps both issues under the carpet simultaneously using a politically correct language referencing problems that were taken care of a long time ago, and are not that critical to begin with. -- 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.
Re: [liberationtech] need advice on using hashes for preserving PII's utility for disambiguation while protecting sensitive info
In addition to what the others have said, I'll give a name to some of these techniques. The process of assigning an opaque random identifier to an easily reversed string is 'Tokenization'. I don't work in payment processing - but it's big there. Don't want to have a ton of PCI requirements? Pay a tokenization service - send the credit card to them, they give you an identifier (say a guid like 1C4E0B18-ABE6-4657-8B1B-79474EC80A94) and you store that. A horrible way of doing this is choosing a 'secret' salt and making every token MD5(salt || identifier). A safe way is a database of GUID-Identifier mappings. (But secure the database!) It's a pretty safe situation and used all over the payment industry BUT like others have said, requires some meta-authority between government organizations to do this, which probably makes it a non-starter. Similar, but different, is Format Preserving Encryption (FPE). FPE is used in the situation where you have a database full of credit card numbers of the form --- (or SSNs) and you realize Holy crap, storing these in plaintext is a horrible idea! - BUT you have so much software that expects credit card numbers to be in a specific form and you can't rewrite it all to handle V1dXVy1YWFhYLVlZWVktWlpaWgo= or something like that. FPE converts the credit card to NDKG-NDSH-LKAU-QNCB so your application sees it in a correct format, but it's 'encrypted' (it can ever have a correct Luhn number.) The encryption is strong, as long as you keep the key secret. But this _also_ requires some sort of meta-authority government organization and thus is even less likely to work, because as soon as you say 'crypto' everyone gets huffy about control of the keys. [0] The idea of using a CRC, a colliding but unlikely to be colliding in the situation you care about is interesting, and I have to imagine there's a term for it and studies about it. The unfortunate situation is data anonymization is wildly difficult.[1] I realize that you're in the trenches and saying Actually, the problem we have is that the anonymization is too good. The long term approach I have to problems like this is find a professor researching it, and hook up with a grad student where you get them to work on your problem. They come up with an idea, write a paper, someone else breaks their paper and your work - but hey, so long as the grad student did their homework, it's been broken in a new and novel way. ;) -tom [0] Look up the Federal Bridge PKI for a great example [1] http://strata.oreilly.com/2011/05/anonymize-data-limits.html On 6 February 2014 15:49, Tom Lee t...@sunlightfoundation.com wrote: We've been kicking around an idea at Sunlight that aims to use cryptographic ideas to resolve some of the concerns around the publication of publicly identifiable information in government disclosures. I could use some smart people to tell me what's dumb about it. We often face challenges related to disambiguating entities: is the John Smith who gave political donation A the same John Smith that gave political donation B? One obvious solution to this problem is to push to expand the information that's collected and disclosed -- if we had John's driver's license number (DLN), for instance, it'd be easy to disambiguate these records. But that could introduce privacy concerns for John. One approach to this problem (which I don't think government has tried) is employing a one-way hash. Obviously the input key space for DLNs and most other personal ID numbers is so small that reversing this with a dictionary attack would be trivial. You can add a salt, but only on a per-entity basis (not a per-record basis) if you want to preserve the capacity to disambiguate. That in turns calls for a lookup table in which the input keys are stored, which kind of defeats the point of using a hash (you might as well just assign random output IDs for each input ID). I would worry about government's ability to keep this lookup table secure, and I worry about the brittleness of such a system. Alternately, you can use a single system-wide secret (or set of secrets) to transform inputs into reliable outputs. I think this is less brittle and maybe easier to preserve as a secret, but this system might be too easily reversible given the ability to observe its outputs and know the universe of possible inputs. I'm unsure of the cryptographic options that might be appropriate here. For all I know, the lack of implementations using this kind of one-way transformation isn't about government sluggishness but rather about its feasibility. I'd be very curious to hear folks ideas on this score, though. My general hunch is that something must be possible -- even a few bits' worth of disambiguating information would be hugely useful to us, and presumably you're not leaking important amounts of information by, say, sharing the last digit of a DLN. So there must be a spectrum of options. But as is probably
Re: [liberationtech] Catch-22: When Government Tells Professors What Not to Teach
A cleared friend lamented this recently. (But long enough ago my memory is a tad hazy.) I believe they told me that they're allowed to read reports _about_ the material (e.g. a summarizing article) but not the content themselves. They wished there was some uncleared, but 'blessed' source from the government where they could read summaries so they weren't put in uncomfortable positions but at the same time had some idea of what the hell everyone was talking about. In an academic setting for a Homeland Security degree, this is clearly not as good as reading primary materials. But for the Air Force Institute of Technology, they _should_ have a class that's like 'Breaking Secure Protocols' (say, DNSSEC, TLS, SSH, Tor etc - universities do of course) and they _should_ read summaries of published attacks, and such a summary source would include enough info to augment. -tom -- 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] uVirtus Linux, encrypted OS for Syria: a security review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 07, 2014 at 11:25:31AM +0200, Maxim Kammerer wrote: On Fri, Feb 7, 2014 at 2:37 AM, Sahar Massachi sa...@brandeis.edu wrote: The fact that there's a naked sudo hole is brutal. Forgive me if I misunderstand the problem, but how could *anyone* ship a distribution with a passwordless sudo? That seems like it requires deliberate malice to even set up. Careful here: Tails had passwordless sudo prior to v0.11, less than 2 years ago. So either unlimited local root access is not such a big deal, or recommendation to use Tails is short-sighted — in either case the report has a problem. I suggest that the report author sweeps both issues under the carpet simultaneously using a politically correct language referencing problems that were taken care of a long time ago, and are not that critical to begin with. There may be two differents things mixed here. First, recommending the use of Tails instead of uVirtus is not just related to the passwordless root access. You probably noticed by reading the report that there are numerous other issues in and around uVirtus that make Tails undoubtedly a safer (and possibly easier to use) choice. Possibly not the only choice though, as this is mentioned in the conclusion with a link to a comparative study between IprediaOS, Liberté Linux, Privatix, Tails and Whonix. The idea was to avoid just saying Hey, you're using uVirtus, too bad for you, but to also give a link to better solutions in overall. It is a misundertanding to think that I sweep under the carpet the root issue and Tails at the same time: I would perform the same recommendation even without this issue. Second, on the passwordless issue itself. It may be a matter of interpretation, but considering that any executable program using sudo can get unlimited access seems problematic to me. As mentioned in the report, in Syria a common method of attack is to fool users in downloading and executing malicious programs disguised as something else. If one manages to have the user do this from uVirtus, it looks to me quite easy then to perform nasty stuff such as messing around with the data contained on the local hard disks. Maybe it is not so easy to do, making the issue not that critical as you state, in which case I think it'd be useful to justify a bit the claim. But then maybe this depends on other security features of the system you're considering, and in uVirtus the fact that this issue is surrounded by many others seems to make it quite critical. The Tails ChangeLog¹ I found for 0.11 does not seem to explain why the passwordless root was removed, but my guess would go towards security concerns. Best, KheOps ¹ https://git-tails.immerda.ch/tails/plain/debian/changelog?id=0.11 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS9NSYAAoJEK9g/8GX/m3dz3AIAI7UyyRYH5mJbUAIAlUcGRQp cKeTneIMeAheJGiaBQm+gMypL0x8hA5Q2lioZyXGnP2NyU4OG+ktJCOSguflXDx2 9IqeKoyrS9bp6AJAY2A+a361wN28OgQr6gPc7C+s8DNDNcv6v4LksD1MphS1j01Y uHJ4OcuN1AqzvZbGK22nkAewT89qF4YzEraHoWpqlUZEh+hvxBfYScipWA/h8wMD xCU1ZZyJVyYtEOHpV15Oja1DXtLrL5Db9uizI6k8UtHEgn+KxNq6wQb66tmDiwNs 9AJAD8ndc6oz5cEkQtOaMvqVVMDyTGWJwHS7zU3Zaj6LtDJHLizAjhM2Nsz1vKY= =fj5e -END PGP SIGNATURE- -- 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] [sunlightlabs] need advice on using hashes for preserving PII's utility for disambiguation while protecting sensitive info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/14 20:56, Margie Roswell wrote: For all I know, the lack of implementations using this kind of one-way transformation isn't about government sluggishness but rather about its feasibility. I'd be very curious to hear folks ideas on this score, though. My general hunch is that something must be possible -- even a few bits' worth of disambiguating information would be hugely useful to us, and presumably you're not leaking important amounts of information by, say, sharing the last digit of a DLN. So there must be a spectrum of options. But as is probably apparent, I don't think I've got a handle on how to think about this problem rigorously. Even if you had a perfect method of anonymising the individual records, they might be reidentifiable by examining the whole dataset: http://33bits.org/2010/06/21/myths-and-fallacies-of-personally-identifiable-information/ http://randomwalker.info/social-networks/ http://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf At the level of individual records, you could use modular exponentiation to anonymise the data. You pick a prime modulus p, and each organisation that's going to publish anonymised data picks a random secret value. Organisation X with secret value x anonymises a piece of data d by publishing d_x = d^x mod p, and organisation Y with secret value y anonymises the same data by publishing d_y = d^y mod p. If X and Y want to know which records they have in common, X takes the data published by Y and calculates d_x' = d_y^x mod p = d^(yx) mod p, and Y takes the data published by X and calculates d_y' = d_x^y mod p = d^(xy) mod p. For each record in common, d_x' = d_y', but neither can de-anonymise records published by the other that they don't have in common. This can be extended to more than two organisations: pass the records round in a circle, and when they get back to you they've been exponentiated by all the secret values (order doesn't matter). Now you can see which records you have in common with all the other organisations. (Maybe. IANAC.) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJS9NWaAAoJEBEET9GfxSfMyWcH/1Au9/066O/3AaPkkid8nBhq 2uuNjjLgDWzE+5aTIQGMzk9yy85TRKlXKdC4c9/n0UXxJjAUYxkLSoNkAD33ej36 s/oi3pI0C9OQ1MffJVCSImA+NwQ0QqDG6DOUBNPRoBUTr/nd5efbBRwWVtLSn50D 0QlLJYXUGGB+fSMZKyy368rrx5Ue8ICQOzIUyNJ3sWZsQEJo0nE8WJd1+89GlR45 XPRSUUma/5DCECl9gWBFq5pVuEtf29KoXV6QLCzagWCaAa2dNlCspoGp4bVlkBz9 UWMJRFHYDj9AxzUKt5Vi++uh6nYrTu++a7bXqOGJHb9y8VL54JHweEXNW2xWyog= =BrUY -END PGP SIGNATURE- -- 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] Unmasking the hardliner webosphere in Iran
Hi folks, Small Media has published a report about the hardliner webosphere in Iran. The report is the first in-depth research about the hardline on the Persian cyberspace with lots of interesting information. You can read the report here: http://unmaskthearzeshi.com I was one of the senior researchers in this report and I'll be happy to receive your feedback about it. Cheers, Amin -- 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] Seed Grants for Tech Challenge for Atrocity Prevention
I believe it's only open to winners of the tech challenge from last year. On Feb 7, 2014 12:54 AM, Lina Srivastava l...@linasrivastava.com wrote: This might be of interest to some on this list. Lina -- Forwarded message -- From: *NPCC GGIS* g...@npccny.org Date: Wednesday, February 5, 2014 Subject: Seed Grants for Tech Challenge for Atrocity Prevention To: lina.srivast...@gmail.com [image: NPCC logo]http://r20.rs6.net/tn.jsp?f=001EMWUSYBx3BhhhqZ5wJ3KM0oom71O3g1cFuxGZuvVzx-S1NQsw1TmGxHJ1cPi5tF9gBt_ADrH1_NVaAJu5j473mu3ZSlvT5_P-ebRMw1Ol3Xglb7c9ZWvoS2aILed4QXo0xXwEjbnB2u_vYyCWipYhRHVRKlHuzJKDy0mS5IZ0eY=c=bIRYW1ycv7ChZpDlMHTkpNsYp8p4LFpLaCR4k2vn4flpg6ostEC6Zw==ch=Rseb00WfNFz8GzxzwUFtpMxcc89YyTAYj-B4Rgnb7Y9ZJnAGDneJag== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Government Grants Information Service Funding Alert* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Grant/Contract Name:* Seed Grants for Tech Challenge for Atrocity Prevention *Deadline: * March 10, 2014 *Funding Amount: *5 awards anticipated. Estimated Total Program Funding: $150,000; Award Ceiling: $50,000 *Eligibility: *qualified U.S. and non-U.S., nonprofit or for-profit non-governmental organizations (NGOs), and international organizations (PIO or IO). *Agency: *U.S. Agency for International Development *Grant ID: *RFA-OAA-14-61 *CFDA#: *98.001 *Summary: *Over the past year, USAID and Humanity United have jointly administered the Tech Challenge for Atrocity Prevention, a prize contest that sought innovative ideas for applying technology to five specific issues related to atrocity prevention. Discrete problems focused on by the Tech Challenge included: how to identify and spotlight intentional or unintentional third party enablers of atrocities; how to better model or forecast the likelihood of atrocity events; how to safely document and transmit evidence of atrocities; how to enable secure communication among and between at-risk communities; and how to better obtain and verify information in hard-to-access areas. The Tech Challenge utilized three different solver platforms (OpenIDEO, InnoCentive and TopCoder) to conduct each of the separate component challenges. Four of the five component challenges were ideation challenges, meaning they solicited ideas rather than prototypes, while one of the challenges sought and tested algorithms. External judges selected the winners for all of the contests. Cash prizes were disbursed to the winners of four of the five challenges via the platforms, usually for 1st, 2nd and 3rd place winners, while the fifth challenge's platform advised against monetary awards for winners. The United States Agency for International Development (USAID) is launching a Seed Grants Program to provide support for implementation of innovative technology applications for broader atrocity prevention or response efforts. *Link: * http://www.grants.gov/web/grants/view-opportunity.html?oppId=250855http://r20.rs6.net/tn.jsp?f=001EMWUSYBx3BhhhqZ5wJ3KM0oom71O3g1cFuxGZuvVzx-S1NQsw1TmG2hA-dBuxJ431xRChN7qy-6dgL_W9hj4tXqib6n4jILn5fKxhwrY1a2ctr3ZVtzRH73c50CR9ZWIn7uxP1FYDb3xQ5CGPv6tse0KbSCCL6vU007_ncYkGJBF8TjJI4gBtxfsHPg0WYm_bmdQIvipuXExYwmoym-YW2YiZD_dK0ZqJshafZjcOYg_KpTfeILWMQ==c=bIRYW1ycv7ChZpDlMHTkpNsYp8p4LFpLaCR4k2vn4flpg6ostEC6Zw==ch=Rseb00WfNFz8GzxzwUFtpMxcc89YyTAYj-B4Rgnb7Y9ZJnAGDneJag== http://visitor.constantcontact.com/do?p=unm=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7 http://www.constantcontact.com/index.jsp?cc=news01 This email was sent to lina.srivast...@gmail.com by g...@npccny.org | Update Profile/Email Addresshttp://visitor.constantcontact.com/do?p=oom=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7 | Instant removal with SafeUnsubscribehttp://visitor.constantcontact.com/do?p=unm=001B0eMsXdjRo76QnxyEAmu8Q%3D%3Dch=d3359130-1d4c-11e3-874d-d4ae5292c973ca=306d728e-1c4f-42fe-ba1b-79baa8cde3e7(tm) | Privacy Policyhttp://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp . Nonprofit Coordinating Committee of New York | 135 West 36th Street, 15th Floor | New York | NY | 10018-7173 -- Lina Srivastava -- linasrivastava.com | twitter http://twitter.com/lksriv | linkedinhttp://www.linkedin.com/in/linasrivastava -- 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
[liberationtech] Stanford blocking webmail access to those who refuse spyware
I awoke this morning to find this awaiting me behind Stanford's WebAuth to access Zimbra: WebLogin What is this? You are being temporarily blocked from accessing Stanford systems because one or more of your mobile devices is not compliant with the School of Medicine's Data Security Policy. To remove this block, please go to med.stanford.edu/securityblock/mobile.html and follow the directions. This is after following every requirement such that my devices do not fall under the new requirements, including several emails to Randy Livingston, Michael Duff, and Jack Zeng. And filing a variance request (that has since been ignored). So much for their claims that this new security policy is not mandatory. This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. It seems for now I can still access my email via IMAP, but how long before the Great Firewall of Stanford blocks that access, too? Seems like we need some liberation not just in this country, but this particular campus as well. Frustratingly, ~T -- Tomer Altman, MS PhD Candidate Biomedical Informatics --- BigFix is a backdoor on your personal property that continuously scans your private files: http://ucomm.stanford.edu/computersecurity/ http://www.stanford.edu/group/security/securecomputing/idf/ Stanford University's stand on academic freedom, privacy, surveillance and the Fourth Amendment: Users have no expectation of privacy while using this system and uses, data, and transmissions on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed at the discretion of Stanford University -- Fine print when you log in to Stanford WebAuth -- 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] Stanford blocking webmail access to those who refuse spyware
Transfer to Harvard Medical School, or MIT, or Columbia! :D Best Regards | Cordiales Saludos | Grato, Andrés L. Pacheco Sanfuentes a...@acm.org +1 (817) 271-9619 On Fri, Feb 7, 2014 at 11:52 AM, taltm...@stanford.edu wrote: I awoke this morning to find this awaiting me behind Stanford's WebAuth to access Zimbra: WebLogin What is this? You are being temporarily blocked from accessing Stanford systems because one or more of your mobile devices is not compliant with the School of Medicine's Data Security Policy. To remove this block, please go to med.stanford.edu/securityblock/mobile.html and follow the directions. This is after following every requirement such that my devices do not fall under the new requirements, including several emails to Randy Livingston, Michael Duff, and Jack Zeng. And filing a variance request (that has since been ignored). So much for their claims that this new security policy is not mandatory. This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. It seems for now I can still access my email via IMAP, but how long before the Great Firewall of Stanford blocks that access, too? Seems like we need some liberation not just in this country, but this particular campus as well. Frustratingly, ~T -- Tomer Altman, MS PhD Candidate Biomedical Informatics --- BigFix is a backdoor on your personal property that continuously scans your private files: http://ucomm.stanford.edu/computersecurity/ http://www.stanford.edu/group/security/securecomputing/idf/ Stanford University's stand on academic freedom, privacy, surveillance and the Fourth Amendment: Users have no expectation of privacy while using this system and uses, data, and transmissions on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed at the discretion of Stanford University -- Fine print when you log in to Stanford WebAuth -- 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] Stanford blocking webmail access to those who refuse spyware
On Fri, Feb 7, 2014 at 9:52 AM, taltm...@stanford.edu wrote: This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. This seemed to me like an inevitable outcome when there was little to no backlash against spyware requirements for exams in most law-schools. (unless you want the massive disadvantage of turning in your exam on paper…) I can't fathom how people it was remotely acceptable to require the installation of spyware on students systems at institutions training people for work which handles confidential client information where running such software ought to be considered an violation of professional conduct. But there you go— the world is an unfathomable place and here we have just a natural continuation of that unfathomably. Cynically, I might suggest that the issue causing the complaints is not the spyware, is that you don't get anything in return for it that you weren't already receiving. -- 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] Stanford blocking webmail access to those who refuse spyware
In response I have created the following Facebook Group to help gather support for showing the administration that their policies have crossed a line: https://www.facebook.com/groups/nospysu/ Of course I have reservations using Facebook for this (i.e., the public/private surveillance partnership), so I am open to alternatives. Thanks, ~Tomer taltm...@stanford.edu writes: I awoke this morning to find this awaiting me behind Stanford's WebAuth to access Zimbra: WebLogin What is this? You are being temporarily blocked from accessing Stanford systems because one or more of your mobile devices is not compliant with the School of Medicine's Data Security Policy. To remove this block, please go to med.stanford.edu/securityblock/mobile.html and follow the directions. This is after following every requirement such that my devices do not fall under the new requirements, including several emails to Randy Livingston, Michael Duff, and Jack Zeng. And filing a variance request (that has since been ignored). So much for their claims that this new security policy is not mandatory. This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. It seems for now I can still access my email via IMAP, but how long before the Great Firewall of Stanford blocks that access, too? Seems like we need some liberation not just in this country, but this particular campus as well. Frustratingly, ~T -- Tomer Altman, MS PhD Candidate Biomedical Informatics --- BigFix is a backdoor on your personal property that continuously scans your private files: http://ucomm.stanford.edu/computersecurity/ http://www.stanford.edu/group/security/securecomputing/idf/ Stanford University's stand on academic freedom, privacy, surveillance and the Fourth Amendment: Users have no expectation of privacy while using this system and uses, data, and transmissions on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed at the discretion of Stanford University -- Fine print when you log in to Stanford WebAuth -- Tomer Altman, MS PhD Candidate Biomedical Informatics --- BigFix is a backdoor on your personal property that continuously scans your private files: http://ucomm.stanford.edu/computersecurity/ http://www.stanford.edu/group/security/securecomputing/idf/ Stanford University's stand on academic freedom, privacy, surveillance and the Fourth Amendment: Users have no expectation of privacy while using this system and uses, data, and transmissions on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed at the discretion of Stanford University -- Fine print when you log in to Stanford WebAuth -- 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] Stanford blocking webmail access to those who refuse spyware
This seemed to me like an inevitable outcome when there was little to no backlash against spyware requirements for exams in most law-schools. There was backlash at Berkeley (my law school), and the school no longer forces students to install exam software. On 2/7/14, 10:12 AM, Gregory Maxwell wrote: On Fri, Feb 7, 2014 at 9:52 AM, taltm...@stanford.edu wrote: This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. This seemed to me like an inevitable outcome when there was little to no backlash against spyware requirements for exams in most law-schools. (unless you want the massive disadvantage of turning in your exam on paper…) I can't fathom how people it was remotely acceptable to require the installation of spyware on students systems at institutions training people for work which handles confidential client information where running such software ought to be considered an violation of professional conduct. But there you go— the world is an unfathomable place and here we have just a natural continuation of that unfathomably. Cynically, I might suggest that the issue causing the complaints is not the spyware, is that you don't get anything in return for it that you weren't already receiving. -- 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] Stanford blocking webmail access to those who refuse spyware
What kind of webmail are you talking about? Microsoft Exchange? That would be, like, so unprofessional! On Feb 7, 2014 11:52 AM, taltm...@stanford.edu wrote: I awoke this morning to find this awaiting me behind Stanford's WebAuth to access Zimbra: WebLogin What is this? You are being temporarily blocked from accessing Stanford systems because one or more of your mobile devices is not compliant with the School of Medicine's Data Security Policy. To remove this block, please go to med.stanford.edu/securityblock/mobile.html and follow the directions. This is after following every requirement such that my devices do not fall under the new requirements, including several emails to Randy Livingston, Michael Duff, and Jack Zeng. And filing a variance request (that has since been ignored). So much for their claims that this new security policy is not mandatory. This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. It seems for now I can still access my email via IMAP, but how long before the Great Firewall of Stanford blocks that access, too? Seems like we need some liberation not just in this country, but this particular campus as well. Frustratingly, ~T -- Tomer Altman, MS PhD Candidate Biomedical Informatics --- BigFix is a backdoor on your personal property that continuously scans your private files: http://ucomm.stanford.edu/computersecurity/ http://www.stanford.edu/group/security/securecomputing/idf/ Stanford University's stand on academic freedom, privacy, surveillance and the Fourth Amendment: Users have no expectation of privacy while using this system and uses, data, and transmissions on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed at the discretion of Stanford University -- Fine print when you log in to Stanford WebAuth -- 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] Stanford blocking webmail access to those who refuse spyware
On 02/07/2014 01:12 PM, Gregory Maxwell wrote: On Fri, Feb 7, 2014 at 9:52 AM, taltm...@stanford.edu wrote: This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. This seemed to me like an inevitable outcome when there was little to no backlash against spyware requirements for exams in most law-schools. I'm unclear on the meaning of this sentence. Are you saying you fought against the spyware requirements and then realized the inevitable outcome when you couldn't garner enough support? If so, I'd be curious to know the kind of tactics you used and if you have any advice for resisting these kinds of programs going forward. -Jonathan -- 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] GIS data for Gender International Development
From: Hemant Purohit hem...@knoesis.org I am wondering if you could help me find some GIS dataset relating to gender and development, relevant to international development policy applications. Please let me know about any pointers to further dig into. I appreciate your help. Thanks very much, Hemant Purohit Researcher, Ohio Center of Excellence in Knowledge-enabled Computing (Kno.e.sis) - FB LinkedIn Twitter G+ http://knoesis.wright.edu/researchers/hemant -- 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] Suggested Readings on Consumer Surveillance
From: surveilla...@jiscmail.ac.uk Surveillance and Society: http://library.queensu.ca/ojs/index.php/surveillance-and-society/issue/view/Consumption Pridmore, Jason. 2012. “Consumer Surveillance Context , Perspectives and Concerns in the Personal Information Economy.” In Routledge Handbook of Surveillance Studies, edited by Kirstie Ball, Kevin D. Haggerty, and David Lyon, 321–329. Routledge. Beckett, Antony. 2012. “Governing the Consumer: Technologies of Consumption.” Consumption Markets Culture 15 (1) (March): 1–18. Coll, S. 2013. “Consumption as Biopower: Governing Bodies with Loyalty Cards.” Journal of Consumer Culture 13 (3) (October 25): 201–220. Zwick, D., and J. Denegri Knott. 2009. “Manufacturing Customers: The Database as New Means of Production.” Journal of Consumer Culture 9 (2) (June 15): 221–247. Andrejevic, Mark. 2013. Infoglut: How too much information is changing the way we think and know. New York: Routledge. Murakami Wood, David, and Kirstie Ball. 2013. Brandscapes of control? Surveillance, marketing and the co-construction of subjectivity and space in neo-liberal capitalism. Marketing Theory 13 (1):47-67 Zurawski, Nils. Consuming Surveillance: Mediating Control Practices Through Consumer Culture and Everyday Life, in: Jansson, André / Christensen, Miyase (eds.) Media, Surveillance and Identity, New York u.a. 2014, Peter Lang. Details Zurawski, Nils. Local practice and global data. Loyalty cards, social practices and consumer surveillance- Sociological Quarterly, Volume 52, Issue 3 (Fall) 2011.-- 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] First public DNSChain server went online yesterday!
From README.md on GitHub: DNSChain (formerly DNSNMC) makes it possible to be certain that you're communicating with who you want to communicate with, and connecting to the sites that you want to connect to, without anyone secretly listening in on your conversations in between. • DNSChain stops the NSA by fixing HTTPS • Free SSL certificates • How to use DNSChain *right now*! • Don't want to change your DNS settings? • The '.dns' meta-TLD • How to run your own DNSChain server • Requirements • Getting Started for devs and sys admins • List of public DNSChain servers • Contributing • Style and Process • TODO • Release History • License https://github.com/okTurtles/dnschain Previous thread was: [liberationtech] okTurtles DNSNMC: Surveillance-free communication. Fixes HTTPS. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- 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.
