Privatebin: Set expiration time separately for pastes with attachments/a bigger file size

[volfclub]

For servers, file storage pressure is much greater than text.

want, if only the plain text is pasted, it can never expire; once the user uploads the file, the file expires in one week, but the text can still be viewed.

[elrido]

Unfortunately, the server can't distinguish between text and file attachment. Since the goal of the project is to expose as little information as necessary, the paste format stores as much information as possible in the encrypted payload. The server doesn't even know if the paste contains an attachment or just a very large text. And without the key, as per the design, it can't decrypt the paste, check it's contents or re-encrypt the paste after deleting the file attachment.

[rugk]

That said, of course one could:

• only make it an “insecure” client-side only check, which may prevent easy “attacks!”, respectively many users from using a longer expiration time with full pastes
• or let the server decide the thing based on the paste size. I guess this can give a quite good estimation of the space and actually remedy's the overlaying problem.

Both may also be combined, so user errors are less likely to happen (big text is pasted by user in frontend, but server rejects large expiration time, due to large size – ok, that’s a problem you could never solve, but maybe the inverse with a small attachment) but in general it’s a lot of quite complex logic to implement, when you want all parts of the frontend and backend to properly work together,

[volfclub]

That said, of course one could:

• only make it an “insecure” client-side only check, which may prevent easy “attacks!”, respectively many users from using a longer expiration time with full pastes
• or let the server decide the thing based on the paste size. I guess this can give a quite good estimation of the space and actually remedy's the overlaying problem.

Both may also be combined, so user errors are less likely to happen (big text is pasted by user in frontend, but server rejects large expiration time, due to large size – ok, that’s a problem you could never solve, but maybe the inverse with a small attachment) but in general it’s a lot of quite complex logic to implement, when you want all parts of the frontend and backend to properly work together,

I have two ideas:

1. The browser web page makes restrictions. After the user clicks to upload a file, the expiration time option will automatically prohibit selecting a longer time. This may be easier to implement, allowing users to use the service more reasonably.

2. The server backend makes restrictions. When the user sends encrypted files that occupy too much space, the server automatically reduces the expiration time and reminds the user that the expiration time has been shortened because the file is too large. This may be safer.

[elrido]

Keep in mind that since PrivateBin has no user authentication concept, all storage class implementations and the API are designed to be write once - there is no way for the client to change the paste, once it got stored, and the only operation the server supports is the pastes complete deletion, if the delete token matches or the expiration time occurs, and appending comments to a paste (these are stored in separate files/table and can be deleted independently of the parent paste).

Option number 2 isn't easy to implement, as of version 2 of the paste format - we now store the metadata of the paste as part of the encryptions authenticated data. If the metadata were changed on the server side, the paste would fail to decrypt. The server therefore can't adjust the expiration time, only reject storing pastes, if they don't comply with it's rules. So you'd have to implement such a check on the client side and have the server enforce it.

Honestly, this really sounds like a very niche use case. Given that installing privatebin is trivial, I would just offer two instances (say in two folders of the same domain): One with no expiration, but no file uploads and a second instance with file uploads and limited expiration.

Additionally, the two instances could link to each other, via the notice configuration option, saying, for example "if you would like to share files, use other instance" / "if you would like to share texts without expiration, use main instance"

Optionally, both instances could share the data path, so you only have one storage location getting used / to back up / etc.

[volfclub]

Keep in mind that since PrivateBin has no user authentication concept, all storage class implementations and the API are designed to be write once - there is no way for the client to change the paste, once it got stored, and the only operation the server supports is the pastes complete deletion, if the delete token matches or the expiration time occurs, and appending comments to a paste (these are stored in separate files/table and can be deleted independently of the parent paste).

Option number 2 isn't easy to implement, as of version 2 of the paste format - we now store the metadata of the paste as part of the encryptions authenticated data. If the metadata were changed on the server side, the paste would fail to decrypt. The server therefore can't adjust the expiration time, only reject storing pastes, if they don't comply with it's rules. So you'd have to implement such a check on the client side and have the server enforce it.

Honestly, this really sounds like a very niche use case. Given that installing privatebin is trivial, I would just offer two instances (say in two folders of the same domain): One with no expiration, but no file uploads and a second instance with file uploads and limited expiration.

Additionally, the two instances could link to each other, via the notice configuration option, saying, for example "if you would like to share files, use other instance" / "if you would like to share texts without expiration, use main instance"

Optionally, both instances could share the data path, so you only have one storage location getting used / to back up / etc.

This is really a rude but very useful way, thx

[volfclub]

Keep in mind that since PrivateBin has no user authentication concept, all storage class implementations and the API are designed to be write once - there is no way for the client to change the paste, once it got stored, and the only operation the server supports is the pastes complete deletion, if the delete token matches or the expiration time occurs, and appending comments to a paste (these are stored in separate files/table and can be deleted independently of the parent paste).

Option number 2 isn't easy to implement, as of version 2 of the paste format - we now store the metadata of the paste as part of the encryptions authenticated data. If the metadata were changed on the server side, the paste would fail to decrypt. The server therefore can't adjust the expiration time, only reject storing pastes, if they don't comply with it's rules. So you'd have to implement such a check on the client side and have the server enforce it.

Honestly, this really sounds like a very niche use case. Given that installing privatebin is trivial, I would just offer two instances (say in two folders of the same domain): One with no expiration, but no file uploads and a second instance with file uploads and limited expiration.

Additionally, the two instances could link to each other, via the notice configuration option, saying, for example "if you would like to share files, use other instance" / "if you would like to share texts without expiration, use main instance"

Optionally, both instances could share the data path, so you only have one storage location getting used / to back up / etc.

Can I plug-in storage to solve the problem of shortage of storage space? Such as AWS

[rugk]

That is a complete other question (or possibly feature request), that should maybe be tackled in a new issue.

But TLDR is: Well… there is no built-in support (as Nextcloud has); but as long as you can connect to a remote database (for storage) or just some kind of mount in your file system, e.g. SFTP or whatever… you sure could.

That’s just a server administration question. PrivateBIn just stores the data in a database or in your filesystem.

[volfclub]

That is a complete other question (or possibly feature request), that should maybe be tackled in a new issue.

But TLDR is: Well… there is no built-in support (as Nextcloud has); but as long as you can connect to a remote database (for storage) or just some kind of mount in your file system, e.g. SFTP or whatever… you sure could.

That’s just a server administration question. PrivateBIn just stores the data in a database or in your filesystem.

Thank you very much, I just want to do my best to make my users more comfortable;）