ShadowPouncer

And the Supreme Court is supposed to be a court of law.

Sadly, as they have decided to move away from that, the least the executive can do is ensure that the law is being correctly applied in cases where it favors the people.

The big cost to doing it yourself is maintenance.

There is, for a lot of people, a fairly large amount of value in never having to worry about hardware dying. If it does, that's someone else's problem, and it will be fixed, as far as you are concerned, rapidly and without any interaction with you.

How much any given person values that is going to vary wildly, but it means that you don't risk having stuff go down at a moment when you can't do anything about it. Maybe you're on vacation, and you don't have any hands that can do anything. Maybe you're sick, or just extremely busy that week.

You're not wrong that this comes at a fairly substantial monetary cost, but it is wrong to say that this isn't, in many cases, a cost that people are more than willing to pay in exchange for the benefit.

Mastodon absolutely does have a weakness of making it more difficult to find people that you want to follow based on what you have already engaged with.

And from a purely user perspective, that is a weakness.

But it's also a very distinct choice. Because having enough data to be able to meaningfully make such recommendations means having a central database of every user interaction by every user.

And it also means making choices and value judgements which, almost by definition, can not be value neutral.

If the creators of the algorithm are good, they will actually be aware of the choices and value judgements being made, if not, well... They will still be making them, just not in nearly as educated of a way.

On the whole, I really hope that we eventually come up with answers to these problems that make it possible for a user to make those choices, and to have the amount of recommendations that they want, while somehow not having anyone have the huge database of user interactions. I'm not sure if that's even possible, most especially if you assume that there will be entities on the fediverse that are fudging their data to get recommended in ways that other users don't want.

But it sure would be interesting to try.

You make a great point about GDPR requirements.

But I don't think that the full export would be very practical as an account migration tactic. There's no value uploading previously made posts/comments/toots to the new instance, because it can't do anything with them.

That's like saying that only using high security locks with various security pins in them to protect your house is a bad idea, and you should throw in some secured with padlocks too just to change things up.

And if some of them are shitty masterlocks, well, you're changing things up.

That's really not how security works.

Yes, pass phrases can have large amounts of entropy attached. But unless you are picking your pass phrases truly randomly, with a large dictionary, and using unique pass phrases per site, and the sites are not silently truncating the password input (such as bcrypt which truncates to 72 bytes), you are not actually getting that large amount of entropy.

Where as a 16 character password that randomly uses the ASCII printable range, excluding spaces, gives you 93^16 possible combinations. That's 31313180170800116587336013460801 passwords.

Or, very roughly, 104.6 bits of entropy. (104.6265409777285022441578006899739 bits of entropy if you want to be downright absurd about it.)

Knowing that you're doing that simply doesn't help the attacker in any meaningful way.

Bumping that to 20 characters gives you over 130 bits of entropy, or 2342388736625917052139104541473924426001 possible combinations.

This is quite simply not a viable attack surface.

Where as saying 'use pass phrases for some things' means that it is quite likely that some of your pass phrases are going to be much less secure than this.

But let's give the same numbers for properly generated random passphrases.

The xkcdpass utility can help us here.

Even picking entirely randomly, out of a large word list of 7227 words, a 6 word pass phrase only gives roughly 76 bits of entropy.

Going up to 8 words gives us roughly 102 bits of entropy, that helps a ton... Except that some of those passphrases are going to be longer than 72 bytes. So you're almost certainly losing bits of entropy.

That best case still gives you fewer bits of entropy than a 20 character randomly generated password. Unless you're trying to memorize your password, there are no benefits to alternating between randomly generated passwords with good generation settings and passphrases.

And if you're trying to memorize your passwords, you are definitely doing it wrong.

You're both right, but I'm pretty sure that you're having two separate but related discussions.

Certification by itself does absolutely nothing. It's a piece of paper.

However, it's a piece of paper that you can not get unless you've done a bunch of other stuff.

Regulations would have prevented this, because they would have required the certifications, which would have required the other stuff.

In this case, they didn't do the other stuff.

They didn't test the hull to see if it could take the pressure.

They explicitly decided not to bother testing the hull to see if it could actually take the pressure.

They certainly didn't do any fatigue testing to see how repeated pressure cycles impacted the material. The material that is extremely complex, and which nobody has done this with.

Because they didn't do that testing, they had no way to reliably know if other steps were required, like only using it X number of times, or establishing processes to do specific inspections to look for whatever kinds of damage might happen as a result of repeated stress.

So yes, if they had actually followed the process, this wouldn't have happened. They explicitly arranged to use the vessel in locations where they could not be held to the process.

But they didn't want to follow the process. Which means more than 'they didn't do the certification', it means that they also didn't do many of the other things that would have been required to get that certification.

And the lack of regulation meant that nobody could shut them down for those decisions.

I think that it matters a great deal.

One side wants entire groups to not exist. We have seen that play out, time after time after time. We have seen that carried to the point of concentration camps, and the systematic extermination of entire groups of people.

We know where that road ends, and it ends is more blood than anyone should have the slightest desire to ever see spilled in their lifetime.

The other side might not be perfect, but it isn't out to exterminate people.

That's not a small difference. It's not a subtle difference. It's the difference between one side thinking that the holocaust didn't go far enough, didn't succeed enough, and the other side seeing it as an absolutely horrific event, something so horrible that it should never be allowed to happen again.

And make no mistake, when the far right is literally copying propaganda from the Nazis, and they are, they damn well know what they are doing.

Based on the comment, I think that what is wanted is a little different than what people are assuming.

First, it sounds like there is a desire to implement enough of the Mastodon API that various mobile Mastodon clients can connect to kbin.social and interact with that side of things. I have no idea how difficult this would be, but I suspect that it would be an interesting undertaking.

And second, unrelated, but it came up in the comments, and I think it would be an excellent idea, there is definitely a desire to implement a Mastodon-like way to export and import enough of your account information to easily migrate to another instance.

In my opinion, there needs to be an option that can both import and export a fully Mastodon compatible format, so that people can migrate from Mastodon to kbin, and can migrate back from kbin to Mastodon, at least for stuff where that makes sense.

At the same time, I am unsure if that format would be sufficient for everything required to migrate from one instance of kbin to another, or between kbin and lemmy.

And given that last point, it should come as no surprise that I think that if another format is needed, or even an extension to the existing format, that should really be coordinated with Lemmy, so that it is easier to move around the entire ecosystem.

The really really sad thing is, Reddit could have done a half decent job and made a fair bit of money, but they decided on stupidity instead.

Sure, it would have upset some people a bit, but... Not by anywhere close to the same degree.

Alright, we're sorry, but use of the API is going to have to start costing money for some kinds of uses.

First off, people that just want to scrape everything get the following access, and a much higher rate limit, but it's going to cost $x.

Moderator tools will always be free, but the API will require that the tool be associated with a moderator, and it will only permit access to subs that the user is a moderator for.

Community bots will generally be free, subject to the following restrictions.

And 3rd party clients will be charged a minimal amount, calculated to be roughly equal to what we are making from similar users on the official clients, to make up for lost ad revenue. Alternate options involving profit sharing may be viable, contact X for details.

By accepting the API agreement, you agree that use of the wrong class of API usage (for example, using the community bot or 3rd party client classes for data scraping) will be billed, retroactively, at $X * 10.

There. That's really not that hard. And people would have been much less upset at that, at least as long as the fees were actually as described, and not based on, say, how much they would like to make per user.

You'd probably want a free tier for 3rd party clients for users of specific account types. If the user is paying for Reddit Premium, maybe 3rd party clients don't get charged for API usage for that user account. Or if the user is a moderator for a given subreddit, API usage for that user on that subreddit is also free. With an API that the client can use to check the status of such things. If they were smart, they would also have a process for users with disabilities to have their accounts exempted from fees. That last one is hard, because you need a verification process, but it would get them a lot of good will.

Again... This shouldn't be hard. And it would have turned into a viable revenue stream!

Hell, flatly disclose that the 3rd party cost is 30% more than the average cost of using the standard client, to support the effort required to maintain the API. (Largely bullshit, but it makes those users more valuable than those that use the official client, while not being expensive enough to make it impossible for anyone to offer a 3rd party client at an even remotely sane cost.)

Yes, this would have very sadly been the end of free 3rd party clients... But I for one would have been... Okay with paying a small amount per month/year through the app store for a client that didn't suck.

Instead, Reddit decided that committing suicide was the better path forward.

The advice to always use a unique password per site is an excellent one.

The why is multifaceted, and some of them are moderately complex.

First off, not every site is going to be storing your password in a good a secure manner.

In an ideal world, every site on the planet would be hashing it with something like bcrypt with a fairly aggressive cost setting, and good salts.

And they would have a way to automatically rehash your password on login in the event that the password hashing settings change. (Almost everyone misses this one.)

In practice... It could be stored in plain text. It could be hashed with classic crypt(), or with md5 or sha1 with no salt. There are so many ways to get it wrong.

On the rehashing one, they could have picked something that was best practices at the time, you setup your account, and then two years later, best practices have changed, it turns out that there was a way to attack the previous way, so they change how they do it... And that's great for everyone who changes their password or sets up a new account after that change, but everyone who did it before that change? Well, those passwords are just sitting there hashed by the old method indefinitely.

Or someone could compromise the site, and grab every password everyone enters.

Or you could fall prey to a phishing attack, and type your login to what looks exactly like the site in question, but is infact a common typo of the real domain.

Again, there are a lot of ways for the password used on a site to get compromised. Many of those ways are entirely out of your control. It is standard practice for attackers to attempt to use that password and username / email on other services when this happens, just so that they can see what else they can get into.

Don't let that work.

I use + addresses for stuff.

Well, since I run my own mail server, I tend to use _ instead of + as the separator, simply because more places will consider it a valid address.

But it's amazing how useful it is to include the name of whoever you're giving the email address to in the email address. It lets you keep getting email for stuff like password recovery. And when an address is leaked, not only can you block that one, but you also get to know who leaked it.

Which is awesome for knowing which businesses to never use again.

Don't do this.

Just use a good, random, password generator with decent settings.

Varying away from that just to 'change the kind of password' is only going to reduce your security.

You want as many random bits of information as possible in the password. That's it.