redlib-org / redlib

Private front-end for Reddit
GNU Affero General Public License v3.0
1.31k stars 90 forks source link

💡 Feature request: Persistence for subscriptions across restarts #110

Open Opening-Button-8988 opened 5 months ago

Opening-Button-8988 commented 5 months ago

As far as I know, if you add or remove subscriptions using the redlib UI (in a browser), they will not persist across browser sessions. I for one don't use browser persistence, no cookies are ever saved. This functionality encourages people to hoard their cookies.

The only way to add or remove subscriptions and for the change to be permanent is via environment variables. I use an .env file for that with Docker. However, this is very inconvenient. I shouldn't have to edit my .env file every time I want to add/remove subscriptions.

I did some testing and it appears that only sometimes will subscriptions be saved across container restarts. Not entirely sure why.

I am against the use of accounts, except for public instances. I host locally for myself, I don't want to have to create an account for myself. For public instances it makes more sense.

I think it's been suggested elsewhere (#38) but I am in favor of saving posts locally. But I am only in favor of this if there's an easy Export / Import for all kinds of data on redlib (including subscriptions, posts, config, etc).

I am aware there is a link that allows you restore subscriptions and settings. But thinking about it for just a few seconds; where do I store this link, and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database? What if I have multiple browsers (which I do)? I use redlib as an installed PWA on Brave, which doesn't have a bookmark UI, meaning I don't want to have to use browser bookmarks to save my settings, and again, I'd have to update my bookmark link every time.

I also support #70.

Bug

Also, to follow users you need to use the encoded %2B instead of +. For example, this

askreddit+techsupport%2Bu_someuser%2B_anotheruser

instead of this

askreddit+techsupport+u_someuser+u_anotheruser

Otherwise the user won't show up in your feed.

argium commented 4 months ago

But thinking about it for just a few seconds; where do I store this link, and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database?

Yes, this is what we all do.

What if I have multiple browsers (which I do)?

Whatever mechanism you use for bookmarks will work. If you truly don't use bookmarks, perhaps a text file.

I am against the use of accounts, except for public instances. I host locally for myself, I don't want to have to create an account for myself. For public instances it makes more sense.

You misunderstand what this project (and libreddit) are for. It's designed to never store user data (ie. accounts) server side. Default subscriptions can be set via environment variables but they're not specific to a user. I run my own private instance so I understand where you're coming from but a bookmark is better than the full reddit site.

Opening-Button-8988 commented 4 months ago

@rifuller A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient. I should be able to do this in the redlib UI. I consider this a bug. It relies on cookies to store subscriptions, which encourages practices that are against user privacy such as using a browser that retains cookies. I use redlib in a Brave PWA, which doesn't have a bookmarks bar, I don't want to have to click the bookmark every time, nor edit it every time I want to adjust subscriptions. I can't imagine making this change would be a technical feat.

As for accounts, I think I already said that I'm against them.

EmberHeartshine commented 4 months ago

You can make the PWA address the link necessary to restore subscriptions/settings (the "bookmark") instead of just the root address.

What you're asking for doesn't really seem congruent with the tech in place. Redlib doesn't store data server-side by design, which is itself a security consideration. Cookies are the client-side method to have settings from a website persist across browser sessions (unless you kludge something together using LocalStorage, I guess, but that has many of the same issues as using a cookie in the end). Moving that to the server is worse.

An example of this I point to is Whoogle. You can store all your settings as an argument in the URL of the search query if you want to. But if you change those settings, that argument necessarily changes and you have to update your search shortcuts, bookmarks, etc. to accommodate. Would you prefer that Whoogle holds your information on a server somewhere and.... somehow authenticates your information without a cookie or any kind of local storage? Using, what, browser fingerprint? That's hilariously insecure. (Startpage operates the same way, though since that's not self-hosted the security implications are more obvious.) In an era of web crawlers that can find the most obscure URLs, you really can't "security through obscurity" server-side privacy and security anymore.

It legitimately sounds to me like you've hopped on the "cookies bad" train without actually knowing or understanding why cookies are sometimes considered a security risk, or recognizing what the actual methods to "fix" this bug might be. (FWIW: storing any information server-side is always a greater security risk than storing information client-side. Besides, if your instance is generally available on the internet, would it not be safer to keep your personal info local?)

A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient.

Using any FOSS front-end is a balance between privacy and convenience. You already made the decision that privacy overrules convenience by using a FOSS front-end over, say, old.reddit.com. The suggestions you're making reduce the privacy of a given redlib instance, not enhance it.

sigaloid commented 4 months ago

I am aware there is a link that allows you restore subscriptions and settings. But thinking about it for just a few seconds; where do I store this link

Entirely up to you, anywhere you want

and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database?

Yes. The goal is to be self-contained, so there is no other way to store data.

What if I have multiple browsers (which I do)?

Create a URL file on your desktop, perhaps?

I use redlib as an installed PWA on Brave, which doesn't have a bookmark UI, meaning I don't want to have to use browser bookmarks to save my settings, and again, I'd have to update my bookmark link every time.

Yes, that's really the intention. Manage your settings however you want locally, it could even be a text file in your home dir. But your settings should not ever have any information associated with them except for the content.

A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient. I should be able to do this in the redlib UI. I consider this a bug. It relies on cookies to store subscriptions, which encourages practices that are against user privacy such as using a browser that retains cookies.

Cookies are not against user privacy. Cookies are great to store things like this, user-side settings. It's not hard to have a browser clear cookies for many sites except select ones - in fact it's built into Firefox's container system.

I use redlib in a Brave PWA, which doesn't have a bookmarks bar, I don't want to have to click the bookmark every time, nor edit it every time I want to adjust subscriptions. I can't imagine making this change would be a technical feat.

It sounds like what you propose would require local state, which I'm against adding. I don't want to complicate it with databases, etc. There's so many ways to save your preferences to the project, via URL, via cookies, via env var, and via docker compose. Add your subscriptions there, or manage the settings URL however you'd like. But between your local preferences and the default settings options via environment variable/config, there's infinite flexible ways to manage your settings - adding a local database is not a good answer, given it locks you into the server instead of being a naturally agnostic chunk of data (literally your settings in plain text).

wat100 commented 3 months ago

@EmberHeartshine it really seems like you're making excuses for disappointing design. there's plenty of selfhosted apps that use a database that you can store on your server in order to keep your information instead of having to rely on cookies and all of their issues. you can't have it both ways. you can't say selfhosted apps trade convenience for privacy then have an app rely on the security nightmare of enabling cookies. there are literal selfhosted banking apps that store settings via your own selfhosted server instead of cookies. if it's good for your money it's good for your subreddits

argium commented 3 months ago

It's designed to store user data client side that prevents data from all users of an instance being collected in a single place and enables mobility between instances should one choose.

security nightmare of enabling cookies

There is nothing inherently wrong with cookies. What do you recommend for client-side storage?

If the ask is to support single-user instances then I think that's reasonable to consider. Perhaps initialised from env vars and, instead of reading from a cookie, those settings are stored as a singleton in memory. I'm not sure I understand the scenario though because that just moves the settings from one user-controlled computer [using cookies] to another user-controlled computer [using something other than cookies].

EmberHeartshine commented 3 months ago

you can't have it both ways. you can't say selfhosted apps trade convenience for privacy then have an app rely on the security nightmare of enabling cookies.

Sure I can, because cookies are only a security nightmare if you don't actually understand what a cookie is and how they work. It isn't 1990 anymore, implementations of cookies have drastically improved. Get your head out of the sand and get with the times.

Opening-Button-8988 commented 2 months ago

@EmberHeartshine

You can make the PWA address...

I only use redlib on a locally hosted instance. Does everything you said still apply here then?

EmberHeartshine commented 2 months ago

It's accessed through a web browser, so regardless of whether there's a FQDN or IP address being used the arguments are the same.

Opening-Button-8988 commented 2 months ago

It's accessed through a web browser, so regardless of whether there's a FQDN or IP address being used the arguments are the same.

Pardon my ignorance but I don't think localhost:5000 is a FQDN, nor an IP address. Just so we're clear, my instance is not accessible anywhere except on my computer. Despite this, you are saying this still shouldn't be implemented?

I don't believe cookies are inherently insecure (maybe they are, I don't know). But relying on cookies in the way redlib does encourages me to have to store cookies rather than not store any. What this means is that I have to make an exception that can only hurt my privacy, if anything. Not storing cookies is better than storing cookies.

For now, I'll try to manage my subreddits through bookmarks and see how I manage.

EmberHeartshine commented 2 months ago

localhost is an alias for 127.0.0.1 unless you've fucked with your DNS resolution settings.

The point is that there's no reason to create two different forks of redlib to accommodate local vs remote instances when there's literally nothing wrong with how it's handled right now. If you don't want to use cookies, then don't use cookies. Use the address instance_url/settings/restore/?your_settings_here and it'll restore your settings every time you open a new session. It's a silly, outdated mindset to refuse to use on-domain cookies but whatever. The option is there if you want to use it for whatever reason.

Opening-Button-8988 commented 2 months ago

I will use the link. How is "refusing to use on-domain cookies" outdated? I'm not refusing to use them, just explaining I shouldn't have to use them if a better solution exists. Best example I can use is SearXNG, while there is a way to restore settings through a link, I am still able to restore settings without needing links nor cookies because (I'm guessing) that data is stored in the docker image. Good thing too, cause I like being able to type any string into my browser and make use of Brave's shortcut functionality so that it appends my search query to SearXNG. It's just convenient that way.

dderg commented 1 month ago

Another interesting functionality would be having different feeds that you are able to subscribe to different subreddits. For that some sort of account system is needed. But if I understand correctly, if I implement such functionality it would never be accepted into the main project. I was thinking something similar to what Invidious does. Having instance-specific accounts.