July 2018 - cypherpunks-legacy

Re: [liberationtech] in anticipation of Stockholm Internet Forum...
by Andre Rebentisch 06 Jul '18

06 Jul '18

Am 14.04.2012 09:51, schrieb Fabio Pietrosanti (naif): >> In other words, Sweden does monitor all traffic. > > Almost all countries have capabilities to monitor internet traffic at > borders. Indeed, though "capabilities" would not imply they actually do. I am sorry for my choice of words bc it is also difficult to determine what "monitoring" means to an institution, e.g. "printing emails forwarded to them". > It seems to me that Sweden is so civil that even the intelligence need > to ask a court order to do so. The main advantage of a court order is that we get a formal (classified) track record of the actual cases and statistics. Parliament scrutiny is a useful device. It is helpful to assess intelligence performance, and make services more efficient. You need external checks and balances, otherwise technocratic bodies get lazy and useless. Prior Court Order: Throughout Europe the EU Telecoms Package rules should apply. In the reform process some insisted on the prior court order principle. The objective and motivation from my colleagues (who wrote the related amendment) was to prevent automated net filtering (as demanded by the content industries and AT&T). The driving force for traffic monitoring is not the Levithan in Europe, but content interests. Italy is very advanced in media industry driven ISP filtering. They tried it earlier than the other member states via voluntary agreements. See also Sabam vs. Netlog. http://curia.europa.eu/juris/document/document.jsf?docid=119512&mode=req&pa… Best, Andri _______________________________________________ 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. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech 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

[Fink-announce] FINK-2004-07-24 Security Announcement - Samba
by David H. 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 ID: FINK-2004-07-24 Reported: 2004-07-13 Updated: 2004-07-24 Package: samba, samba-ldap Affected: <= 2.2.9 Maintainer: Matt Stephenson Tree(s): 10.3/stable, 10.3/unstable Mac OS X version: 10.3 Fix: upstream Updated by: forced update (dmalloc(a)users.sourceforge.net) Description: Buffer overrun in hash mangling method when the "mangling method = hash" option is enabled in smb.conf, has unknown impact and attack vectors. References: BUGTRAQ Ref-URL: http://marc.theaimsgroup.com/?l=bugtraq&m=109052891507263&w=2 Ref-URL: http://marc.theaimsgroup.com/?l=bugtraq&m=109051340810458&w=2 References: REDHAT Ref-URL: http://www.redhat.com/support/errata/RHSA-2004-259.html References: CVE Ref-URL: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0686 To verify the authenticity please visit http://fink.sourceforge.net/doc/security/notification.php?phpLang=en#who -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (Darwin) iD8DBQFBAvn2PMoaMn4kKR4RA9AlAJ4oYT8DdEXbnQw/6DyZ96NlYob6jACdFVZh 9DhJtiK0rIi2xziaqI+67wA= =vtEO -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Fink-announce mailing list Fink-announce(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-announce --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: Hello directly from Jimbo at Wikipedia
by Marc Abel 06 Jul '18

06 Jul '18

Hi Jimbo, My concern about pseudonyms is that they can compromised after-the-fact. Suppose Li Li is over in China writing blogs, and she selects Muzimei as her pseudonym and implements it with any of several digital signature schemes. Then she writes a bunch of blog entries, and possibly a few edits to her Wikipedia page. Wikipedia trusts her because of her reputation, and presumably no one knows her real name is Li Li. Except there's an eyewitness to one of her blogs, or the authorities raid her Linux box and her private key is compromised. Li Li has a serious problem, because all of her previous activity is signed by her Muzimei pseudonym, so after 36 hours of interrogation she confesses, is found guilty of separatism in an 18 minute trial, and executed 20 days later. I still lean in favor of approaches which protect Wikipedia on the basis of actual content submitted, instead of information about the submitter. This is why Paul Syverson and I are advancing these types of proposals. Once again, one way to check content (until machines can "think" better) is to have not-necessarily-anonymous parties with interests in specific subjects ok what would otherwise be anonymous posts prior to the posts showing up. This system would be only as efficient as these "approving" personnel for anonymous posts, but these people can be mutually selected in the sense that an anonymous editor can nominate anyone, and Wikipedia may refuse anyone. It's a little like any meeting held under Robert's Rules of Order. To discuss anything, someone must present a motion and someone else needs to second it. If the content's not pertinent enough for even a second, there really no need for the group to consider it. In the mechanism I am suggestion (as an intermediate-term approach to try), the mover may be anonymous if the seconder is willing not to be. Marc On Wed, 2005-09-28 at 08:36, Jimmy Wales wrote: > Marc Abel wrote: > > This has law enforcement implications; if you can prove that Alice took > > the cookie from the cookie jar, perhaps using eyewitnesses, you can now > > show that Alice did many other unreputable things. > > Can you explain this in more detail? > > --Jimbo ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[tahoe-dev] Tahoe-LAFS Weekly Dev Chat, 2012-10-09 (was: Tahoe-LAFS Weekly Dev Chat, 2012-10-02)
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

I forgot to take notes during, so this is ex post facto. Other participants, please feel free to reply and add your recollections! In attendance: Zooko, CodesInChaos, Andrew, Brian, Ali who popped in briefly because the hangout was posted as a public chat on G+, David-Sarah The topic was mostly dynamic Merkle Trees and LDMFs again. (For those following along at home, Dynamic Merkle Trees are this idea of using something like a Red-Black Tree instead of a static Binary Tree as the structure for your secure-hash-function based "authenticated data structure". Andrew Miller claims that this is a unifying abstraction that describes both git and Bitcoin, as well as any future Tahoe-LAFS Large Distributed Mutable File. See previous week's notes 9.) I said that I had been looking at using Tahoe-LAFS as the backend for other systems, to give them decentralization, fault-tolerance, integrity-checking, access control, and encryption. Those systems that I've looked at a little bit include Ward Cunningham's Smallest Federated Wiki, Dan Whaley's Hypothesis, and Jeff Garzik's gleam-in-the-eye of a fault-tolerant form to make the Bitcoin forums DoS-resistant. In each of these cases as well as in others, I have the feeling that programmers want some sort of search or query language, and when they find that LAFS doesn't natively offer that, they give up on using it. Brian replied that what you have to do is maintain your own index. He called it "voluntary search", which is a turn of phrase that I like. MK_FG's recent attempt to make a Skydrive plugin for the Cloud backend is another example where voluntary search is needed. Andrew asked for a specific use case for LDMF. How and why anyone would use LDMFs even if we had them? After all, there's no way to use the features of an LDMF, such as efficiently inserting bytes into the middle of a file, through the standard POSIX file API. I groped around for a while trying to answer that. There are a few half-formed ideas about things that LDMFs *might* turn out to be useful for, such as "filesystem in a file", which is basically what the authors of virtual machines are doing to store their virtual machine images in POSIX filesystems. Other half-formed ideas are to use LDMFs as the backend storage for git. But I finally got a hold of a use case that seems clear enough: scalable directories. Directories ought to be able to hold arbitrarily many entries, support efficiently adding or removing children, ought to be able to maintain a sort order on the children, and support range queries on the children. That *is* something that you can express through the POSIX filesystem API, it seems clear that it could be useful, and very importantly for the purposes of Andrew's research, it is easy to evaluate how well your solution satisfies it. Such directories might make a good building block for search. I remember thinking when I unsuccessfully pitched LAFS as a possible backend for Singly/LockerProject that if only directories had been scalable, sorted, and range-queriable then LAFS might have sufficed for their needs. Along the way I pointed people at the performance.rst file: https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/docs/performance.rst Only to see that it appears to be describing the performance of old SDMFs, not of MDMFs! For example it says: """ Downloading B bytes of an A-byte mutable file cpu: ~A network: A memory footprint: A notes: As currently implemented, mutable files must be downloaded in their entirety before any part of them can be read. We are exploring fixes for this; see ticket #393 for more information. """ Which is very stale information. We've closed #393 and made it so that you only need to download about B bytes to read B bytes of an A-byte mutable file. I thought we had updated performance.rst to reflect that. What gives? Do I misremember or did we somehow regress performance.rst? There are a few tickets about updating performance.rst to reflect the existence of MDMF: #1497, #1772. Andrew mentioned that since last week he implemented a new Red-Black Merkle Tree in C++, and it is 400X faster than the first Python-based prototype. I questioned why the language would make that much difference and suggested he try PyPy. Regards, Zooko https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1497# update docs/performance.rst to explain the performance of MDMFs https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1772# update docs to include MDMF 9 https://tahoe-lafs.org/pipermail/tahoe-dev/2012-October/007750.html _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

[HacDC:Byzantium] Collaboration?
by m0nk 06 Jul '18

06 Jul '18

So I'm way late to the game on this but I was wondering if there is something we could do to collaborate on mesh projects. It seems there are way to many splinter groups wanting the same thing but are slightly too divergent to combine. I just spoke @ DefCon XX with my Android Mesh project: SPAN More info here: http://youtu.be/RrI3MUnExJM In a nutshell, we have injected transparent proxies into the smart phones below the network stack to control routing. This allows us to be just another network interface and all apps behave as normal. anyway, is there interest in chatting / sharing? We are open source and are mostly interested in routing protocols and security, the initial mesh implementation was more of a platform to allo my team to explore these things easily. Thanks! m0nk -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To view this discussion on the web visit https://groups.google.com/a/hacdc.org/d/msg/Byzantium/-/pe5O_7dNfsgJ. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. ----- 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: [IP] I strongly afree with this djf Google search and
by Phil Karn 06 Jul '18

06 Jul '18

seizure >Google's internal slogan is, charmingly, ''Don't be evil." Well, the >interaction of cyber-snooping and the unreasonable searches >authorized by >the Patriot Act is pure evil. Instead of getting mad at Google, why don't we get even? Here are two simple ideas that any good coder could turn out in an afternoon: 1. Write and disseminate a little daemon that makes randomize queries to Google from your computer. Every few minutes to an hour (i.e., at random times) it would send a Google query with search terms randomly chosen from a large dictionary. This would pollute Google's logs and create reasonable doubt if you are later accused of entering queries for, say, the words "neck" and "snap". 2. Write and disseminate a web proxy filter that would route all Google queries through the TOR (The Onion Router) network and strip off all tracking mechanisms from the results. This may be a more palatable alternative to routing all your web surfing through TOR, which can be quite slow. I consider it unproductive to scream at Google, as has become so popular of late. It is also misguided to call for laws to limit what they can do with our search queries. Even if Google were to say that they no longer keep personally-identifiable search queries, there would be no way to verify it. And any new privacy law for search engines would surely be riddled with enormous loopholes for government abuse. As with confidentiality, the *only* solution here is technological. So let's get coding. --Phil ------------------------------------- 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] more on I strongly afree with this djf Google search and
by David Farber 06 Jul '18

06 Jul '18

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

1 0

Re: [IP] I strongly afree with this djf Google search and
by Phil Karn 06 Jul '18

06 Jul '18

seizure >Google's internal slogan is, charmingly, ''Don't be evil." Well, the >interaction of cyber-snooping and the unreasonable searches >authorized by >the Patriot Act is pure evil. Instead of getting mad at Google, why don't we get even? Here are two simple ideas that any good coder could turn out in an afternoon: 1. Write and disseminate a little daemon that makes randomize queries to Google from your computer. Every few minutes to an hour (i.e., at random times) it would send a Google query with search terms randomly chosen from a large dictionary. This would pollute Google's logs and create reasonable doubt if you are later accused of entering queries for, say, the words "neck" and "snap". 2. Write and disseminate a web proxy filter that would route all Google queries through the TOR (The Onion Router) network and strip off all tracking mechanisms from the results. This may be a more palatable alternative to routing all your web surfing through TOR, which can be quite slow. I consider it unproductive to scream at Google, as has become so popular of late. It is also misguided to call for laws to limit what they can do with our search queries. Even if Google were to say that they no longer keep personally-identifiable search queries, there would be no way to verify it. And any new privacy law for search engines would surely be riddled with enormous loopholes for government abuse. As with confidentiality, the *only* solution here is technological. So let's get coding. --Phil ------------------------------------- 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] more on I strongly afree with this djf Google search and
by David Farber 06 Jul '18

06 Jul '18

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

1 0

Re: [FoRK] Newsroom score: American Taliban
by J. Andrew Rogers 06 Jul '18

06 Jul '18

On Aug 29, 2012, at 9:56 AM, "Stephen D. Williams" <sdw(a)lig.net> wrote: > Is there also a conspiracy by local government not to report this voter fraud to the Federal government? > Recent stories have cited 86 or 26 verified cases of voter fraud, nationally, in the last 6 or so years. Were they all in Garden Grove? If not, what's wrong with the local election board that has prevented them from reporting these problems? Where are links to proof that this has happened? I think you are taking a bit of a naive view of the reality. I know someone that does transaction analysis at one of the major banks for the purposes of detecting irregularities such as money laundering. To do that job, they look at pretty much the entire ebb and flow of money throughout the country. While the bank only cares about irregularities it has some liability for, they detect a much broader range of crimes in the analysis. The most pervasive crime detected is securities fraud, but most people probably do not find that surprising. The second most pervasive crime, on the other hand, is very surprising to many people: judicial bribery. If we were to go by "verified cases" of judicial bribery as evidence, we would conclude that it is very rare. The people who could verify cases to your satisfaction have no significant incentive to do so and there is rarely a smoking gun that the victims of the crime can point to. In fact, most of the victims have no idea that it even occurred. Furthermore, on what basis could someone in the government responsible for investigating judicial corruption run the kind of privacy-violating fishing expeditions that the banks do? As far as the government is concerned, there is no evidence of widespread corruption in the judiciary even though they know they would find it if they actually looked. Voter fraud likely falls into a similar category. It is "rare" because it is institutionally implausible for the people who could verify it to look for it. Like with judicial bribery, there is an enormous amount of resistance to putting into place the kinds of policies that would make it possible for the government to officially verify its existence. There are many things that, as far as the government is concerned, do not exist because the government goes to great lengths to not look for them. _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- 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