-3

I know that P2P sharing is copying the exact content between the peers. Everyone has the same data.

Let's assume the content is very important and I don't want anyone to distribute outside the group. only those who got access to the material can only download.

When anyone downloads the content. The material gets marked with a unique Identifier Like a meta data or something.

If someone shares it. I would be able to identify who did it and kick him out of the group.

I believe this against the protocol of P2P. But I'm asking if there could be a way to do it or will this require changing the protocol itself?

4
  • 1
    Your idea won't work. All I need to do is to get two "users" in your group, compare the data I receive from both of them and distribute the common subset. Dec 30 '21 at 15:45
  • This would be hard to achieve with a lot of material and also a lot of users
    – JackUP
    Dec 30 '21 at 16:04
  • 3
    What I do with the data once I get it is not something BitTorrent controls or is aware of. If I turn around and share it on BitTorrent again BitTorrent knows what IP I’m using. But nothing ensures that will be the same ip. No protocol defeats the sneaker net. Dec 30 '21 at 16:05
  • Not exclusively sharing it again on Bittorrent. You could simply hand it to a friend or someone decided to pirate it and share it online. I'm keen on knowing that. can't find an effortless way to accomplish this.
    – JackUP
    Dec 30 '21 at 16:08
0

What you want is not a viable method for protecting anything, even if you could get a particular P2P program to work this way.

If you're dealing with a file format that you don't control (images, video files, etc), then your metadata ID would have to be part of that format. Which means it would be trivial to edit it.

If you establish a file format (along with the various apps needed to then use this file), then it would not be difficult for people to de-process the format and figure out where your ID is stored. You can try to use a checksum or something to ensure that the ID is unchanged, but this too is pretty easy to get around.

If you go for full-on encryption of the data and the ID... well, some program on the user's hardware is going to have to be able to decrypt it. Which means they can snatch the decrypted data right out of memory sans ID. You can use clever techniques to make this easier or harder on the user, but ultimately, so long as enough people have a desire to break your code, they will.

Also, doing P2P with fully encrypted data would be painful for all of the peers in terms of drive space. Since the ID would be folded into the encrypted portion of the data, to be able to send your copy of the data to a peer, you have to have a version of the data that is identified for that peer. Which means that, for each identified peer that you "share" with, you're going to have to basically have a separate copy of the data tailored to their ID.

I don't think people will want to do that.

This is why, when you see people doing things like this, they will put identifying info in the datastream itself. There have been attempts to track down leakers by placing small, barely audible modulations in a sound stream that uniquely identify where it came from. Or they'll use special bugs in the corner of video streams. Or whatever. And even then, they won't do it on a per-peer basis; they'll do it to the list of "trusted" agents who aren't supposed to leak the information. The goal is not to track down every person who shared it; it's to find the origin of the leak.

2
  • Thank you for taking the time to write this long explanation. I really appreciate it. Anyway, I can say that I use a similar approach to your last paragraph. However, It is painful and time consuming to catch those leakers but have been efficient for the past few months. I don't intend into fully encrypted or hard-to-decrypt system. For now, All I want is a simple Unique identifier way to check it with those who aren't able to decrypt it or not checking the checksum or the Meta Data. If people find out how to decrypt it. I will be fine with it. will look later for alternative.
    – JackUP
    Dec 30 '21 at 18:54
  • This may be an idiot approach to think of before designing a software but I know my members and I know how this is going to help if it works.
    – JackUP
    Dec 30 '21 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.