undefined | Better HN

0 pointsfizzbatter9y ago0 comments

> 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.

0 comments

3 comments · 1 top-level

clueless4049y ago· 2 in thread

> 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?

fizzbatterOP9y ago

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.

clueless4049y ago

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 :)

1 more reply

j / k navigate · click thread line to collapse