July 2018 - cypherpunks-legacy

Can cryptography prevent printer-ink piracy?
by Jeff.Hodges＠KingsMountain.com 06 Jul '18

06 Jul '18

Can cryptography prevent printer-ink piracy? http://hardware.slashdot.org/article.pl?sid=07/07/01/0221213&from=rss Zack Melich writes with news of a new front about to open in the war printer manufacturers wage with cartridge counterfeiters, refillers, and hardware hackers. A San Francisco company, Cryptography Research Inc., is designing a crypto chip to marry cartridges to printers. There's no word so far that any printer manufacturer has committed to using it. Quoting: "The company's chips use cryptography designed to make it harder for printers to use off-brand and counterfeit cartridges. CRI plans to create a secure chip that will allow only certain ink cartridges to communicate with certain printers. CRI also said that the chip will be designed that so large portions of it will have no decipherable structure, a feature that would thwart someone attempting to reverse-engineer the chip by examining it under a microscope to determine how it works. 'You can see 95 percent of the [chip's] grid and you still don't know how it works,' said Kit Rodgers, CRI's vice president of business development. Its chip generates a separate, random code for each ink cartridge, thus requiring a would-be hacker to break every successive cartridge's code to make use of the cartridge." =JeffH ------------------------------------------- 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

[IP] Can cryptography prevent printer-ink piracy?
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

<nettime> "A new WikiLeaks" revolts against Assange
by nettime's avid reader 06 Jul '18

06 Jul '18

http://www.dn.se/nyheter/varlden/a-new-wikileaks-revolts-against- assange-1.1224764 Uppdaterat 2010-12-09 22:17. Publicerat 2010-12-09 22:16 The pressure on WikiLeaks is increasing. DN.se reveals that several key figures behind the website that publishes anonymous submissions and leaks of sensitive governmental, corporate, organizational or religious documents have resigned in protest against the controversial leader Julian Assange only to launch a new service for the so-called whistleblowers. The goal: to leak sensitive information to the public. The new project, b Openleaks,b has been under way for some time and will be launched Monday. DN.se has spoken to individuals behind the new site and the message is clear. b Our long term goal is to build a strong, transparent platform to support whistleblowers--both in terms of technology and politics--while at the same time encouraging others to start similar projects,b says a colleague wishing to remain anonymous. bAs a short-term goal, this is about completing the technical infrastructure and ensuring that the organization continues to be democratically governed by all its members, rather than limited to one group or individual.b The news comes in turbulent times for WikiLeaks. Thousands of documents infuriating global leaders and policy-makers have been unveiled to the public via Cablegate. Meanwhile, Julian Assange has been arrested in Great Britain on suspected rape charges based in Sweden. News about WikiLeaks has been over-shadowed by Assange's personal problems. Earlier this year, WikiLeaks experienced accessibility issues. According to information revealed to DN.se, the problem was not linked to outsiders trying to sabotage, but came from the inside as a signal to Julian Assange to step down. The colleagues were dissatisfied with the operation's association with Assange's personal problems and how he used the organization in his explanation of the criminal charges. It is the top-down management style which is under critique. On the other hand, the DN.se source emphasizes the fact that the new website is supportive of WikiLeaks purpose and goal. b The two organizations are similar in that aspect that both are focusing on providing means for whistleblowers to anonymously provide the public with information,b one insider says. Unlike WikiLeaks, Openleaks will not receive and publish information directly for the public eye. Instead, other organizations will access the Openleaks system and in turn, present their audience with the material. Documents will be processed and published by various collaborating organizations. b We intend to split the work in a way where we handle only the anonymity and receiving end of the information,b says another colleague. According to the internal documents shared with DN.se, Openleaks intends to establish itself as a neutral intermediary bwithout a political agenda except from the dissemination of information to the media, the public, non- profit organizations, trade- and union organizations and other participating groups.b b All editorial control and responsibility rests with the publishing organization. We will, as far as possible, take the role of the messenger between the whistleblower and the organization the whistleblower is trying to cooperate with,b says one anonymous informant. Another intended consequence is to avoid the pressure from world leaders that WikiLeaks has experienced. b As a result of our intention not to publish any document directly and in our own name, we do not expect to experience the kind of political pressure which WikiLeaks is under at this time. In that aspect, it is quite interesting to see how little of politicians' anger seems directed at the newspapers using WikiLeaks sources.b Translation: Majsan BostrC6m. Ossi Carp, ossi.carp(a)dn.se # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mail.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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

<nettime> "A new WikiLeaks" revolts against Assange
by nettime's avid reader 06 Jul '18

06 Jul '18

http://www.dn.se/nyheter/varlden/a-new-wikileaks-revolts-against- assange-1.1224764 Uppdaterat 2010-12-09 22:17. Publicerat 2010-12-09 22:16 The pressure on WikiLeaks is increasing. DN.se reveals that several key figures behind the website that publishes anonymous submissions and leaks of sensitive governmental, corporate, organizational or religious documents have resigned in protest against the controversial leader Julian Assange only to launch a new service for the so-called whistleblowers. The goal: to leak sensitive information to the public. The new project, b Openleaks,b has been under way for some time and will be launched Monday. DN.se has spoken to individuals behind the new site and the message is clear. b Our long term goal is to build a strong, transparent platform to support whistleblowers--both in terms of technology and politics--while at the same time encouraging others to start similar projects,b says a colleague wishing to remain anonymous. bAs a short-term goal, this is about completing the technical infrastructure and ensuring that the organization continues to be democratically governed by all its members, rather than limited to one group or individual.b The news comes in turbulent times for WikiLeaks. Thousands of documents infuriating global leaders and policy-makers have been unveiled to the public via Cablegate. Meanwhile, Julian Assange has been arrested in Great Britain on suspected rape charges based in Sweden. News about WikiLeaks has been over-shadowed by Assange's personal problems. Earlier this year, WikiLeaks experienced accessibility issues. According to information revealed to DN.se, the problem was not linked to outsiders trying to sabotage, but came from the inside as a signal to Julian Assange to step down. The colleagues were dissatisfied with the operation's association with Assange's personal problems and how he used the organization in his explanation of the criminal charges. It is the top-down management style which is under critique. On the other hand, the DN.se source emphasizes the fact that the new website is supportive of WikiLeaks purpose and goal. b The two organizations are similar in that aspect that both are focusing on providing means for whistleblowers to anonymously provide the public with information,b one insider says. Unlike WikiLeaks, Openleaks will not receive and publish information directly for the public eye. Instead, other organizations will access the Openleaks system and in turn, present their audience with the material. Documents will be processed and published by various collaborating organizations. b We intend to split the work in a way where we handle only the anonymity and receiving end of the information,b says another colleague. According to the internal documents shared with DN.se, Openleaks intends to establish itself as a neutral intermediary bwithout a political agenda except from the dissemination of information to the media, the public, non- profit organizations, trade- and union organizations and other participating groups.b b All editorial control and responsibility rests with the publishing organization. We will, as far as possible, take the role of the messenger between the whistleblower and the organization the whistleblower is trying to cooperate with,b says one anonymous informant. Another intended consequence is to avoid the pressure from world leaders that WikiLeaks has experienced. b As a result of our intention not to publish any document directly and in our own name, we do not expect to experience the kind of political pressure which WikiLeaks is under at this time. In that aspect, it is quite interesting to see how little of politicians' anger seems directed at the newspapers using WikiLeaks sources.b Translation: Majsan BostrC6m. Ossi Carp, ossi.carp(a)dn.se # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mail.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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: [tahoe-dev] Idea for a Publish/Subscribe Message System on Tahoe-LAFS
by Brian Warner 06 Jul '18

06 Jul '18

>> On Sat, Feb 11, 2012 at 11:08 AM, darrob <darrob(a)i2pmail.org> wrote: >> >> I'd like to discuss my idea for a messaging system on Tahoe with you. >> As far as I know there is currently no such thing. Great idea! We've discussed this a bit in the past, in the context of helping AllMyData users send files to each other, but never got around to building most of it. (We did build a tinyurl-like service that pointed at filecaps, with some Javascript in the frontend that acted upon the link by inserting the filecap into your root directory, but it was mostly out-of-band). Our thought was to give each pair of users a pair of directories. Each one would be an "inbox" for one of them and an "outbox" for the other. You'd give your friend the writecap to your inbox, and they'd add things to it. Then you'd read from it later. A user agent could notice when something was added to the inbox and move it somewhere else (sort of like maildir's new/ and cur/ directories), to keep the inbox tidy. >> The file naming scheme here is <username>-<user_ID>-<timestamp> >> -<message_hash>. The user_ID could be the directory URI or a shorter >> hash of it etc. You could just use the file's filecap: those are unique. Or the storage-index if you wanted to show someone else the directory listing without revealing the filecaps. >> [1]: A text file containing a list of URIs would work, too, I >> suppose. I don't know which will be more efficient. The benefit of using a dircap to track them is that you could fetch your messages from a different machine by just remembering the dircap, instead of the whole list of URIs. >> [4]: A quick Google search brought up >> http://muffinresearch.co.uk/archives/2010/10/15/fake-smtp-server-with-pytho… Twisted has a lot of SMTP functionality built-in, which would make it easier to integrate into the Tahoe process, if that ended up being useful. On 3/5/12 9:26 PM, David Reid wrote: > I've so far considered the problem from a fairly email centric point > of view. My ideas also require the so far non-existant append-only > capability and draw inspiration from systems like StubMail[1] and > Internet Mail 2000[2]. > > You see an email address, is capability in it's own right. It's a > transferable (practically) non-revocable append-only capability for a > message queue that is directly linked to your attention span. At this > point I should hope that the negative properties of an email address > are obvious. You've read my http://petmail.lothar.com/ paper, right? It probably won't surprise you that some of these ideas influenced Tahoe too. > Alice has bob's append-cap. > Alice creates a new message on the grid. > Alice takes the read-cap for that message and writes that (perhaps > with other metadata) into bob's append-cap. As above, you can mostly avoid the need for append-caps by using pairwise inbox/outbox directories. Drawbacks: * Giving Alice a one-inbox writecap allows her to cancel messages (deleting it before Bob has a chance to read it), but you could actually argue this is a feature * For long-term storage, Bob might want to have a user agent (or a cron job) copy/move messages out of the inbox and into some archive directory where Alice can't delete them any longer Advantages: * it's clear where the message came from: Alice cannot write into the inbox that Bob has created for Carol * append-only caps are, cryptographically speaking, really hard > Bob then uses the read-cap to his inbox to look at all the message > metadata and download the messages he wants to read. This is where the > system resembles Internet Mail 2000, in a grid with accounting the > cost of storing the unread sent message is pushed to the sender. Yeah, my problem with IM2k was always that storage of the message body is not the important cost: as you pointed out, it's the recipient's attention that really matters. In IM2k, or this scheme, you have to give the recipient enough information about the message (typically the subject line) to decide whether to download the rest. It'll take the spammers at most an hour before every subject line is "Help I've been mugged and lost my wallet", or "Hi sweetie", or "Important your account has been suspended", and the recipient has to download every message (or ignore them and suffer false-positives). Actually, I take it back, every spam I get already has those subject lines :). What you really need is to rate-limit attention-grabbing behavior that comes from outside a "social contract". New connections (people who learn about me out-of-band, from a conference or a blog post or on the street) are only enabled by allowing strangers to consume your time, but if you can require them to spend their time too, then you can keep things to a comfortably civilized level. That rate-limiting could take the form of CAPTCHA, or money (either a refundable bond or outright payment), or proof of membership in some group, whatever fits your tastes. You also want reciprocal access and easy third-party introductions to reduce the barrier to natural human communication patterns, and you want gradual revocation to discourage abuse by otherwise normal correspondents (that uncle who keeps forwarding chain letters to you). > My ideas sort of hinge on something which is not quite possible in > Tahoe today, the revocable append-only capability. Sadly I don't even > feel I have a good understanding of how hard it is. But if it existed > it would be an incredibly powerful primitive for all sorts of > applications. Append-only caps are possible but tricky: we've had them sketched out for years. They need pubkey-encryption (which we don't currently have or need in Tahoe), but that's not too hard. The biggest part is deciding how much complexity we're willing to accept in exchange for reducing the server-attacker's ability to selectively roll-back individual records. There's a big fun multi-way tradeoff here. Zooko is keen on using client-side storage to remember the most-recent state of the mutable object (so they can reject attempts to roll it back). I keep fantasizing about a per-share DAG of record dependencies to make it hard for N-1 of the servers to convince you that a record has gone away. And there's a funny lattice of caps (append+write+read, append-only, append-and-read, write-only, read-only, verify) that need some thought. It gets even weirder when you consider the failure modes: if each record is erasure-coded, and you get 4 shares that show evidence of record A being added, and 3 with record B added, but k=5 and neither is enough to recover the new records.. what should a new record-appender do? Adding revocation to append-only caps is more complicated, but not horribly so. You'd keep a list of pubkeys (verifiying keys) in each share, signed by a master key (which gets to add/revoke append-caps). It adds an extra dimension of failure modes. The server needs to be more aware of the share format (to enforce some of the writer restrictions, to prevent simple availability-threatening graffiti), but that's the case for irrevocable appendcaps too. > Of course, I leave the UX model of interacting with these long random > cryptographic URLs as address for contacting people as an exercises > for the reader. Bah (/me waves hands), that's what petnames are for :). cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://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

[Politech] White House supports forcible DNA extraction from Americans by cops [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

We discussed this here weeks ago: http://www.politechbot.com/2005/09/13/more-on-dna/ http://www.politechbot.com/2005/09/10/federal-dna-database/ --- http://www.washingtonpost.com/wp-dyn/content/article/2005/09/23/AR200509230… 65.html Bill Would Permit DNA Collection From All Those Arrested By Jonathan Krim Washington Post Staff Writer Saturday, September 24, 2005; Page A03 Suspects arrested or detained by federal authorities could be forced to provide samples of their DNA that would be recorded in a central database under a provision of a Senate bill to expand government collection of personal data. The controversial measure was approved by the Senate Judiciary Committee last week and is supported by the White House, but has not gone to the floor for a vote. It goes beyond current law, which allows federal authorities to collect and record samples of DNA only from those convicted of crimes. The data are stored in an FBI-maintained national registry that law enforcement officials use to aid investigations, by comparing DNA from criminals with evidence found at crime scenes. [...remainder snipped...] _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[IP] New US intelligence center to exploit publicly available information]
by David Farber 06 Jul '18

06 Jul '18

-------- Original Message -------- Subject: [EPIC_IDOF] New US intelligence center to exploit publicly available information Date: Wed, 16 Nov 2005 08:15:06 -0500 From: Richard M. Smith <rms(a)computerbytesman.com> To: EPIC_IDOF(a)mailman.epic.org http://www.politicalgateway.com/news/read.html?id=5315 New US intelligence center to exploit publicly available information WASHINGTON, Nov 8 (PG) - US intelligence chief John Negroponte announced Tuesday the creation of a new CIA-managed center to exploit publicly available information for intelligence purposes. The so-called Open Source Center will gather and analyze information from a host of sources from the Internet and commercial databases to newspapers, radio, video, maps, publications and conference reports. Douglas Naquin, the center's director, said it will build on the work of the CIA's Foreign Broadcast Information Service, which once monitored and translated foreign radio brodcasts but has since expanded its reach to other media. He said a key difference will be that the center aims to spread its findings and expertise across the US intelligence community, which consists of 15 agencies. "Generally what we go against is what's going to have the biggest intelligence impact where open sources can play an important role that either may or may not be covered by more clandestine intelligence activity or will augment it in some way," he told AFP. The FBIS' strength has been in tracking media trends that show, for instance, how foreign publics are responding to particular US policies. But in recent years a group at the FBIS also has been applying data mining techniques to analyze massive volumes of informaiton on the Internet or commercial databases, Naquin said. He said they are "trying to use what we call the volume problem against itself in some type of judo fashion -- you know, the more volume the better -- so we can kind of get some sense of where the trends are and what the buzz is on certain topics, or who's connected to whom." _______________________________________________ EPIC_IDOF mailing list EPIC_IDOF(a)mailman.epic.org https://mailman.epic.org/cgi-bin/mailman/listinfo/epic_idof ------------------------------------- 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> ______________________________________________________________ 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

Can cryptography prevent printer-ink piracy?
by Jeff.Hodges＠KingsMountain.com 06 Jul '18

06 Jul '18

Can cryptography prevent printer-ink piracy? http://hardware.slashdot.org/article.pl?sid=07/07/01/0221213&from=rss Zack Melich writes with news of a new front about to open in the war printer manufacturers wage with cartridge counterfeiters, refillers, and hardware hackers. A San Francisco company, Cryptography Research Inc., is designing a crypto chip to marry cartridges to printers. There's no word so far that any printer manufacturer has committed to using it. Quoting: "The company's chips use cryptography designed to make it harder for printers to use off-brand and counterfeit cartridges. CRI plans to create a secure chip that will allow only certain ink cartridges to communicate with certain printers. CRI also said that the chip will be designed that so large portions of it will have no decipherable structure, a feature that would thwart someone attempting to reverse-engineer the chip by examining it under a microscope to determine how it works. 'You can see 95 percent of the [chip's] grid and you still don't know how it works,' said Kit Rodgers, CRI's vice president of business development. Its chip generates a separate, random code for each ink cartridge, thus requiring a would-be hacker to break every successive cartridge's code to make use of the cartridge." =JeffH ------------------------------------------- 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

[IP] Can cryptography prevent printer-ink piracy?
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [tahoe-dev] Idea for a Publish/Subscribe Message System on Tahoe-LAFS
by Brian Warner 06 Jul '18

06 Jul '18

>> On Sat, Feb 11, 2012 at 11:08 AM, darrob <darrob(a)i2pmail.org> wrote: >> >> I'd like to discuss my idea for a messaging system on Tahoe with you. >> As far as I know there is currently no such thing. Great idea! We've discussed this a bit in the past, in the context of helping AllMyData users send files to each other, but never got around to building most of it. (We did build a tinyurl-like service that pointed at filecaps, with some Javascript in the frontend that acted upon the link by inserting the filecap into your root directory, but it was mostly out-of-band). Our thought was to give each pair of users a pair of directories. Each one would be an "inbox" for one of them and an "outbox" for the other. You'd give your friend the writecap to your inbox, and they'd add things to it. Then you'd read from it later. A user agent could notice when something was added to the inbox and move it somewhere else (sort of like maildir's new/ and cur/ directories), to keep the inbox tidy. >> The file naming scheme here is <username>-<user_ID>-<timestamp> >> -<message_hash>. The user_ID could be the directory URI or a shorter >> hash of it etc. You could just use the file's filecap: those are unique. Or the storage-index if you wanted to show someone else the directory listing without revealing the filecaps. >> [1]: A text file containing a list of URIs would work, too, I >> suppose. I don't know which will be more efficient. The benefit of using a dircap to track them is that you could fetch your messages from a different machine by just remembering the dircap, instead of the whole list of URIs. >> [4]: A quick Google search brought up >> http://muffinresearch.co.uk/archives/2010/10/15/fake-smtp-server-with-pytho… Twisted has a lot of SMTP functionality built-in, which would make it easier to integrate into the Tahoe process, if that ended up being useful. On 3/5/12 9:26 PM, David Reid wrote: > I've so far considered the problem from a fairly email centric point > of view. My ideas also require the so far non-existant append-only > capability and draw inspiration from systems like StubMail[1] and > Internet Mail 2000[2]. > > You see an email address, is capability in it's own right. It's a > transferable (practically) non-revocable append-only capability for a > message queue that is directly linked to your attention span. At this > point I should hope that the negative properties of an email address > are obvious. You've read my http://petmail.lothar.com/ paper, right? It probably won't surprise you that some of these ideas influenced Tahoe too. > Alice has bob's append-cap. > Alice creates a new message on the grid. > Alice takes the read-cap for that message and writes that (perhaps > with other metadata) into bob's append-cap. As above, you can mostly avoid the need for append-caps by using pairwise inbox/outbox directories. Drawbacks: * Giving Alice a one-inbox writecap allows her to cancel messages (deleting it before Bob has a chance to read it), but you could actually argue this is a feature * For long-term storage, Bob might want to have a user agent (or a cron job) copy/move messages out of the inbox and into some archive directory where Alice can't delete them any longer Advantages: * it's clear where the message came from: Alice cannot write into the inbox that Bob has created for Carol * append-only caps are, cryptographically speaking, really hard > Bob then uses the read-cap to his inbox to look at all the message > metadata and download the messages he wants to read. This is where the > system resembles Internet Mail 2000, in a grid with accounting the > cost of storing the unread sent message is pushed to the sender. Yeah, my problem with IM2k was always that storage of the message body is not the important cost: as you pointed out, it's the recipient's attention that really matters. In IM2k, or this scheme, you have to give the recipient enough information about the message (typically the subject line) to decide whether to download the rest. It'll take the spammers at most an hour before every subject line is "Help I've been mugged and lost my wallet", or "Hi sweetie", or "Important your account has been suspended", and the recipient has to download every message (or ignore them and suffer false-positives). Actually, I take it back, every spam I get already has those subject lines :). What you really need is to rate-limit attention-grabbing behavior that comes from outside a "social contract". New connections (people who learn about me out-of-band, from a conference or a blog post or on the street) are only enabled by allowing strangers to consume your time, but if you can require them to spend their time too, then you can keep things to a comfortably civilized level. That rate-limiting could take the form of CAPTCHA, or money (either a refundable bond or outright payment), or proof of membership in some group, whatever fits your tastes. You also want reciprocal access and easy third-party introductions to reduce the barrier to natural human communication patterns, and you want gradual revocation to discourage abuse by otherwise normal correspondents (that uncle who keeps forwarding chain letters to you). > My ideas sort of hinge on something which is not quite possible in > Tahoe today, the revocable append-only capability. Sadly I don't even > feel I have a good understanding of how hard it is. But if it existed > it would be an incredibly powerful primitive for all sorts of > applications. Append-only caps are possible but tricky: we've had them sketched out for years. They need pubkey-encryption (which we don't currently have or need in Tahoe), but that's not too hard. The biggest part is deciding how much complexity we're willing to accept in exchange for reducing the server-attacker's ability to selectively roll-back individual records. There's a big fun multi-way tradeoff here. Zooko is keen on using client-side storage to remember the most-recent state of the mutable object (so they can reject attempts to roll it back). I keep fantasizing about a per-share DAG of record dependencies to make it hard for N-1 of the servers to convince you that a record has gone away. And there's a funny lattice of caps (append+write+read, append-only, append-and-read, write-only, read-only, verify) that need some thought. It gets even weirder when you consider the failure modes: if each record is erasure-coded, and you get 4 shares that show evidence of record A being added, and 3 with record B added, but k=5 and neither is enough to recover the new records.. what should a new record-appender do? Adding revocation to append-only caps is more complicated, but not horribly so. You'd keep a list of pubkeys (verifiying keys) in each share, signed by a master key (which gets to add/revoke append-caps). It adds an extra dimension of failure modes. The server needs to be more aware of the share format (to enforce some of the writer restrictions, to prevent simple availability-threatening graffiti), but that's the case for irrevocable appendcaps too. > Of course, I leave the UX model of interacting with these long random > cryptographic URLs as address for contacting people as an exercises > for the reader. Bah (/me waves hands), that's what petnames are for :). cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://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