Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, that is fair. I'm mainly talking about "normal" adoption though.

Eg, for a long time BitTorrent was being branded as a pirate haven. The only major players i saw adopt BitTorrent were open source projects needing to distribute large ISOs. IPFS is something that they're trying to get into standards, into browsers, into operating systems, etc. If it's known for distributing kiddy porn on the dark net it will be much more difficult.

I know piracy spreads like wildfire, but it's not really the target audience for what IPFS is trying to do. In short, they want YouTube, not PirateBay. Or so i gather, at least.

Do you disagree?



If IPFS wants get gain traction and go mainstream, they still have you address the kiddy porn and piracy issue.

You can't go downloading and seeding random hashes if this exposes you to criminal charges and/or law suites.


They are addressing it, but it's a future feature. Last i saw on Github issues (it likely has evolved since then), they plan to have a central authority which allows for DMCAs/reports/etc of illegal content. The network then propagates an ignore list of sorts (or possibly watches a central list).

Any nodes on the network which abide by this will simply not download and/or unpin the data.

It doesn't prevent you from downloading some kiddy porn that a stranger sent you.. but neither does the internet. This, is purely to allow law to take place, and hopefully allow lawmakers to work with IPFS, and not block the whole damn thing.


It's ironic that IPFS plans on using a central service to censor and purge it's distributed system.

Not that this central authority will solve this issue either. It just opens another can of worms.

Who will review claims and reports? Who will be authorized to add hashes to the blacklist? How will counternotices be handled? How will different juridistictions and conflicting laws be handled? Who will be liable for content that makes it past the filters? Who will pay for all this?

The world is a messy place and IPFS does nothing to protect its users.


> The world is a messy place and IPFS does nothing to protect its users.

I'm a bit confused, why is it the job of IPFS to "protect its users"? IPFS has no liability here, it's simply trying to make IPFS a law-abiding software as a whole. So it is not outlawed.

IPFS doesn't have any reason to "protect" me from things i download anymore than HTTP or TPC does. It's a technology for localizing data. What makes you feel IPFS has to protect its users?

It sounds like you think IPFS somehow spreads files onto your system without your consent. You only download what you choose to, just like with HTTP/TPC/UPD and the whole tech stack.

IPFS changes nothing for your personal security. It's not intended to. It's a technology to lower bandwidth usage from the production of mass data in the current age. And in regards to it being ironic for having a central authority, - sure - but the problem is bandwidth that IPFS is aiming to solve is, not law and/or DMCAs.

IPFS must have some seriously bad marketing (i blame the whole "good for humanity angle"), because i feel like you and a lot of people have the entirely wrong idea about IPFS. It's a technology, nothing more.. especially in it's current form. The only thing it might "save the world" from is bandwidth, lol.


IPFS needs to protect its users, if it is to have any users.

The creators of IPFS may not have any liability, but they open up its users to severe issues of liability due to the way it operates.

IPFS will become toxic real quick, if it becomes know that IPFS can make you an unintentional distributor of kiddy porn and pirated content.

The core problem is that IPFS' default mode of operation is actively user hostile. This is a big problem, and the reason IPFS needs to protect its users. IPFS not only leaks what you retrieve, it also makes you an (unknowing) distributior of everything you retrieve. All it takes for you to commit a crime and/or copyright infringement, not only as a consumer but also a as a distributor, is to be tricked into retrieving one hash.

In conclusion, IPFS needs not only to not be outlawed, it also needs to be safe to use. As it is IPFS is not safe to use. Hence IPFS needs to do something to become safe to use, i.e. to protect its users.


> IPFS will become toxic real quick, if it becomes know that IPFS can make you an unintentional distributor of kiddy porn and pirated content.

Yea, this is where you're mistaken. It cannot make you distribute anything! You only distribute what you download. Don't download kiddy porn, and you won't distribute kiddy porn.

> All it takes for you to commit a crime and/or copyright infringement, not only as a consumer but also a as a distributor, is to be tricked into retrieving one hash.

That is fair - but the same could be said for every p2p system on the planet. Has anyone solved this problem? How does BitTorrent protect me from unknowingly downloading kiddy porn?


> Yea, this is where you're mistaken. It cannot make you distribute anything!

Oh, really?

"In some cases, nodes must work for their blocks. In the case that a node has nothing that its peers want (or nothing at all), it seeks the pieces its peers want, with lower priority than what the node wants itself. This incentivizes nodes to cache and disseminate rare pieces, even if they are not interested in them directly."

https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs...

What's to say BitSwap won't proactively decide to download and start seeding some rare pieces of kiddy porn?

> You only distribute what you download.

As if that wasn't bad enough.

> Don't download kiddy porn, and you won't distribute kiddy porn.

How are you to know if a hash contains kiddy porn or not?

You need to know if the hash contains kiddy porn before you download it, but to know if it contains kiddy porn you have to download it. Classic Catch-22.

The only rational response to a system like this is not to use it.

> How does BitTorrent protect me from unknowingly downloading kiddy porn?

By not randomly downloading stuff from the Internet. By only downloading torrents, I have explicitly chosen to retrieve (hopefully from vetted and reputable sources). By giving me complete control and feedback on what I'm seeding.

Obviously not ideal, but far better than what IPFS does.

I also don't get how this central censorship authority is going to work. I very much doubt IPFS wants to become the Internet Police for Saudi Arabia.

The whole thing is a futile attempt to appease lawmakers and dictators, since any filtering will be done clientside. Nothing is stopping the client from ignoring any blacklists.

Any great or small firewall will just find it easier to block the whole thing than do some silly whack-a-mole deep packet inspection.

How is IPFS not going to become a haven for kiddy porn aficionados?

If the censorship authority publishes a list of blacklisted hashes, that's the same as publishing a directory of all the available kiddy porn. Oops!

If the censorship authority requires each hash to be queried individually, it becomes a real honeypot for the state surveillance machinery.

Not exactly great choices.


> What's to say BitSwap won't proactively decide to download and start seeding some rare pieces of kiddy porn?

Nice catch, that is interesting. Granted, i feel like this could be tweaked as it is simply a mechanic to attempt to reduce leeching on the network.

> You need to know if the hash contains kiddy porn before you download it, but to know if it contains kiddy porn you have to download it. Classic Catch-22.

How do you know if that link to a pdf from a friend contains kiddy porn? You need to download it to check the md5 / contents.

I'm really lost on how this is any different than HTTP/BitTorrent/etc. Any link on the web can be kiddy. Any bittorrent link can be kiddy. Any IPFS link can be kiddy. They're all equally dangerous on that front as i see it.

The only argument i feel like can be made on this front, is that the hash can make for a hard to visually decipher file. Ie, `foo.com/bar.pdf` is inherently more "trust worthy" than `/ipfs/d3b07384d113edec49eaa6238ad5ff00`. With that said though, that's a better reason to not use `/ipfs/d3b07384d113edec49eaa6238ad5ff00` than it is to use `/ipns/foo.com/bar.pdf` (fake domain/example for easy discussion).

Again, stay away from random hashes just like you stay away from sketchy torrents and random http files.


> Granted, i feel like this could be tweaked as it is simply a mechanic to attempt to reduce leeching on the network.

How do you propose tweaking it without either publishing a directory of all the kiddy porn on IPFS or creating a bottleneck which incidentally is ideal for tracking and surveillance?

> How do you know if that link to a pdf from a friend contains kiddy porn?

You don't, but at least your browser won't shout out to the world: "Hey, everybody! This guy is downloading kiddy porn! IPFS does that and to add insult to injury then automatically goes on to seed it.

On the web you also have a sense of where you are. With IPFS you don't, it's all a bunch of hashes. There is no there there. There are no clues to tell you that you are in a seedy neighborhood. Everything is just available, one hash away, from kiddy porn to fine art. That makes navigating IPFSpace such a minefield, the next hash could take you anywhere.

> I'm really lost on how this is any different than HTTP/BitTorrent/etc.

Let me recap:

- BitSwap

- metadata leakage

- automatic seeding

- opacity and lack of control

> Again, stay away from random hashes just like you stay away from sketchy torrents and random http files.

How? Is there some kind of sniff test I don't know about?


Fwiw, I appreciate your insight on this matter. I know we disagree on some points, but it was fruitful for me to see your perspective. Anyway:

> How do you propose tweaking it without either publishing a directory of all the kiddy porn on IPFS or creating a bottleneck which incidentally is ideal for tracking and surveillance?

Well this is off the cuff, because i wasn't aware of BitSwap's desire to seed in the event of no swap data.. but with that said, i was mainly just referring to alternate methods to help inhibit leeching.

Eg, allow leeching but only for the first (tiny) %x. How willing a host is to allow leeching should be up to them regardless. If i'm hosting a file i want to distribute for an open source network, it's in my interest to host it, and i'd rather not inhibit others from downloading what i'm providing them based on some BitSwap algorithm trying to make things "fair".

P2P is a tough challenge though, which is what that whole sketchy BitSwap section stems from. I imagine a beer and an hour and you could come up with a dozen alternate methods to discourage leeching. Whether or not they're as effective as requiring "work", is impossible for me to say.. but i think we both agree that the work outlined in that PDF is a bit.. sketchy.

> How? Is there some kind of sniff test I don't know about?

Well, i don't know about you - but i don't download random files on the internet. I download from trusted sources only. IPFS would be no different. A trusted web TLD or a trusted IPNS namespace would be good enough for me to feel it is trusted, in both accounts. Outside of trusted domains on the web, i don't download it. Eg, would you download 555.555.555.555/foo.pdf? I certainly wouldn't.

I think with IPFS it will become a bit defacto to trust IPNS rather than IPFS directly. Not only are hashes potentially dangerous, but they're simply a terrible UX. A parallel would be like downloading `555.555.555.555/foo.pdf` - you have no idea if that's kiddy porn or not, it's effectively a random hash. Don't download it.

A domain (like that IPNS is aiming to provide, i believe) would be more akin to `https://trusted-site.com/foo.pdf`. Long term, i don't think anyone should be using hashes directly. But that's just my 2c, we'll see how it plays out.


I, too, have enjoyed our discussion.

Moving towards IPNS namespaces would probably be a great start.

Example content sites like the below one (found in another comment) are a disaster just waiting to happen:

https://ipfs.io/ipfs/QmU5XsVwvJfTcCwqkK1SmTqDmXWSQWaTa7ZcVLY...

This brings us back to my original point. Even with trusted IPNS namespaces, IPFS needs to protect its users. If nothing else IPFS should have some kind of content policy engine that warns or blocks the user from unintentionally leaving safe namespaces and/or retrieving random hashes.

P.S. 555.555.555.555 isn't really a great example IP :)


> P.S. 555.555.555.555 isn't really a great example IP :)

I chose it because it made me think of the old 90s 555.555.5555 movie phones, haha.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: