Hacker News Reader

Comment by sneak | Hacker News Reader

A gateway is a bridge from http to ipfs. Not all nodes are gateways.

But all gateways are nodes. Of course, unless we're talking CSAM, no one will be targeting arbitrary nodes. But gateways are, by definition, the publishers of what's in IPFS. They are frontends to the same backend - and thus it makes sense for each of them to be liable for everything that's on the backend, i.e. the whole IPFS network.

Ehh... Does it make sense in the same way that TOR exit nodes are liable for everything on TOR, or that VPN providers are liable for everything that is downloaded via the VPN or that the ISP is liable for everything that its users download?

I think that's why DMCA safe harbor exists, and it could be argued that an IPFS gateway is acting as an OSP (in fact, it's almost text-book[1]).

Though, at this point, it seems that DMCA is skewed almost exclusively in favor of rights holders (or indeed anyone simply claiming to be a rights holder), that unless you're Comcast or Verizon or something, you're not going to get much sympathy from the legal system by claiming to be an OSP.

[1] https://en.wikipedia.org/wiki/Online_service_provider

VPN providers and TOR exit nodes are a different beast, IMO. They're potentially liable for everything that goes through them, but it's a "push" model, not a "pull" one. Plenty of organizations don't want to interact with, or intermediate in hosting, TOR exit nodes, because they fear any kind of illegal thing could come through those nodes - but until something specific does come out, that's a risk management reason, not a legal reason.

In contrast, IPFS gateways are running on a "pull" model. Anyone can come to the gateway, and pull through it anything that's stored anywhere in the IPFS network. This is meaningfully different, in the same way "users could post illegal/infringing content to YouTube" is different from "there exist illegal/infringing content on YouTube already posted, available to anyone who know the ID to put in the URL". In the former case, possibility of "bad" upload doesn't create a problem until such upload actually happens; in the latter case, possibility of a "bad" download is a problem even if, so far, no one actually downloaded the "bad" thing.

> I think that's why DMCA safe harbor exists, and it could be argued that an IPFS gateway is acting as an OSP

I don't have any argument against that. I assume this wasn't tested in courts yet, and the rights holders are exploiting this uncertainty, expecting that no IPFS gateway operator will try to contest the DMCA claims.

I don't understand what you mean by push/pull in this context. Aren't I pulling content through a VPN or TOR exit node? Pulling content through my ISP?

> expecting that no IPFS gateway operator will try to contest the DMCA claims.

Unfortunately, even if you have a case, there are substantial legal costs involved.

> I don't understand what you mean by push/pull in this context. Aren't I pulling content through a VPN or TOR exit node? Pulling content through my ISP?

I thought this was clarifying it well:

This is meaningfully different, in the same way "users could post illegal/infringing content to YouTube" is different from "there exist illegal/infringing content on YouTube already posted, available to anyone who know the ID to put in the URL".

But maybe it's not, or maybe I'm making a category error here?

I see what you're saying. You push content onto IPFS but you access it over HTTP using an IPFS gateway, which pulls content off an IPFS node and basically "streams" it to the client. The IPFS gateway is acting only as a proxy to IPFS itself. IPFS clients can also download directly from IPFS but IPFS is not natively supported in a browser like HTTP(S) is.

The content itself is stored on IPFS nodes which "pin" the content they wish to persist on the network. I think there would be grounds under DMCA to ask IPFS pinning services to stop pinning copyrighted materials, but going after the gateways seems misguided and a misuse of DMCA, as they're only acting as a proxy.

'xoa actually explained what I meant better than I could: https://news.ycombinator.com/item?id=36480081

If you take IPFS for what it was designed to be - one big, distributed, content-addressable file system, then each individual IPFS gateway is effectively a server that serves that entire file system.

Whether or not this is abuse of DMCA, I can't tell, though I feel it indeed is. It does make sense from practical point of view, though. From the point of view of the rights owners, IPFS by itself is, at the moment, too small and too nerdy to be of significance - however, gateways are projecting IPFS into the Internet inhabited by general population, and in doing that, they look like servers serving content. They're good targets because they're how most people would access copyrighted material stored in IPFS.

xoa is kind of correct in describing IPFS as a giant CDN but there's a key difference here between IPFS and "IPFS gateways".

IPFS gateways don't host any files, they act in the exact way that xoas comment talks about.

> They don't host content, they don't discriminate, they just route traffic.

Indeed an IPFS gateway does not "host" content either, it merely shifts bits around in the same way a proxy or VPN shifts bits around. It's not correct to say that when you're connected to a VPN that your VPN provider is hosting Google or Netflix, it's the exact same with IPFS gateways.

The only difference between IPFS gateways and a proxy in that sense is that a proxy serves the client HTTP content from a HTTP source whereas an IPFS gateway serves HTTP content from an IPFS source.

Equivalently imagine a proxy that could proxy traffic from any publicly accessible FTP server to HTTP. Is it correct to say that the proxy is hosting the content that resides on the FTP? No, it's not. The FTP server is hosting the content and the proxy is piping it to clients from FTP->HTTP without storing anything.

I think the difference is that FTP is historically known and easy to use with generic tooling. Or at least it was so a decade ago. Today, in fact, I bet that if you made a website that's fronting someone else's FTP server, it's you who'd get hit with DMCA first. IPFS is public only for a small subset of techies - at this point, for anyone else, it's some mystery alternate realm they don't have access to. This is not a theoretical issue, but a purely pragmatic one - but legal action is also mostly taken on practical grounds, not theoretical. Thus, obscurity of the tech involved matters.

This is late but I don't think "push/pull" is very clear terminology here, and confuses things a lot. The difference rather is that VPNs/TOR are ISPs, or more generally they're Common Carriers. They don't host content, they don't discriminate, they just route traffic. So Section 230 or the DMCA doesn't even apply, just regular common carrier rules. They're not liable for what goes through them short of actual knowledge or defiance of a legitimate court order, but the nature of encryption means they won't generally have any way to know or technical means. They're just infrastructure. To get content off of a VPN or TOR, someone must go to some actual server that serves said content, whether it be on the general internet or a hidden service. It's that server and user that are the liable parties. There are some edge cases, and of course differences in law for other countries, but overall they're an established thing.

IPFS in contrast would be a CDN. It actually hosts content, that's the point, it's a massively distributed filesystem. I can see that creating new legal arguments separate from pure network infrastructure.

Thank you for posting it. This is exactly the distinction I meant, and from now on, I'll be describing it the way you did - ISP/Common Carrier vs. CDN.

Reply on news.ycombinator.com