As a parallel option for introduction, a hashcash-protected global announcement queue?
Say KSK,23 at blah is a KSK protected by hashcash (this key type is implementible, the catch is that you may get a collision and then you have to find another slot and recompute). Then as an opt-in, and with a configurable hashcash strength, WoT nodes could poll a single global introduction queue. They would announce which strength queues they poll. This would ensure that everyone who wants to can see every new identity as it is announced, and form their own opinion of it. When it gets spammed, the hash strength can be increased. Obviously hashcash is not a real solution on its own. Would this satisfy the anti-WoT-censorship folk, or at least appease them to some degree? Also, it would cut the time taken to get announced: once the hashcash is solved and the key posted, we don't need to wait 24 hours for an acknowledgement. Drawbacks: - Excludes users with slow systems. - Limited deterrent to a determined attacker. - Might need native hashcash cracking libraries? OTOH the hashes are implemented in native code anyway by the JVM, so maybe not. Advantages: - With the current system, if an identity is marked as spam early on, many people won't see it. Whereas if you can announce to a large number of people at once, and have each evaluate your posts individually, this may avoid some of the effects the anti-wot-censorship lobby are complaining about. - Useful emergency fallback should the captchas be broken. Sensible? Stupid? Also, what about an option for ignoring the WoT's opinion until a newbie has posted at least N messages, or M time has elapsed? On Wednesday 06 May 2009 22:00:34 xor wrote: > Hello, > > I am currently refactoring the WoT plugin to allow per-context trust values. > > Lets first explain how WoT currently works so you can understand what I mean: > - There is a set of Identities. An identity has a SSK URI, a nick name, a set > of contexts (and a set of properties). An "own identity" is an identity of the > user of the plugin, he owns the SSK insert URI so he can insert the identity. > > - Each identity can offer a Set<String> of contexts. A context is a client > application, currently there are: "Introduction" (the > given identity publishes captchas to allow other identities to get known by > the web of trust by solving a captcha - if you solve one, you get on the > publisher's trust list) and "Freetalk", which is the messaging system based on > WoT (comparable to FMS) which I am implementing. > > - Identities currently can give each users a trust value from -100 to +100. > Each trust relationship is stored as a object of class Trust in the database. > > - From all Trust values an identity has received, from the trust values the > trusters have received, etc. the WoT calculates and stores a "Score" object > for each identity in the database. The score is the calculated rating the > which identity receives from the whole of the other identities. > > Not only one Score object is stored - for each pair of [OWN identity > "treeOwner", identity "target"] a score object is calculated. The reason is > that the score of an identity depends on what trust the treeOwner gives to the > identity itself, what trust its trusters have received, their trusters, and so > on. > > .... Considering the fact that there will be many more client applications > (for example: Search indexing, files haring, web of trust based code review > (image Freenet compiling its updates itself as soon as all code has received > enough "review trust")). we came to the conclusion that it must be possible to > assign a trust value which is only valid in the context of a single client > application and does not affect any others. If someone publishes crap in the > file sharing that does not prove that he is not able to produce nice messages > in Freetalk, and vice versa. > > Therefore, I will implement per-context trust and score now. I will not wait > with the implementation until Freetalk even though Freetalk is important > because the per-context trust values change the database model very much and > writing code to convert legacy databases is possible but not guaranteed to not > have any bad side effects. Having a "finished" database model before deploying > stuff is a good idea. > > Now the question is: Which logic should be used to decide when to ignore an > identity, i.e. when to NOT download it anymore and not add the identities > which it trusts to the database? > Several ideas: > - Have a global "trust list trust" as in FMS which is a rating of whether the > identity as a whole is trustworthy and should be downloaded, only decide upon > the score value there whether to download it or not, ignoring all scores from > client apps. > - Download it as long as ONE client app has positive score for that identity: > Not possible because then someone could create zillions of spam identities to > spam the WoT and keep every WoT-plugin downloading them by writing good posts > in Freetalk but not adding the Freetalk context to the spam identities so > Freetalk users might not notice them. In general, this attack could be used > with any other client app where it is easy to gather positive trust. > - Download as long as ALL client apps have positive trust: Not possible, the > whole goal of per-context trust was to prevent identities from being judged as > a whole just by their misbehavior in ONE client app. > > - Any other ideas by anyone? > > - Because I do not have any other ideas, I came to the conclusion that it is > necessary to have a separate "global" trust context (could be called > "TrustList" or "WoT" or whatever) which is used to judge whether an identity > should be downloaded or not. This means that each client app will need UI to > manage 2 trust values per identity. This sucks in terms of usability and I'd > like to prevent it, yet IF we want to prevent it someone must come up with a > smart idea for the "download decision". > > So does anyone has an idea which prevents the need of a "global" trust > context? If not, I will implement it with the global context and call it > "TrustList". > > Greetings, xor > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090507/7803cb38/attachment.pgp>
