A1kmm

joined 3 years ago
[–] A1kmm@lemmy.amxl.com 6 points 1 month ago

Hmm, it seems like it was perhaps not engineered for large numbers of pedestrians, but it still seems like the article is a bit hyperbolic (that said, I'm an Australian and don't know the area, and am going off things like Google Street View and maps).

It looks like there is a road, "Patterson Plank Road", that actually has a footpath, and has a speed limit of 40 (presumably miles per hour, so 64 kph - about the same speed as most arterial roads in Australian suburbs), and connects to the local area. Then there is a "Rd A Plaza" that seems to go around the outside of the complex, that has a footpath for most of the way, up until there are vehicle barriers. From that point, there is a wide grass verge that looks relatively well drained, and runs all the way to the start of the car park (which presumably has to be walkable to the actual entrance). It would take crossing a 4 lane road that seems to mainly serve the stadium, and isn't well engineered for pedestrians (no pedestrian refuge islands or anything) - but people do that all the time in Australia and areas are still considered walkable.

Now if the intent is to make it harder to access on foot specifically so they can increase profits (create a problem for people and then sell them the solution), then it is possible they'll throw up more obstacles. I think Americans might be much more tolerant of what is called 'drip pricing' in Australia (and is illegal), where a low initial price is presented, but then lots of additional unavoidable expenses are presented (see also, some American retailers apparently exclude taxes from pricing, many Amercian hospitality providers underpay waitstaff and then demand that customers pay a 'tip' or 'service fee' that wasn't reflected in the menu price, and so on). In Australia, the law that is for sales to consumers, the total price has to be displayed up front at least as prominently as any other price - so unavoidable additional charges from the same (or a related) company wouldn't fly.

[–] A1kmm@lemmy.amxl.com 9 points 1 month ago (1 children)

I host my mail server on a VPS.

I suggest making sure you get DMARC / DKIM / SPF working, and having an anti-spam strategy (greylisting helps, but there are a few ASNs that just exist to send spam). Also make sure your IP is not on any public spam list.

The next problem you might face is that Microsoft and especially Google like to make it hard for anyone not using their services. With Microsoft, you fill in a form and jump through some hoops and they'll start accepting your email enough to land it in spam. Unless you are regularly sending to Microsoft, it is hard to keep them accepting mail, but just sending to a free Hotmail address (owned and occasionally marked as read and deleted by you!) on cron is enough to keep occasional mail deliverable as long as none of your mail ever gets marked as spam. Google can be more of a pain to small email servers in terms of not landing in spam, but I think occasional reports of not spam will help you.

In terms of keeping down spam:

  • postgrey or similar for greylisting keeps out the least serious spammers.
  • The notorious spammers / bulletproof hosting is best blocked by ASN since they regularly shift IP addresses. Try a script like this on daily cron (assuming you jump to the custom BAD_AS table from your INPUT iptables rule) - please don't run it too often since routeviews is a free public service and you should be respectful of them:
#!/bin/bash -e

TEMPDIR=$(mktemp -d)
trap 'rm -r "$TEMPDIR"' EXIT

curl https://archive.routeviews.org/oix-route-views/oix-full-snapshot-latest.dat.bz2 -Lo "$TEMPDIR/snapshot.bz2"
bzgrep -e " (15828|213035|400377|399471|210654|46573|211252|62904|135542|132372|36352|209641|7552|36352|12876|53667|138608|150393|60781|138607) i" $TEMPDIR/snapshot.bz2 | cut -d" " -f 3 | sort | uniq > $TEMPDIR/badranges

iptables -N BAD_AS || true
iptables -D INPUT -j BAD_AS || true
iptables -A INPUT -j BAD_AS
iptables -F BAD_AS

for ROUTE in $(cat "$TEMPDIR/badranges"); do
    iptables -A BAD_AS -s $ROUTE -j DROP;
done
  • Despite Google being so hostile to very infrequent emails from IPs that have years of never sending spam, just because they are small, Gmail and Firebase are one of the most significant spam sources. I find client-side filtering works best for things like that which get through your other defences.
  • Another spam source is Docusign. These types of companies tend to shut down individual scammer / spammer accounts, but then allow them back in for the same scam with another account.

Note that of the spam that gets through if you have the basic defences, it's probably a similar level to big corporate hosted mail, so don't let this deter you (I just hate spammers).

[–] A1kmm@lemmy.amxl.com 3 points 2 months ago (1 children)

idea of requiring attribution is specifically called out in Section 7, item B.

But requiring that the logo be retained is not.

Now, it's not entirely clear what they even are asking for. If the ask is that the OnlyOffice logo be included in a 'credits' page (which is perhaps a reasonable interpretation of "you must retain the original Product logo when distributing the program") then it is much less problematic, although perhaps still beyond requiring attribution, than if they are trying to demand that, say, the favicon of the webapp must not be changed (especially if their intent is also to say that you can't distribute the program if you don't change the favicon because it would be a trademark violation).

Now of course, if they have written all of OnlyOffice in house, and not had any external contributors or used any external copyleft code, then they can re-license OnlyOffice on whatever terms. If they were bound to the licence by including other people's AGPL contributions, then they have to follow the licence themselves, and cannot add arbitrary additional restrictions.

 

This happens if you have some third-party repositories that are still using SHA-1 signatures. A similar error happens with RPM-using distros too. Ideally, the repo owners would fix their repos, but until they do, if you want to accept the risk of them using SHA-1, you can set your own policy about when you'll accept SHA-1 until.

Both apt and rpm use a library that validates using Sequoia, a GnuPG compatible tool & library. It comes with a default policy to start rejecting SHA-1 as a hash from 2026-02-01, but it reads /etc/crypto-policies/back-ends/sequoia.config and accepts that.

So the solution is sudo mkdir -p /etc/crypto-policies/back-ends, and then sudo nano /etc/crypto-policies/back-ends/sequoia.config and pasting in:

[hash_algorithms]
sha1 = 2030-01-01 

That will give the repo owners until 2030 to fix the problem.

A note on security risk: SHA-1 in this case is used for revocation checks, and poses a very minor risk. If the repository's key is compromised, and they revoke it, but before it was revoked the attacker was able to manipulate a request in the right way, they might be able to get a signature that the key is not revoked that is also valid for a certain other time, and then extend how long they can keep using the leaked key.

On the other hand, I've seen tutorials on the Internet on how to solve this problem that amount to telling apt to always pass the validation check (i.e. don't actually validate) using APT::Key::GPGVCommand. For your own benefit, please don't do this, as that just requires using a dodgy mirror to compromise your system.

[–] A1kmm@lemmy.amxl.com 2 points 2 months ago (1 children)

is it technically possible to accurately verify someone’s age while respecting their privacy and if so how?

With your constraints yes, but there are open questions as to whether that would actually be enough.

Suppose there was a well-known government public key P_g, and a well protected corresponding government private key p_g, and every person i (i being their national identity number) had their own keypair p_i / P_i. The government would issue a certificate C_i including the date of birth and national identity number attesting that the owner of P_i has date of birth d.

Now when the person who knows p_i wants to access an age restricted site s, they generate a second site (or session) specific keypair P_s_i / p_s_i. They use ZK-STARKs to create a zero-knowledge proof that they have a C_i (secret parameter) that has a valid signature by P_g (public parameter), with a date of birth before some cutoff (DOB secret parameter, cutoff public parameter), and which includes key P_i (secret parameter), that they know p_i (secret parameter) corresponding to P_i, and that they know a hash h (secret parameter) such that h = H(s | P_s_i | p_i | t), where t is an issue time (public parameter, and s and P_s_i are also public parameters. They send the proof transcript to the site, and authenticate to the site using their site / session specific P_s_i key.

Know as to how this fits your constraints:

Let the service know that the user is an adult by providing a verifiable proof of adulthood (eg. A proof that’s signed by a trusted authority/government)

Yep - the service verifies the ZK-STARK proof to ensure the required properties hold.

Not let the service know any other information about the user besides what they already learn through http or TCP/IP

Due to the use of a ZKP, the service can only see the public parameters (plus network metadata). They'll see P_s_i (session specific), the DOB cutoff (so they'll know the user is born before the cutoff, but otherwise have no information about date of birth), and the site for which the session exists (which they'd know anyway).

Generating a ZK-STARK proof of a complexity similar to this (depending on the choice of hash, signing algorithm etc...) could potentially take about a minute on a fast desktop computer, and longer on slower mobile devices - so users might want to re-use the same proof across sessions, in which case this could let the service track users across sessions (although naive users probably allow this anyway through cookies, and privacy conscious users could pay the compute cost to generate a new session key every time).

Sites would likely want to limit how long proofs are valid for.

Not let a government or age verification authority know whenever a user is accessing 18+ content

In the above scheme, even if the government and the site collude, the zero-knowledge proof doesn't reveal the linkage between the session key and the ID of the user.

Make it difficult or impossible for a child to fake a proof of adulthood, eg. By downloading an already verified anonymous signing key shared by an adult, etc.

An adult could share / leak their P_s_i and p_s_i keypair anonymously, along with the proof. If sites had a limited validity period, this would limit the impact of a one-off-leak.

If the adult leaks the p_i and C_i, they would identify themselves.

However, if there were adults willing to circumvent the system in a more online way, they could set up an online system which allows anyone to generate a proof of age and generates keypairs on demand for a requested site. It would be impossible to defend against such online attacks in general, and by the anonymity properties (your second and third constraints), there would never be accountability for it (apart from tracking down the server generating the keypairs if it's a public offering, which would be quite difficult but not strictly impossible if it's say a Tor hidden service). What would be possible would be to limit the number of sessions per user per day (by including a hash of s, p_i and the day as a public parameter), and perhaps for sites to limit the amount of content per session.

Be simple enough to implement that non-technical people can do it without difficulty and without purchasing bespoke hardware

ZK-STARK proof generation can run on a CPU or GPU, and could be packaged up as say, a browser addon. The biggest frustration would be the proof generation time. It could be offloaded to cloud for users who trust the cloud provider but not the government or service provider.

Ideally not requiring any long term storage of personal information by a government or verification authority that could be compromised in a data breach

Governments already store people's date of birth (think birth certificates, passports, etc...), and would need to continue to do so to generate such certificates. They shouldn't need to store extra information.

[–] A1kmm@lemmy.amxl.com 2 points 2 months ago

More likely that change.org provides information about who signed (including emails unless opted out) to the person running the petition. Information gathering from informal petitions is more likely to undermine trust and make people less likely to sign, but then you can't build a database of people sympathetic to some cause and spam them afterwards.

The "20,000 petition signatures" feels like straight up manipulation - there's no magic number to force a debate at parliament, and as MisterFrog@aussie.zone points out, an official petition would be needed for it to be tabled. If an official petition with a lot of signatures is tabled, that is a signal to politicians that the public care about it, and can overcome lobbying in the other direction and apathy, so it increases the chance a bill is put up for debate.

This comes from an ad agency; they don't list any gambling companies as clients, but I'm sure they'd find information like a list of people who signed useful for something.

That said, it's still a good idea to regulate in a losing sound if there is no political will to do anything more drastic. Better yet would be to require linking play to a one-per-person card, and having hourly, daily, monthly and annual loss limits per card, after which the owner cannot allow any more losses for that card holder.

[–] A1kmm@lemmy.amxl.com 5 points 2 months ago (4 children)

In most jurisdictions, part of the definition of a not-for-profit (of which a charity is a more restricted subset) is that it doesn't exist for the benefit of the members / shareholders, or a specific person.

So creating a charity / NFP and asking people to pay into it is usually okay, but the purpose of that charity can't be to enrich you, and it is a separate legal identity (i.e. taking a charity's funds and giving it to yourself would be embezzling). Many jurisdictions allow for sports clubs to exist as not-for-profits, but they'd generally need to be for the purpose of organising a whole team to practice, compete and so on.

Generally charities can employ people to do work for them and pay them, but (varies by jurisdiction) they generally need to be not paid above a fair market rate for the work they actually do to advance the goals of the charity.

If the goal is to help a legitimate cause, you could also ask them to donate to an existing not-for-profit for the cause.

Disclaimer: IANAL, and anyway all of this would vary by jurisdiction - not legal advice!

[–] A1kmm@lemmy.amxl.com 7 points 2 months ago

Attacking a military ship is generally not a war crime (as defined by international law such as the Geneva treaties, Rome Statute etc...). It is an act of war (same as invasion or bombardment of another country), and is likely to see retaliation by the attacked country.

Aggression (i.e. unprovoked acts of war) is against the Charter of the United Nations, which also includes the International Court of Justice as a dispute resolution mechanism. It is up to the United Nations Security Council (at which the US has a veto) to authorise enforcement of ICJ rulings.

If a nation is acting to protect another nation facing aggression from the US, it would be legal for the attack US military ships. The reason why they wouldn't would more be that it would likely bring counter-retaliation from the US.

[–] A1kmm@lemmy.amxl.com 5 points 3 months ago

Liberal by itself is an ambiguous term, so it's generally best to prefix it with another word / prefix to clarify.

e.g. Neoliberal / Classical liberal - aligned to what I think parent post is saying. Implies economic right. Socially liberal - probably what the GP post means, meaning in favour of social liberties. Can be associated with economic left (usually coupled with positive protection of social liberties) or the economic right (e.g. libertarianism - usually believe government shouldn't trample social liberties, but businesses can). Liberal is also a political party in many countries - e.g. in Australia it is a (declining, but formerly in power) right-wing party.

That said, I believe most wars are started for reasons of cronyism / crony capitalism, to distract from issues or project an image for the leader and/or for reasons of nationalism, and politicians from all sides will give an insincere pretext aligned to the politics people expect them to have.

[–] A1kmm@lemmy.amxl.com 2 points 3 months ago (1 children)

Is there any evidence that Dayenu has actually said anything supporting the genocide? Their public web presence does not seem to have anything along those lines; if it is solely because they are Jewish, then I kind of think it is reasonable to deplatform PiP over it. Many Jewish people are anti-genocide, and it is not reasonable to try to punish an entire ethno-religious group for the actions of Netanyahu, Smotrich, Gallant, Ben-Gvir etc.; it is the same class of generalisation as trying to punish all Palestinians for October 7th (needless to say, genocide and seeking to exclude a group from Mardi Gras are very different ends of the same spectrum).

[–] A1kmm@lemmy.amxl.com 27 points 3 months ago (1 children)

So back in 1994 my neighbours and I agreed that I'd give them my anti-theft fog cannons, as long as they promise not to steal my stuff.

Then in 2014 they sent some buddies in to burgle my place, and got away with a chunk of my stuff - and I know it was said neighbour behind it, because they now openly claim what was taken is theirs (of course, I never agreed with them on that).

Then since February 2022 they've started regularly burgling my place - in the first few weeks, they tried to take literally everything, but fortunately I hired good security guards and they only got away with about 20% of my stuff (including what they stole in 2014).

I've been trying to make arrangements for a monitored alarm system that will bring in a large external response if more burglaries happen, but the security company doesn't want to take it on the contract while a burglary is in progress - but they did sell me some gear. I'm still working on getting the contract.

They say they'll stop trying to burgle my place as long as I promise not to ever get a monitored burglar alarm, to officially sign over the property they've already stolen and to stop trying to get it back, stop buying stuff to protect my property from the monitored security company, and that I fire most of my security guards.

Do you think this is really their end game, or if I agree, do you think they'll just be back burgling more as soon as I make those promises, with fewer security guards and stuff to protect my house? After all, I did have an agreement with them back in 1994 and they didn't follow that.

[–] A1kmm@lemmy.amxl.com 2 points 4 months ago

That doesn't work as a defence in common-law jurisdictions (at least), because all participants who deliberately participate in a crime are considered equally guilty of it.

I'd say this is not a strategy to avoid prosecution, but more the brazen acts of individuals who don't fear prosecution.

 

spoilerHe was the instar pupa.

 

Today, lemmy.amxl.com suffered an outage because the rootful Lemmy podman container crashed out, and wouldn't restart.

Fixing it turned out to be more complicated than I expected, so I'm documenting the steps here in case anyone else has a similar issue with a podman container.

I tried restarting it, but got an unexpected error the internal IP address (which I hand assign to containers) was already in use, despite the fact it wasn't running.

I create my Lemmy services with podman-compose, so I deleted the Lemmy services with podman-compose down, and then re-created them with podman-compose up - that usually fixes things when they are really broken. But this time, I got a message like:

level=error msg=""IPAM error: requested ip address 172.19.10.11 is already allocated to container ID 36e1a622f261862d592b7ceb05db776051003a4422d6502ea483f275b5c390f2""

The only problem is that the referenced container actually didn't exist at all in the output of podman ps -a - in other words, podman thought the IP address was in use by a container that it didn't know anything about! The IP address has effectively been 'leaked'.

After digging into the internals, and a few false starts trying to track down where the leaked info was kept, I found it was kept in a BoltDB file at /run/containers/networks/ipam.db - that's apparently the 'IP allocation' database. Now, the good thing about /run is it is wiped on system restart - although I didn't really want to restart all my containers just to fix Lemmy.

BoltDB doesn't come with a lot of tools, but you can install a TUI editor like this: go install github.com/br0xen/boltbrowser@latest.

I made a backup of /run/containers/networks/ipam.db just in case I screwed it up.

Then I ran sudo ~/go/bin/boltbrowser /run/containers/networks/ipam.db to open the DB (this will lock the DB and stop any containers starting or otherwise changing IP statuses until you exit).

I found the networks that were impacted, and expanded the bucket (BoltDB has a hierarchy of buckets, and eventually you get key/value pairs) for those networks, and then for the CIDR ranges the leaked IP was in. In that list, I found a record with a value equal to the container that didn't actually exist. I used D to tell boltbrowser to delete that key/value pair. I also cleaned up under ids - where this time the key was the container ID that no longer existed - and repeated for both networks my container was in.

I then exited out of boltbrowser with q.

After that, I brought my Lemmy containers back up with podman-compose up -d - and everything then worked cleanly.

 

I'm logging my idea across a series of posts with essays on different sub-parts of it in a Lemmy community created for it.

What do you think - does anyone see any obvious problems that might come up as it is implemented? Is there anything you'd do differently?

There are still some big decisions (e.g. how to do the ZKP part, including what type of ZKPs to use), and some big unknowns (I'm still not certain implementing TLS 1.3 on TPM 2.0 primitives is going to stand up and/or create a valid audit hash attestation to go into the proof, and the proofs might test the limits of what's possible).

 

Looks like it is also flowing into huge numbers of people using the trams.

 

Stallman was right - non-Free JavaScript does hostile things like this to the user on who's computer it is running.

view more: next ›