freedomPusher

In both Lemmy 0.19.4 and Lemmy 0.19.5, you click the magnifying glass to open the search dialog. If you enter a search query and tab out of the field, whatever you typed is cleared. Even if you simply hit <enter> without tabbing out of the query field, the search form is refreshed and it tells you enter a query, as if you had not done so already.

Both versions have this problem with Ungoogled Chromium. The problem does not manifest on Tor Browser.

cross-posted from: https://sopuli.xyz/post/14184367

Lemmy version 0.19.4 introduces 3 relatively intolerable bugs, and 0.19.5 only fixes one of them.

• cannot post, risk of data loss
• cannot cross-post, but no data loss.
• can only visit the default timeline view

Lemmy version 0.19.4 introduces ~~3~~ 4 relatively intolerable bugs, and 0.19.5 only fixes one of them.

• cannot post, risk of data loss
• cannot cross-post, but no data loss.
• can only visit the default timeline view
• (update) cannot search

This bug was introduced with version 0.19.4 and still persists in 0.19.5: There are four possible timeline views:

• subscribed
• local
• all
• moderator view

That selector is broken in Ungoogled Chromium 112.0 but not in Firefox-based browsers. In UC, clicking “moderator view” highlights the button, the page refreshes, but the selector does not stick. It snaps back to whatever view is the default and remains trapped on that timeline.

This problem is replicated in both 0.19.4 and 0.19.5 instances.

If I use the cross-post feature to copy the post elsewhere, the form is populated just fine but then I have to search for the target community at the bottom of the form. As soon as I select the target community, the whole rest of the form clears. If another field is re-populated, the target community field clears. So only one field at a time can be populated.

Tested with Tor Browser.

Untested in Lemmy 0.19.5.

Lemmy 0.19.4 introduced a quite serious defect whereby if you are using Ungoogled Chromium (and perhaps stock Chromium), the form to create a new post accepts input but then the instant you tab out of the field, the whole field is cleared. Poof… just like that, all your work vanishes and no way to get it back.

Firefox-based browsers have no issue.

~~Lemmy 0.19.5 seems to have fixed it.~~ But there are other problems with both 0.19.4 and 0.19.5, so I suggest not upgrading past 0.19.3.

(edit) actually the problem manifests differently in 0.19.5. The form can be filled out and there is no data loss, but the “create” button is insensitive. It remains gray and behaves as if the form is still empty.

cross-posted from: https://sopuli.xyz/post/14087065

One quite annoying Lemmy behaviour is when you search for a community that has many results spanning multiple screens (e.g. query “software”), the list is largely clusterfucked with crappy centralised instances that go against the #fedi philosophy (e.g. #lemmyWorld, #ShItjustWorks, #lemmyCa, #LemmyZip, #programmingDev, etc).

I discovered a fix: ctrl-rt-click on every community in the list to open each in a tab. Then click “block community”, then repeat the search. It works the way it should: blocked communities are excluded from search results.

Wish I realised that sooner.. would have saved me some effort and frustration in trying to search only for communities in the decentralised free world.

One quite annoying Lemmy behaviour is when you search for a community that has many results spanning multiple screens (e.g. query “software”), the list is largely clusterfucked with crappy centralised instances that go against the #fedi philosophy (e.g. #lemmyWorld, #ShItjustWorks, #lemmyCa, #LemmEE, #LemmyZip, #programmingDev, etc).

I discovered a fix: ctrl-rt-click on every community in the list to open each in a tab. Then click “block community”, then repeat the search. It works the way it should: blocked communities are excluded from search results.

Wish I realised that sooner.. would have saved me some effort and frustration in trying to search only for communities in the decentralised free world.

In the US, consumers can freeze their credit worthiness records and receive a code. When the records are frozen, the only orgs that can access the records are those already doing business with the consumer. If a consumer wants to open up a new account, they share the code with the prospective creditor who uses it to see the credit report.

So the question is, how are access controls on credit histories done in various EU nations? Do any use unlock codes like the US, or is it all trust based?

Yikes.

“In the adequacy decision, the European Commission estimated that the U.S. ensures a level of protection for personal data transferred from the EU to U.S companies under the new framework that is essentially equivalent to the level of protection within the European Union.” (emphasis added)

Does the EU disregard the Snowden revelations?

And what a missed opportunity. California state specifically has some kind of GDPR analogue, so it might be reasonable if CA specifically were to satisfy an adequacy decision, (still a stretch) but certainly not the rest of the country. Such a move could have motivated more US states to do the necessary.

I must say I’ve lost some confidence and respect for the #GDPR.

cross-posted from: https://sopuli.xyz/post/13985430

The problem:

Most #fedi authors post links with no idea if the hosting server discriminates against people, or who. The consequence is that the fedi is muddied with references to exclusive venues that do not treat people equally, which wastes the time of readers who are impacted by discrimination. A variety of walled gardens pollute our threadiverse experience. So how can we remedy this?

Proposed fix:

Suppose we create a community and designate it as a testing area which welcomes bots. So e.g. I post something in the test community, and a bot that is paywall-aware replies yes or no whether the link is paywall-free. A bot that is Cloudflare-aware does the same. A regional bot, such as a bot in Poland can check that Polish IP addresses can reach the URL and make noise if the website blocks Poland. Etc. It need not be just bots.. someone in some oppressed region might manually attempt to visit links and report access problems. We would certainly like a bot in a GDPR region to test whether access is refused on the basis of a data controller’s unwillingness to respect GDPR rules. The OONI project could have a bot that reports anything interesting in their database.

There could also be anti-enshitification bots, which point out things like cookie walls.

There are bots that find better links to replace Cloudflare links. Those bots could help direct authors to better URLs to share.

There could be a TL-DR bot that replies with a summary or even the full text, so an author can decide before posting in the target community whether to omit a shitty link and just post the content.

(update) It’s worth noting that for Mastodon there an ad hoc tool. If you follow @mg@101010.pl, that bot will follow you back and analyze every URL you share for whether it is Cloudflared. If yes, it will DM you with alternative URLs.

Note that the mitigator bot is quite loose it its judgement. If the host is not Cloudflared but another host on the same domain is Cloudflared, it is treated as a positive because it’s assumed that when you visit the host it will link to other hosts on the same domain.

The problem:

Most #fedi authors post links with no idea if the hosting server discriminates against people, or who. The consequence is that the fedi is muddied with references to exclusive venues that do not treat people equally, which wastes the time of readers who are impacted by discrimination. A variety of walled gardens pollute our threadiverse experience. So how can we remedy this?

Proposed fix:

Suppose we create a community and designate it as a testing area which welcomes bots. So e.g. I post something in the test community, and a bot that is paywall-aware replies yes or no whether the link is paywall-free. A bot that is Cloudflare-aware does the same. A regional bot, such as a bot in Poland can check that Polish IP addresses can reach the URL and make noise if the website blocks Poland. Etc. It need not be just bots.. someone in some oppressed region might manually attempt to visit links and report access problems. We would certainly like a bot in a GDPR region to test whether access is refused on the basis of a data controller’s unwillingness to respect GDPR rules. The OONI project could have a bot that reports anything interesting in their database.

There could also be anti-enshitification bots, which point out things like cookie walls.

There are bots that find better links to replace Cloudflare links. Those bots could help direct authors to better URLs to share.

There could be a TL-DR bot that replies with a summary or even the full text, so an author can decide before posting in the target community whether to omit a shitty link and just post the content.

(update) It’s worth noting that for Mastodon there an ad hoc tool. If you follow @mg@101010.pl, that bot will follow you back and analyze every URL you share for whether it is Cloudflared. If yes, it will DM you with alternative URLs.

Note that the mitigator bot is quite loose it its judgement. If the host is not Cloudflared but another host on the same domain is Cloudflared, it is treated as a positive because it’s assumed that when you visit the host it will link to other hosts on the same domain.