> Since Twister is a µblog service, I would consider a successful attack everything > where a message gets delayed by more than 15 minutes (imagine twister > being used to organise a political rally). one example: I am in a restrictive environment and I am currently seeing for @b0t delays of a few days, the maximum so far being 2 weeks, without the deny relay feature being implemented yet.
On Sat, Sep 12, 2015 at 9:38 AM, Francesco Ariis <[email protected]> wrote: > On Sat, Sep 12, 2015 at 07:39:50AM +0100, Cathal (Phone) wrote: > > If they could, then they wouldn't need help.from the twister team. > > > > The requested feature is a *refusal to relay*, it has no bearing on > other nodes. If this were useful for an *attack* then it'd be trivial to > code a fake node to do just that: connect and not relay. > > > > In P2P unless you trust a node, you never trust a node. So anyone > trusting a set of nodes to tell them the whole story will have a bad day. > If ye want child porn in a world where non-monsters can choose not to relay > it, you'd better keep hunting for nodes willing to share child porn with > you. > > > > The tragwdy of the commons is that in the absence of mechanisms for a > community to protect it, a common resource usually ends up abused. This is > a democratic and anarchic way to protect the commons of free speech and > thought from abuse before it becomes known as just > yet-another-refuge-for-cp. > > > > Hello Cathal, > thanks for your reply. > > If I am reading your message correctly, you say: "It doesn't matter, > because even if it mattered, a malicious user could implement this > trivially by themselves today, without anyone being able to detect it". > I appreciate the explanation and would personally add: "*if* it matters, > we need to find a way to prevent this kind of attack". Since Twister > is a µblog service, I would consider a successful attack everything > where a message gets delayed by more than 15 minutes (imagine twister > being used to organise a political rally). > But as I said I am quite ignorant on the inner mechanism of Twister, > so I don't know if this is even possible (but you showed it is *not > related* to the particular feature requested). > > I'll share with you another thought I had. I think everyone in this > ML used TOR at least once (I see you suggest it as 'the ultimate > anti-censorship technology' in your blog). > Well, if we are to run an onion-router, there is a risk (I would say > certainty) that a non-zero number of packets will contain illegal, > morally abject or even terrorism related material. If every > onion-router provider said "I don't want to risk retransmitting > those", the whole network would be impaired in its primary goal > (letting political dissenters retrieve/publish information without > being identified, etc.). > I am not saying that this related 1:1 to the case at hand (it doesn't > translate well really, in one case the information is overt, in the > tor-case we just 'peel' one layer of encryption), but that's a > simple example where the _very_ understandable behaviour of many would > influence the network as a whole. > > To Erkan and the proponents of the 'censorship-resilience is not open > for debate' folks: imagine a scenario where a malicious party floods > twister with a ton of gibberish material, rendering the transmission > ineffective or very very slow. Wouldn't it be reasonable to block > those nodes then? And even share a block-list to make the process > speedier? > > What I am trying to convey with those two examples is that it might > be not easy to foresee the results of our intents (those intents > can come in the form of code or behaviours). > > To state how I feel about the issue: I think to let every node > decide what/what not to relay is a valid request, from an ethical > point of view (don't force someone to do what they don't want to > do) and from a technical point of view (you won't be able to control > this anyway). > Twister is a nice piece of software, I hope the community can come > up with a solution everyone can stand behind. > > -- > You received this message because you are subscribed to the Google Groups > "twister-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > ********************************************************************************************** This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese eMail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************************************** -- You received this message because you are subscribed to the Google Groups "twister-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
