Zagorath

Cool. I stopped paying for it back when it was still called "YouTube Red", during one of their many crackdowns on creators' freedom in the name of benefitting advertisers. I dumped it and installed an adblocker, and eventually YouTube Vanced and its successor Revanced.

I recall once hearing that instant hot water heaters (including electric, rather than gas, ones) are supposed to use less energy than water tanks, but I wonder if that's only resistive tanks, rather than the more common (these days) heat pump tanks?

My reasoning has always been—though I don't know if this is backed up by evidence at all—that a higher cadence means each step puts less force through the legs, and thus a high cadence is better when recovering from injury. I hope your recovery goes/is going well!

It's not true.

But if it was, it wouldn't be a reason to dislike Postgres. Academic AI research in the '90s is a far cry from commercial AI companies today.

Actually something just occurred to me. Because my system, unlike the one from the Stack Exchange link or the one described elsewhere in the thread using an ID card, relies on a per-site untraceable request to the government, the government would be able to detect if one user is making a suspicious number of requests. It's reasonable for one person to make tens of requests, maybe even low hundreds over the course of a lifetime. It's not reasonable to be making hundreds or more in a day. They wouldn't know which sites are being accessed with it, or even what accounts on those sites. But they could set rate limits to prevent one person creating too many accounts for others, and potentially threaten legal action against them for doing so.

That threat of legal action is part of the same thing that prevents children from being able to go up to a random adult, handing them a $50 note, and asking for $20 worth of alcohol in exchange. You're not going to be able to prevent it on a smaller scale, but you can definitely prevent a small handful of people being able to age verify on behalf of thousands of children.

An additional protection could be added depending on how the age verification works. If she verification is "upload a scan of your photo ID", then yeah, mass verification becomes possible. But if each verification requires you to hold up your photo ID next to your face, speak a specific phrase aloud (with automated lip reading attempting a rough lip flap match), nod your head, write a specific phrase on a piece of paper, and more, all in randomised orders, it becomes a much bigger burden for someone to provide for others.

I'm certainly not advocating this. The level of burden for legitimate users would be too high to consider it reasonable. But it would be possible. Something like this has been used in the past for things like EV code signing certificates, where a larger burden is relatively more reasonable.

What's the reference here?

It would also reveal to the government that the user was accessing 18+ content

Yes, I did mention that. Although ironically, Australia's social media minimum age law, and other similar laws being considered around the world, would actually increase privacy in this respect. The government could have separate keys for each age of legal significance (16 and 18, in Australia) and sign with the appropriate one (either the highest the user meets, or all the user meets—the latter would give the site less information about the user's and).

I don't believe it is technically possible to get around the example you shared there. Even in the real world, it's not dissimilar to a child asking an adult to buy alcohol for them.

Insomnia > Postman.

I switched to Insomnia around 2021 when Postman started enshittifying and found I liked it a lot more. Insomnia has also been relatively enshittified unfortunately, but it feels like it's to a lesser extent.

Here's one good answer: https://crypto.stackexchange.com/a/96283

It has the downside of requiring a physical device like a passport or some specific trusted long-running locally-kept identity store held by the user. But it's otherwise very good.

Another option does not require anything extra be kept by the user, but does slightly compromise privacy. The Government will not be able to track each time the user tries to access age-gated content, or even know what sources of age-gated content are being accessed, but they will know how many different sites the user has requested access to. It works like this:

The user creates or logs in to an account on the age-gated site.
The site creates a token T that can uniquely identify that user.
That token is then blinded B(T). Nobody who receives B(T) can learn anything about the user.
The user takes the token to the government age verification service (AVS).
The user presents the AVS with B(T) and whatever evidence is needed to verify age.
The AVS checks if the person should be verified. If not, we can end the flow here. If so, move on.
The AVS signs the blinded token using a trusted AVS certificate, S(B(T)) and returns it to the user.
The user returns the token to the site.
The site unblinds the token and obtains S(T). This allows them to see that it is the same token T representing the user, and to know that it was signed by the AVS, indicating that the user is of age.
The site marks in their database that the user has been age verified. On future visits to that site, the user can just log in as normal, no need to re-verify.

All of the moving around of the token can be automated by the browser/app, if it's designed to be able to do that. Unfortunately a typical OAuth-style redirect system probably would not work (someone with more knowledge please correct me), because it would expose to the AVS what site the token is being generated for. So the behaviour would need to be created bespoke. Or a user could have a file downloaded and be asked to share it manually.

There's also a potential exposure of information due to timing. If site X has a user begin the age verification flow at 8:01, and the AVS receives a request at 8:02, and the site receives a return response with a signed token at 8:05, then the government can, with a subpoena (or the consent of site X) work out that the user who started it at 8:01 and return at 8:05 is probably the same person who started verifying themselves at 8:02. Or at least narrow it down considerably. Making the redirect process manual would give the user the option to delay that, if they wanted even more privacy.

The site would probably want to store the unblinded, signed token, as long-term proof that they have indeed verified the user's age with the AVS. A subsequent subpoena would not give the Government any information they could not have obtained from a subpoena in an un-age-verified system, assuming the token does not include a timestamp.

Worth noting that Lemmy receives at least some institutional funding for its development. And I believe some of that funding is contingent on hitting active user goals or similar metrics.

Yes, they have two options. Either honour the sticker price, or stop selling it at all until the price is fixed.

In Australia if the price at the checkout is higher than the price tag you are entitled to the first item free

Got a source on that? That's not what the ACCC says.

They would have to refuse to sell to anyone. It would likely not be lawful to leave it on the shelf and sell it at the higher price to someone else who might not have noticed the discrepancy, until they fix up the shelf pricing.

Australia, the country the article is talking about. That was a quote from the ACCC website.

Reminder that by law, if the price is listed wrong:

Sometimes the price of an item in store or online at the checkout may not match the displayed or advertised price in store or online. If this happens, even by mistake, the business must either:
sell the product for the lowest price - either the checkout price, or displayed or advertised price, or
stop selling the item until the incorrect price is corrected.

Oh very interesting. Thanks for being so patient! I had no idea about this. I always just assumed that if a device said it supported 100M, that necessarily meant that if you connect a 10M device up to it, it'll automatically take the lower speed. Like a car with a max speed of 10 can go on a road with a speed limit of 100...it'll just be limited to 10. I didn't realise it had to sync up like that.

Oh damn, really? So do normal home routers have to support basically every possible speed? Because I don't think I've ever encountered or heard of someone encountering a failure due to a speed mismatch.

So what happens when that occurs? Does it just stop working, or does it work at the lower speed despite the lack of official "support" for it?