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?

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

> 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.

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.

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.

People are often told if their data is published, they have no expectation of privacy. But I found an interesting gem in the EDPB Guidelines of 04/2019 which counters that to some degree:

> 59. Even in the event that personal data is made available publicly with the permission and understanding of a data subject, it does not mean that any other controller with access to the personal data may freely process it themselves for their own purposes – they must have their own legal basis.²⁰ > > ²⁰See Case of Satakunnan Markkinapörssi Oy and Satamedia Oy v. Finland no. 931/13.

IMO, that means #AI bots cannot exploit openly public data if it’s data that’s personal to a European or someone residing in Europe.

If you long-tap an image that someone sent, options are:

• share with…
• copy original URL
• delete image

The URL is not the local URL, it’s the network URL for fetching the image again. When you send outbound images, Snikket stores them in one place, but it’s nowhere near the place where it stores inbound images. I found it once after a lengthy hunt but did not take notes. I cannot find it now. I think it’s well buried somewhere. What a piece of shit.

A national central bank that keeps track of bank accounts, credit records, delinquency, etc for everyone in the country has their website on Cloudflare. People are instructed to check their credit records on that site.

The question is: suppose you don’t use the site. Suppose you only request your records offline. What are the chances that Cloudflare handles your sensitive records?

I guess this might be hard to answer. I assume it comes down to whether to central bank itself uses their own website to print records to satisfy an offline request. And I assume it’s also a question of whether the commercial banks use the website of the central bank to feed it. Correct?

I’m just noticing this instance for the first time. Judging by the hostname, it’s a node that’s devoted to #XMPP chatter. But I cannot reach it. Getting timeouts from Tor. This could mean that they are down, or it could be that they block Tor in the rudest possible way (dropping packets).

To me, it’s a ghost node because I can reach a tiny cache of posts from !infosec@community.xmpp.net locally:

https://sopuli.xyz/c/infosec@community.xmpp.net

cc: @wintermute@feddit.de

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

> In the onion v2 days we had underwood2hj3pwd.onion. There were half a dozen other onion email providers but Underwood was the only one that did not have a clearnet email alias (IIRC). That was a useful feature because you could distribute an onion address to a MS Outlook or Gmail user and they could not use it to share their correspondence to you with Google or MS in the loop. They had just two options: step off the ad surveillance platform or not contact you at all. That option died with Underwood. > > The other onion email services all have a clearnet translation. So if (for example) I give a gmail user this address: > > foo@yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion > > and they are motivated to reach me, they can figure out that the corresponding clearnet alias is foo(/at/)onionmail.info and then they can use that address to send me a msg that is then shared with their surveillance advertiser. And worse, that’s less effort for them than obtaining an onion email account. > > So what I do now is give an XMPP account. Since Google has abandoned jabber and MS never partook, XMPP avoids Google and MS. But XMPP is not a drop-in replacement for email. OMEMO is glitchy/buggy with pitfalls. > > I would like to offer an email option. Ideally, an onion email service would offer a clearnet alias that cannot be determined from the onion address, which implies a different userid string.

Those who condemn centralised social media naturally block these nodes:

• #LemmyWorld
• #shItjustWorks
• #LemmyCA
• #programmingDev
• #LemmyOne
• #LemmEE
• #LemmyZip

The global timeline is the landing page on Mbin nodes. It’s swamped with posts from communities hosted in the above shitty centralised nodes, which break interoperability for all demographics that Cloudflare Inc. marginalises.

Mbin gives a way for users to block specific magazines (Lemmy communities), but no way to block a whole node. So users face this this very tedious task of blocking hundreds of magazines which is effectively like a game of whack-a-mole. Whenever someone else on the Mbin node subscribes to a CF/centralised node, the global timeline gets polluted with exclusive content and potentially many other users have to find the block button.

Secondary problem: (unblocking) My blocked list now contains hundreds of magazines spanning several pages. What if LemmEE decides one day to join the decentralised free world? I would likely want to stop blocking all communities on that node. But unblocking is also very tedious because you have to visit every blocked magazine and click “unblock”.

the fix --- ① Nix the global timeline. Lemmy also lacks whole-node blocking at the user level, but Lemmy avoids this problem by not even having a global timeline. Logged-in users see a timeline that’s populated only with communities they subscribe to.

«OR»

② Enable users to specify a list of nodes for which they want filtered out of their view of the global timeline.

The “disobey”¹ onionmail server has been accepting my POP3 logins without issue for months/years. There has been “no new messages” for as long as I can remember and I have also not sent mail for a long time. Then I tried sending myself a message and I get “500 Mailbox full”. Yet my inbox is empty.

It’s quite disturbing because I have no idea when the admin apparently decided out of the blue to delete my account. It might have an automated removal, perhaps due to such sparse/rare traffic. But regardless, it makes it hard to trust any #onionmail server because they all run the same code. This same scenario occurred on another onionmail server as well.

Does anyone here use onionmail?

¹ a5dkbvgakon2lxmauleiizkv6i3s36wp6w3i32a3buc4xmtdnbttmryd.onion

While composing this post the Lemmy web client went to lunch. This is the classic behaviour of Lemmy when it has a problem. No error, just infinite spinner. After experimentation, it turns out that it tries to be smart but fails when treating URLs written with the gemini:// scheme.

(edit) It’s probably trying to visit the link for that convenience feature of pre-filling the title. If it does not recognise the scheme, it should just accept it without trying to be fancy. It likely screws up on other schemes as well, like dict, ftp, news, etc.

The workaround is to embed the #Gemini link in the body of the post.