paste manager feature

[elrido]

Well, this one is certainly going to be controversial, but here is the idea, comments highly welcome:

Now that I use ZeroBin more frequently myself I started creating lists of URLs, descriptions and (if I created them myself) delete links on my local machine.

Idea 1: local paste manager

Lets say I am accessing my trusted ZeroBin service (trusted here means: from my personal trusted device to a service I set up myself or trust the admin/crew that runs it). There is a button, i.e. "paste manager". When I click on it (for the first time on this service) I get a message explaining: "The paste manager allows you to store paste URLs on your device. This stores the full paste URLs including the secret that is not sent to the server and the deletion tokens. Are you sure you want to continue? Yes/No"

When clicking on yes I get a sidebar with an empty list. It could provide buttons to "clear the manager" (delete the local store) and "add a paste". Otherwise the manager will start to remember any paste I create on this service, including the delete token.

We could even add remote URLs to our list if we implement CORS headers to allow remote AJAX requests to retrieve these. This would allow us to use remote servers for storage only and to use our trusted install to access these.

Pastes would be marked as "crossed through" when they get deleted or expire. There could be a button to delete all such pastes at once. There could be a tagging system to tag pastes and then only display certain tags or tag combinations, etc.

Note: When you don't trust a server, don't store your pastes in it, as the server could in any way inject malicious code that retrieves the secret part of the URL and the password you typed in for the paste.

In any case I think this feature should not be active by default, but always require the user to request and accept it (and of course server admins should have the option to disable it on their installs).

Idea 2: federation and fostering client-server separation

There are ways to access local storage across domains. In this scenario the paste manager from above could not only store paste URLs of remote servers, it could access the local storage (which is on your own device) for that domain and import any stored missing URLs from that sites paste manager. This would allow migration if I switch from using one service to another (i.e. I get hooked using ZeroBin on some public service, but then later want to use my own installation).

ZeroBin consists of a server part to store and retrieve the data and the client could run completely separate, be that as an angular frontend, that maybe even runs on localhost or as a browser plugin (I think vikstrous was working in this direction) or even as a shell client (like ZeroCli by ziirish). Using the current frontend provided by the server would then simply be the fallback for those without a client and for casual visitors.

---

@Hexalyse:

I myself think the local paste manager is a very good idea. It's something that I saw on 0bin, and found it very usefull ! The way you see it and want to implement it is even more modulable. Being able to use our own installation of Zerobin (serving HTML/JS files we trust) to retrieve paste data stored on other Zerobin installations (ie. somebody sent us an URL from another Zerobin instance but we don't trust it) is even better and would give me a better security feeling.

I'm not sure about the Idea 2, it could be useful, but I think it shouldn't automatically import URLs from other domains' paste manager, but instead we could have a tab in which you choose to import URLs from such and such domains. In any case, I would use this feature myself, but it can be nice.

Anyway, the separation between client-side and server side (JSON REST API) is a very good idea, because we could imagine "desktop apps", or even mobile apps, that only use the network to retrieve paste data, so you don't have to rely on the statis JS files sent by the server each time. I totally support this new approach, which is way more "modern".

---

@Draky50110:

About the paste manager : why not, but please make a conf.ini option to enable/disable it ;)
Paranoid peoples are not always wrong :p

---

@Hexalyse:

Even if it's enabled, it wouldn't store anything unless the user enable it in the front end anyway.

---

@elrido:

Thanks for your feedback so far. Lets let these ideas ripe for a bit.

---

@rugk:

I would also be in favour for such a "paste manager",. but don't store the pastes on the server. Just store them in the local storage on your own device. Storing them there does not weaken security as:

1. Usually all browser store accessed URLs in the history, so they are saved on your local disk anyway.
2. A malicious server could read the URLs from local storage and send them to the server, but this needs modified JS (as local storage data is not send to the server by default - in contrast to cookies e.g.). This does not introduce a new danger as servers serving malicious JS are always a danger as discussed in Postgres support #8.
3. Local storage is separated per website.

Of course it has one disadvantage: Users can only use the paste manager on the same device & browser. But I think this is okay as all other solutions (like storing this data on the server) would weaken the security.
In any case it should however be optional - I think this is for sure.

[marsjaninzmarsa]

Maybe area for PrivateBin browser extension?

[elrido]

I have pondered on this over the last weeks and want to finally start implementing this feature, as it has always been my personal most wanted missing feature.

I have just concluded a series of UI mockup iterations and wanted to share my intended road-map for this ticket - since it is a large feature, I want to do this in stages, so I can pick up on feedback from you all along the way.

• Create a collapsible sidebar, called the "memory", most new functions will reside in this new area. By default it will be collapsed.
• Introduce a class in the JS to interact with the memory. As a start, it needs interfaces to add a URL and refresh the display of the list of added URLs in the memory.
• Implement the storage of these URLs in the browser using IndexedDB API (apparently local storage is no longer recommended).
• Add a "remember" button, displayed above a paste in view mode. When clicked, expands the "memory" and adds the currently displayed paste to the list.
• Clicking on the list element should display that paste in the current instances UI - even if it is a paste from another instance.
• Simplify the display of the URL lists - the key should not be displayed - Four columns, HTTPS ✔/✘, Service (domain + path), Paste ID, Actions (copy URL, checkmark for deletion)
• Implement a button to "forget" all marked pastes - I thought about just creating a "forget" button per paste and a "forget all", but these might be clicked accidentally and adding a modal asking "Do you really want to?" is annoying UX. Rather let the user check one or multiple items on the list and offer to "forget" the selected ones is still a two step process avoiding accidental deletion, but less intrusive. Should also add a "(de)select all" checkmark in the list header to deal with long lists quickly.
• Allow to sort the list by HTTPS, service name or paste ID.
• Add "import" and "export" to JSON file buttons at the bottom of the memory. It probably should just contain a list of URLs: ["http://example.com/?xxx#yyy","https://foo.bar/?zzz#aaa"], the simpler the better - this will initially mostly be helpful for testing. "import" should not replace the existing memory, but append any missing pastes - to avoid confusion it should report a import status on success: "total of [x] pastes found, [x-n] new pastes added to memory, [n] pastes already found in memory"
• Add "share" button at the bottom of the memory that creates a new plain text paste, containing the same JSON as for the "export". Such pastes should also be detected when loaded, so that they can offer an "import into memory" button upon display, which adds the shared links to the current users memory.
• Have a field to add paste urls manually to the memory.
• Allow to add a remark per paste in memory, for better distinction.
• Handle edge cases: What to display if the list is empty. What to do if the local storage is full.

I though about terminology and want to avoid terms like "save" and "open" as they indicate persistence on the file system. Hence I choose terms that invoke short term storage, like "remember", "memory", "forget". There needs to be a simple explanation in there, that this information is stored on your device.

It may be obvious to web developers due to the use of IndexedDB, but this means that these memories are specific to a domain and device. If one would visit a different privatebin instance using the same device, it will have it's own memory. This needs to be communicated clearly, or one might be confused why the memory got "lost" when switching to a different instance, as it may otherwise look the same, apart from the URL displayed in the browsers address bar, which is easily missed.

I thought about storing a typed in password in the memory as well, but for now will refrain doing so to avoid accidentally leaking them. Even if this would be added later on, these should probably not be stored in the JSON representation (import, export, share). This would make sharing paste lists safe in that the passwords still need to be transmitted in some other way and re-typed by the user, at least upon first opening one of these new pastes.

Edit: Will update this posts todo list as I progress. You can compare the code changes to master or preview the latest stable state.

[elrido]

TIL: There is a HTTP OPTIONS request type that is used as CORS preflight check. And nginx doesn't support this type by default and responds with a 405 Method not supported. Had to add the following snippet to my test instances server section in the nginx configuration, but now I can load pastes from it and display them on my local dev instance:

    location / {
        if ($request_method = OPTIONS ) {
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            add_header Access-Control-Allow-Origin *;
            add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE";
            add_header Access-Control-Allow-Headers "X-Requested-With, Content-Type";
            return 200;
        }
    }

Since at the moment a form to add paste URLs from other instances is missing, I have to add these via the browsers console using a call like the one below (in case anyone follows along or wants to test it with their own instance on the preview instance):

$.PrivateBin.Memory.add("https://example.com/?xxx#yyy");