why don't we need access control ?

[connectdotz]

Every time an access-control topic came up, it was always tangled with "violation of permanent-web", "distributed-vs-centralized oversight", "deny list" etc. I am not sure we have explicitly distinguished the issue between the content-owner vs. public... While it is debatable if the public should or could impose collective decisions in a truly distributed/decentralized system, I hope we can all agree that the network should honor the content-own's intent...

I wonder, thus ask, shouldn't TTL/ACL be considered as part of the content that IPFS should honor, just like the rest of the data they shared today?...

does this violate the IPFS principle?

• permanent-web: consider TTL/ACL, like a header, would be signed as part of the content, all hash/merkledag mechanism can remain unchanged. Once it is published, nobody can change the header nor the body, just like before.
• big-brother oversight: none, there is no big brother, each file provider create their own headers or none.

Should this be enforced in the protocol layer or a voluntary-outer layer like the deny-list?

• I would argue this should be enforced by the protocol because it is part of the content, thus network, integrity.

can't this be done via private network?

• private network operates on the network/node level, what we need is on the content/file level.

Why should IPFS consider this?

• enable new use cases, such as short-lived messages, group-sharing publication, just to name a few.
• address one of the main adoption barriers - "how do I make sure my file is no longer in the network?" - especially for people/business consider IPFS for private/controlled data access.
• reduce unnecessary resource - storage and traffic. While the traditional IPFS answer for this is resource consumption is (public) demand-driven, IMHO, we fail to look at this from the content owners' perspective...

In short, I think if we could extend the protocol to support something like a header that includes TTL/ACL, it could make IPFS network more scalable and encouraging greater adoption, without compromising its core principle.

Not sure if similar topic has been debated in the past, if not, thoughts?

[Stebalien]

We definitely need some kind of access control (or capability) system for private content. Publishers need to be able to restrict access to enable use-cases like dropbox.

With respect to TTLs, IPFS will soon-(ish) be getting arbitrary metadata for files. Applications could put TTLs in this metadata and choose to honor it (or not). This could be especially useful for, as you say, resource management. For example, the IPFS daemon could remove expired and un-pinned files to free up space.

address one of the main adoption barriers - "how do I make sure my file is no longer in the network?" - especially for people/business consider IPFS for private/controlled data access.

This simply isn't something we can address and is something people need to accept. If you publish something anywhere (ipfs, web, a book, etc.), it's out there and beyond your control. You can ask that it be taken down via legal and/or social means but there's no technological solution. Any product that claims to solve this is lying and giving users a false sense of security.

Really, access control is the best/only answer to this issue as well.

[fredericomba]

While trying to design a message board using IPFS as base, I stumbled across the access control problem and reached this thread. I was expecting that IPFS does not have access control. How could it possibly have something like it? Once the data has been seen by one user, it is public, because it can simply be copied.

However, not all is lost. I had this solution on top of IPFS:

• All messages on the message board are private by default.
• Because all messages are private by default, all of them are encrypted by default.
• Only those that have been authorized to see the message get the decryption key.
• The encryption or decryption keys are never stored on IPFS. They are stored in a separate application (an SQL database or something similar) that enforces the access control.

So, if a message on the message board leaks, that is certainly because someone inside the message board has leaked it. I won't attempt to prevent this (because a simple screenshot of a post in a message board is enough to leak it), but this is one possible solution for access control in the present IPFS.

[hsanjuan]

However, not all is lost. I had this solution on top of IPFS:

* All messages on the message board are private by default.

* Because all messages are private by default, all of them are encrypted by default.

* Only those that have been authorized to see the message get the decryption key.

* The encryption or decryption keys are never stored on IPFS. They are stored in a separate application (an SQL database or something similar) that enforces the access control.

A common reference here are the textile folks who have written a lot on how to do these things (encryption and access):

https://blog.textile.io/the-5-steps-to-end-to-end-encrypted-photo-storage-and-sharing/

https://blog.textile.io/introducing-textiles-threads-protocol/

[ianopolous]

If you want server-less access control (no server needed to enforce anything and no secret keys stored in sql anywhere) then look at the capability system we use in Peergos, which is based on cryptree. This has been audited by Cure53.

What about encrypting the data in transit?
I haven't studied the IPFS source in detail, so please take with a grain of salt, but maybe outbound blocks could be encrypted as they go out and wrapped in an envelope that includes both the pre/post encryption hash. The recipient could be given the key beforehand or provide a token/key themselves that can be checked against an ACL.

[Stebalien]

Connections are already encrypted.