discuss if we could remove the isBadBot() mechanism from legacy.js

It's okay. The only thing to clarify could be to label the button explicitly "Yes, load and burn" or so.

it doesn't prevent anyone from manually adding it to a regular URL to get it to ask for non burn after reading pastes (hence the slightly vague message)

That is a good idea and feature, actually, IMHO!
However, for a real proper localization, we can of course detect on the client-side if the paste was a self-destroy one (we have that information IIRC) and show a different message (aka more generic one), then.

However, for a real proper localization, we can of course detect on the client-side if the paste was a self-destroy one (we have that information IIRC) and show a different message (aka more generic one), then.

As a recipient of the link, you only learned if the paste is burn after reading after loading it. The server knows (so they can delete it), but we would need to add an additional non-destructive API for the client to learn this, and that of course undermines the concept of not leaving a trace (but would let us add a counter: "This paste has been visited but not opened X amount of times") - Anyhow, I don't think it would be worth the extra risk and complexity.

As a recipient of the link, you only learned if the paste is burn after reading after loading it

Ah okay, thanks. Then I mis-remembered that this may have been saved in the authenticated data part of the encryption.

Hi, the top comment says a character "?" is inserted after the "#", but the code seems to use "#-" as prefix.

Could you offer clarification on which character third party clients should look for?
Also, perhaps we should document the full structure of the fragment somewhere on the wiki.

Hi, the top comment says a character "?" is inserted after the "#", but the code seems to use "#-" as prefix.

Could you offer clarification on which character third party clients should look for? Also, perhaps we should document the full structure of the fragment somewhere on the wiki.

That was the initial suggestion, but after a discussion and considering various options and implication in the code review, we ended up changing it to the less ambiguous dash.

Edit: I've now added a description how to generate the URL to the format doc. It covers both the regular and this new URL type and how they are intended to get used, but also clarified that this is optional.

Thanks for the clarification! And the URL format description is very helpful. :)

I understand this is already in production. But since it's relatively new, I wanted to ask what you think of having the character as a suffix, rather than prefix?

Were there any strong arguments for having the character before the key and not after?

If it's in the suffix, the scheme could be extended for other custom options. Clients could always rely on the key being present first after the #, and to ignore anything after the - character if present.

Something like :

Without custom options (current default):

paste_url = privatebin_url + paste_id + "#" + encoded_key

With custom [client-side] options (hints):

paste_url = privatebin_url + paste_id + "#" + encoded_key + client_options 

Where client hints can be defined separately, and supporting them would be optional.

client_options:
    '-' : warn before read

It's a breaking change regardless, because previously clients depended on the whole fragment being the key.
Now they must parse the fragment. Having the key first, means you can grab the first 44 characters (32 bytes worth in base58) and not worry about the rest of the fragment.

I don't see how a character at the start or end makes it any simpler or more difficult to parse. Finding the optional extra char at the beginning or the end just changes your regex pattern or if you check first for the char and then for the base58 or the other way around.

Hence I would not want to change it now, as it is already being used in the wild. Changing it would mean that your client now has to support both the 1.7 version of the URL and the new version you propose.

I don't see how a character at the start or end makes it any simpler or more difficult to parse.

I agree, for a single character it doesn't make a difference. What I was trying to convey was, if in the future there are more option characters, then with prefix, clients would have to update to support each new character, or they will break.

Am sorry for not being able to convey properly before, let me try again.

Say Privatebin 1.9 wants to introduce a character to warn that paste contains large attachment (🐘), again as prefix.
Now clients would have to dynamically search for presence of either this new 🐘 chararater or the - character or both, before getting to the key. If they don't know yet about the 🐘 character, then parsing for base58_key may break unless we do some complicated regex matching on base58 characters.

With suffix system, you could simply define fragment linearly with anchor char (#) as origin.

or treating fragment as csv

clients can then support upto index they know.
And not break on future append only updates to fragment structure.

Q: Isn't this also possible to do by reverse indexing, by counting from end of url ?

Having to index from behind is brittle since other programs or browsers can add spurious chars at the end of url.
So indexing forward from the # would be more robust.

Basically, my suggestion is to keep the base58_key and any other option chars at fixed positive positions relative to the # /#- prefix in future updates

I would not recommend to index from behind either, because, as we had to learn, lot's of tracking-tools in chat-apps or "social" media will automatically add extra "GET-parameters" (ampersand followed by some key=value pairs) to the end of any URL-like string, even if that ends up being appended to the fragment and not to the query part of the URL.

Instead I would parse it as follows:

1. is the first character of the fragment a dash?
2. If yes, ignore it and shift one character forward (or take note of this and do what you want with that information, any use of this is client context specific - it doesn't guarantee you that it is a burn-after-reading paste, for example)
3. from where you now are, can the next 42 characters or the characters till the end of the fragment or till the next ampersand (whichever comes first) decode as base58 into 32 bytes (zero-padded at the front, if there are less than 32 bytes)?
4. if yes, that is the paste key, else you do not have a valid privatebin URL

Granted, I may have gotten exposed to too much C and too many char arrays, in recent years.

I'm not aware of any plans to introduce any other special characters at this time and have so far myself not considered any other such items that we must pass via URL and can't introduce as paste parameters, either in the encrypted payload or the clear text adata.

One argument that would indeed be a good one (IMHO) for putting the character at the end is that a knowledgable user can easier modify it (given some weird things do not add stuff there, but this is more a rare problem IMHO).

• if symbol is at the end: Press Ctrl+L, then → and then Backspace. Enter to access the new URL or copy it.
• if symbol is at the start: Press Ctrl+L, then ←, then Ctrl+→ 4 times and then Backspace. Enter to access the new URL or copy it.

Similarly you can add the - manually, if you want.

Also, it may be easier to see at the end instead of at the beginning – which in the URL is "inside some position in some wild letters".
So if we can still change it, I would also argue place it at the end may be a nicer idea.

Also that behavior is known e.g. from URL shorteners, where https://is.gd/vrlkOW- gives you a preview page and shows the URL first, while https://is.gd/vrlkOW redirects directly. So this is just a slight UX argument here.

This was already merged and has been in release 1.7.0 and 1.7.1 - if we change it, third party clients will have to support three styles, for the classic URL, the 1.7.x URL and the future URL.

Update to this discussion.

For future versions, we could support such client-side features using custom fragmet directives.
This could be the standard way to add support for such features, without breaking backwards compatibility.

For example burn on read could be indicated as:

#9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt:~:mayburn
or simply

#9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt:~:🔥

Example burn on read, and big attachment :

#9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt:~:mayburn&bigattach
or simply
#9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt:~:🔥&🐘

Backward compatibility:
The optional - at the start of fragment (before key) should still be supported as special case, however.

#-9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt

#-9rsiGhAeDjdCScSQQeqpnXHZsfgJohFbRoGfehkMKZZt:~:🐘

Note re above: We may have to change the delimeter (:~:) slightly. As iiuc browsers may strip it off (along with the directives) after their processing and not send it to page scripts.

@nain-F49FF806 Good point and thanks for the information. (though AFAIK browsers may do stuff with fragments itself, so we need to see). Anyway, could you please create a new issue for that, so it is not lost? Thanks!