Discrepancy between API (docs) and behaviour of privatebin.net regarding comments

[nain-F49FF806]

Describe the problem/question

On API page, comments are described as having status and url fields. This is also codified in comments.jsonld

But on https://privatebin.net instance, these fields are not returned for discussion comments.

Did you use the FAQ section?

• Yes, I have read the FAQ and I found no solution/answer there.

What you did?

1. I am adding support for comments in a third party client
2. I used the wiki pages to find documentation regarding comments.
   ...

What happens

The deserialisation for comments choked on not finding status and url fields.
The non-presence of these can be verified using browser dev tools.

What should happen

This was easily fixable client side, but it would be good to get documentation in line with the behaviour or vice versa.

Additional information

No response

Server address

https://privatebin.net

Server OS

n.a

Webserver

n.a

PrivateBin version

v1.7.1

Browser and version

n.a

Local operating system and version

n.a

Issue reproducibility

Yes, reproducible on https://privatebin.net.

[elrido]

I have retested the behaviour on the site and IMO it matches the API doc. Since you concluded differently, it clearly needs to be improved to avoid being misunderstood.

Here is what I observe when creating a paste with comments enabled and submitting a single comment. I copied the requests in curl format and the reply-bodies, so you should be able to replicate this also outside of a browser:

Create paste (POST)

curl 'https://privatebin.net/' --compressed -X POST -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: de-CH,de;q=0.8,en-GB;q=0.6,en-US;q=0.4,en;q=0.2' -H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'X-Requested-With: JSONHttpRequest' -H 'Origin: https://privatebin.net' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'TE: trailers' --data-raw '{"adata":[["ZGNEf32+99WQjoA57YjRWQ==","Q9zzHZb5kfw=",100000,256,128,"aes","gcm","zlib"],"plaintext",1,0],"meta":{"expire":"30min"},"v":2,"ct":"DfhbXK0wuWUK9W1Z3zH0f/7DSpf0e0kYa26fK4rfgD4cUA=="}'

{"status":0,"id":"ba7bf946a542eee1","url":"\/?ba7bf946a542eee1","deletetoken":"9914b0e934253e2e327f9a6477b99f6fff5d1e0e10d3d3bd08d4d9b6a20ab2ea"}

Read paste (GET)

curl 'https://privatebin.net/?pasteid=ba7bf946a542eee1' --compressed -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: de-CH,de;q=0.8,en-GB;q=0.6,en-US;q=0.4,en;q=0.2' -H 'Accept-Encoding: gzip, deflate, br' -H 'X-Requested-With: JSONHttpRequest' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: trailers'

{"status":0,"id":"ba7bf946a542eee1","url":"\/?ba7bf946a542eee1","adata":[["ZGNEf32+99WQjoA57YjRWQ==","Q9zzHZb5kfw=",100000,256,128,"aes","gcm","zlib"],"plaintext",1,0],"meta":{"created":1714070224,"time_to_live":550},"v":2,"ct":"DfhbXK0wuWUK9W1Z3zH0f\/7DSpf0e0kYa26fK4rfgD4cUA==","comments":[],"comment_count":0,"comment_offset":0,"@context":"?jsonld=paste"}

Create comment (POST)

curl 'https://privatebin.net/' --compressed -X POST -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: de-CH,de;q=0.8,en-GB;q=0.6,en-US;q=0.4,en;q=0.2' -H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'X-Requested-With: JSONHttpRequest' -H 'Origin: https://privatebin.net' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' --data-raw '{"pasteid":"ba7bf946a542eee1","parentid":"ba7bf946a542eee1","adata":["UaNSlJdwX/v5YCq/o1HKdw==","uDZs9IoXbPo=",100000,256,128,"aes","gcm","zlib"],"v":2,"ct":"1UeK4Cuu5YBHc1OUJ4+2PQTcu1EoQsK+yHh2wvDRWyyagvm2"}'

{"status":0,"id":"5e6c970dcab21155","url":"\/?5e6c970dcab21155"}

Read paste, again (GET)

curl 'https://privatebin.net/?pasteid=ba7bf946a542eee1' --compressed -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: de-CH,de;q=0.8,en-GB;q=0.6,en-US;q=0.4,en;q=0.2' -H 'Accept-Encoding: gzip, deflate, br' -H 'X-Requested-With: JSONHttpRequest' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'TE: trailers'

{"status":0,"id":"ba7bf946a542eee1","url":"\/?ba7bf946a542eee1","adata":[["ZGNEf32+99WQjoA57YjRWQ==","Q9zzHZb5kfw=",100000,256,128,"aes","gcm","zlib"],"plaintext",1,0],"meta":{"created":1714070224,"time_to_live":484},"v":2,"ct":"DfhbXK0wuWUK9W1Z3zH0f\/7DSpf0e0kYa26fK4rfgD4cUA==","comments":[{"adata":["UaNSlJdwX\/v5YCq\/o1HKdw==","uDZs9IoXbPo=",100000,256,128,"aes","gcm","zlib"],"v":2,"ct":"1UeK4Cuu5YBHc1OUJ4+2PQTcu1EoQsK+yHh2wvDRWyyagvm2","pasteid":"ba7bf946a542eee1","parentid":"ba7bf946a542eee1","meta":{"icon":"data:image\/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAIAAAC0tAIdAAAABnRSTlMAAAAAAABupgeRAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAN0lEQVQokWMMaHBggIENDQcYGBjwiDAxkAJIU82IbC+VzR6Bqjc0HIBEHi4RmsYlphBmqiLTbADcERL8gPykNgAAAABJRU5ErkJggg==","created":1714070340},"id":"5e6c970dcab21155"}],"comment_count":1,"comment_offset":0,"@context":"?jsonld=paste"}

Observations

• all responses to POST requests contain the documented status and url parameters
• replies to the GET request follow the JSONLD schema and are also self-documenting, they all contain a link in the @context property that resolves to the schema of that message
• the original GET for the paste contains no comments, later the comments array is populated
• there is no API call to fetch an individual comment, comments are returned with the paste (is this the bit that was not clear from the doc?)
• the schema of the paste is for example https://privatebin.net/?jsonld=paste and it refers to further schemas, including https://privatebin.net/?jsonld=types , https://privatebin.net/?jsonld=pastemeta and https://privatebin.net/?jsonld=comment , the latter of which also refers to https://privatebin.net/?jsonld=commentmeta - JSONLD is intended to be self describing within the messages
• the status message responded to by POST requests does not follow JSONLD, but is described in the Result column of the API doc page

Let us know which part of the above is in discrepancy with the document and could be clarified. Note that I am not a native English speaker, so I would also appreciate any suggestions on how to improve the wording, if that causes confusion.

[nain-F49FF806]

I concur with your observations. There is no issue with those.
The concern is regarding the comments array in Read paste, again (GET) section above. Quoting below

"comments":[{"adata":["UaNSlJdwX\/v5YCq\/o1HKdw==","uDZs9IoXbPo=",100000,256,128,"aes","gcm","zlib"],"v":2,"ct":"1UeK4Cuu5YBHc1OUJ4+2PQTcu1EoQsK+yHh2wvDRWyyagvm2","pasteid":"ba7bf946a542eee1","parentid":"ba7bf946a542eee1","meta":{"icon":"data:image\/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAIAAAC0tAIdAAAABnRSTlMAAAAAAABupgeRAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAN0lEQVQokWMMaHBggIENDQcYGBjwiDAxkAJIU82IbC+VzR6Bqjc0HIBEHi4RmsYlphBmqiLTbADcERL8gPykNgAAAABJRU5ErkJggg==","created":1714070340},"id":"5e6c970dcab21155"}]

I was expecting each element of the above comment array, to contain all properties defined in the comments.jsonld. But the comment elements do not contain (url, status).

Since url, status are returned only as result of a comment POST request, and are not part of the actual comments, maybe they shouldn't be in comment.jsonld ?

[elrido]

Sure, we can remove those. Thank you for clarifying.

[nain-F49FF806]

Hi, I hope am not troubling with presenting these findings. Do please let me know if it's a bother.

I found another possible, non-vital discrepancy.

The paste format describes the "created" meta property as returned only for comments (and not for pastes). But it seems to be returned for pastes too.

Thoughts:

• The documented behaviour (of not revealing creation time) could have been a small privacy feature.
• Small because by knowing time to live, we can still estimate creation time, in steps of expiration time provided by server. But it is still something, as the recipient may not be able to tell if it's fresh paste or very old.

  created_time_estimate =
    1 day - time to live / 
    1 week - time_to_live /
    1 month - time_to_live /
    ...
  

• For burn on read pastes, this would be perfect, as there is no need to provide time to live, the reader can't estimate creation time at all.
• The documented reason for having "created" on comments is for pagination. But this could as easily be done with a simple integer increment counter (rather than timestamp), since we only need an ordering. This would add to commenter privacy by not revealing exact comment creation time to readers.

Proposal 1: Chrono-privacy

• Do not return "created" on pastes, only ttl
• For comments, "created" can be an integer serial number, incremented on new comment. (1, 2, 3…).
• This would cause removal of time info from comments

Proposal 2: Useful meta (current)

• Leave behaviour as is. "created" can offer the helpful info to readers, that server already has
• Update documentation to reflect this

[elrido]

Hi, I hope am not troubling with presenting these findings. Do please let me know if it's a bother.

No, I think these items were simply never challenged and "have always been this way". It's difficult to notice these much when you've been working closely with a project and, to me, an outsiders perspective can be a breath of fresh air.

The paste format describes the "created" meta property as returned only for comments (and not for pastes). But it seems to be returned for pastes too.

So I tracked this a bit, also on how it was introduced and it is one that was always there (in v1 it was called "postdate"). It gets added by the server upon creation, but isn't used to calculate the expire_date one. Also, the database backend actively extracts and removes the created key (and others) and stores it in a different column than the paste, then re-adds these for reading. So it may get used internally for sorting of items, but doesn't need to get returned.

Thoughts:

* The documented behaviour (of not revealing creation time) could have been a small privacy feature.

And since I see no evidence of it being used by the client code (privatebin.js), I think I'll just raise branch that experimentally removes it at least in the API-output-side and validate/enforce this with a new unit test. I may explore if it can be safely removed from the data backends as well or not.

* The documented reason for having "created" on comments is for pagination. But this could as easily be done with a simple integer increment counter (rather than timestamp), since we only need an ordering. This would add to commenter privacy by not revealing exact comment creation time to readers.

To clarify on this, yes, this is what the comments internally get sorted by, but then we return the sorted list in the JSON and arrays in JSON have a fixed order, so we don't need it in the client code, where the order is just used as is.

Proposal 1: Chrono-privacy

* Do not return "created" on pastes, only ttl

Agreed

* For comments, "created" can be an integer serial number, incremented on new comment. (1, 2, 3…).

No, we can even remove it entirely. The array is already sorted at that point.

* This would cause removal of time info from comments

Good point. Ok, so this should then be an option. Admins can choose to remove that date and then the comments would need to remove the date, but would still get ordered by creation.

Proposal 2: Useful meta (current)

* Leave behaviour as is. "created" can offer the helpful info to readers, that server already has

* Update documentation to reflect this

I can not think of a use case for this, at least with the pastes. We would need to add a new code path to actually display it, but what would that bring in usability and as mentioned it is actually detrimental to the privacy of the paste creator.

[elrido]

@nain-F49FF806 please have a look at #1295 and comment regarding the comments - if we remove their create attribute, we should make it a configurable option to hide them in the discussion display, but server side they would still get tracked and stored, for the sorting.