|
Register | FAQ | The Twelve Commandments | Members List | Calendar | Arcade | Find the Best VPN | Today's Posts | Search |
General Gnutella / Gnutella Network Discussion For general discussion about Gnutella and the Gnutella network. For discussion about a specific Gnutella client program, please post in one of the client forums above. |
| LinkBack | Thread Tools | Display Modes |
| |||
Don't invite RIAA into your home -- a modified P2P concept I've been thinking about a way to invite only those you want into your computer and to keep out RIAA and other undesireables. Here's the basic idea. Any comments? IOP2P -- Invitation Only Peer To Peer A man's home is his castle -- he can invite anyone he wants to share his home or exclude anyone he doesn't. A man's networked computer is the same way. Currently most peer-to-peer networks open the owner's computer to anyone and everyone. Yet it is very simple to restrict who can enter and the terms under which they can enter -- hence "invitation only." Of course in inviting someone into your house, you needn't have initiated the request -- anyone can ask to be invited -- the actual invitation comes in responding positively to the request. The model of IOP2P, then, is standardized request for invitation (RFI) text followed by an invitational acknowledgement (IA). Take an example of a network of private computers wishing to share manuscripts by invitation. A potential invitee sends the search terms of the manuscript he is looking for along with a header text that is a standardized request for an invitation to other computer owners on the network. They verify the terms of the request for invitation, then search their manuscript database for matches, and finding any, return the search matches along with an invitation acknowledgment header. The searcher, thus being invited under the terms of the request he submitted, is allowed to see the search matches or request the manuscript content. The request for invitation text should be standardized so that the inviter computer can recognized it and respond to the invitee appropriately. The text should be transmitted in unencrypted plain text. An example: "I request an invitation to search your database at IP address 63.242.18.29 for item matches and viewing of matching content. I am not a member of the Nazi Party or Philadelphia Rotary Club. I am not acting in the employ of any government or corporation. The information viewed by the granting of this request for invitation to view will not be divulged to anyone else who has not also agreed to and meets the terms of this request. My computer is identified by the IP address 192.168.1.2 : 63.240.76.19" (Note the dual invitee IP address. Some invitee computers are behind NAT routers. Invitations should be issued to specific requesting computers, not to networks. The only way to specify a computer uniquely in that case is to pair up the local IP address and the NAT router IP address.) In reply to the request, the inviter computer echoes the terms of the requested for invitation: "You, at IP address 192.168.1.2 : 63.240.76.19I are invited to search the database here at IP address 63.242.18.29 for item matches and viewing of matching content. You've agreed you are not a member of the Nazi Party or Philadelphia Rotary Club. You've agreed you are not acting in the employ of any government or corporation. You've agreed that the information viewed by this invitation to view will not be divulged to anyone else who has not also agreed to and meets the terms of your request." For robustness, the request for invitation header should be attached to all search requests and all content requests. All search returns and content viewings should have an invitation acknowledge header attached as well. This prevents the possibility of the attempted fooling the state machine of the inviter computer into sending content uninvited and thus unprotected by terms of an invitation. Additional refinements would include sending an encryption key in the invitation acknowledgement header used under the terms of the header for decryption of the search matches and content viewing. If content is encrypted it prevents third parties from snooping the network and viewing the content without specifically accepting the agreement terms in order to parse the decryption key and decrypt the content. In this way they can't claim accidental discovery, as they have to take specific steps to decrypt the content in order to recognize it. IOP2P can be easily overlaid onto many existing P2P networks. It doesn't change the general operation of most networks, it just adds a header and text verification to existing P2P networks. In fact it can co-exist on a standard P2P network, in that it would reply to IOP2P invitee requests and transparently ignore older P2P requests. |
| |||
I think a good RIAA bot could even forge those requests for invitations. That aside, I don't know many people who would want to invite each and everyone who could want to download from them manually, so you'd probably have a lot of leechers. In addition your network must be very small or people with big pipes will see thousands of RFIs a day. And what about people with dynamic IPs? |
| |||
It would all be automated. Of course the RIAA could send such requests, but they'd have to lie. Gaining entry under false pretenses in order to see what you have in your computer would undercut their civil case. Invitation only requires a criminal search warrant to circuvent. No one has a legal authority to falsely gain access to your home or computer contents. It is only by invitation or by court authorized search warrant. The concept here is to establish the terms of entry. A contract if you will. It is all automated -- you could add this capability to standard Gnutella clients. The mere fact that the request and invitation are well known as part of the protocol would mean that people such as RIAA could not have a good faith excuse to look into anyone's computer file shares. They could only see the contents by lying about who they were -- false pretenses which undercut their civil case because they had to engage in fraud to gain entry. |
| |||
Quote:
|
| |||
Quote:
|
| |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Oldfashioned concept? | Unregistered | Gtk-Gnutella (Linux/Unix/Mac OSX/Windows) | 21 | July 16th, 2006 09:09 PM |
:::Can Phex be modified to...::: | geekcube | General Discussion | 3 | July 2nd, 2006 09:45 AM |
cabos and acqlite: using LW core modified by heavy_baby | et voilą | Open Discussion topics | 13 | July 18th, 2005 09:01 PM |
Anti-RIAA Attack Concept | schnarff | General P2P Network Discussion | 4 | August 6th, 2003 04:46 AM |
I/O socket and thread concept in servants? | Moak | General Gnutella Development Discussion | 8 | January 25th, 2002 04:38 AM |