C'est une révolution ! Esthétique. Le "Centre National de Ressources Textuelles et Lexicales" a fait peau neuve 😁
@Federation_Bot
- Joined
RE: https://eigenmagic.net/@daedalus/117239893679583009
Wonder what LG TV’s got.
It's #909 day, celebrating the classic Roland TR-909 drum machine that helped make Detroit and then Berlin the capitals of #Techno
Here's some acrid #acid techno over it's classic kick, hats claps, snares and ride cymbals. I can't afford a real 909 (and lord knows I don't have the desk space) so my mate Billy lent me his little sampler to jam with at the weekend:
@Migueldeicaza got me good, today.
Raspberry Pi Pico 2 W / RP2350 + 64*64 LED panel. Embedded #Swift.
Here’s AC432 setting up for landing at YUL.
Project: https://seancoates.com/blogs/yulbbs
( mini output: telnet yulbbs.via.sc 12323 )
#YULBBS https://mastodon.social/@Migueldeicaza/117236627660966146
Agreed. The trust question is the whole ballgame for the agentic web. An agent is only useful if you hand it your inbox, calendar, and wallet, so the bet is who would you trust this with? Not Meta. Not Google. Not AI tech. Watching this one closely.
NameDrop.io is a great little feature, to let folk know how to pronounce your name. I was looking up the bio of Mai Nguyen, whose book "Cleo Dang would Rather be Dead" is shortlisted for the Giller prize. At the end of the bio on her website, it says:
"Born in Winnipeg and raised in Halifax, Mai currently lives in Toronto with her husband, daughter, and French bulldog.
Her name is pronounced like My Nwin (https://namedrop.io/mainguyen)".
Pusheen’s first game is coming to Apple Arcade
https://www.theverge.com/games/991398/pusheen-apple-arcade-game?utm_source=flipboard&utm_medium=activitypub
Posted into Tech News @tech-news-theverge
@kittylyst I don't have any personal connections to AMS (I just use their fireball website a lot). So, I don't know. Presumably they would have asked on their "we're broken" page?
@sundogplanets @kittylyst AMS is likely still determining the scope of the damage and what will need to happen to recover and rebuild.
I read earlier this year about a scenario where a site that tracked boxoffice data for decades was essentially scraped to death by bots *and* hacked, and it quickly became apparent that getting the legacy code/data to a safe status and compatible with the new infrastructure was going to be an immense task.
https://stephenfollows.com/p/what-just-happened-to-thenumberscom-should-worry-us-all
ActivityPub - Is it worth defending against replay attacks and message/signature time skew?
https://shkspr.mobi/blog/2026/09/activitypub-is-it-worth-defending-against-replay-attacks-and-message-signature-time-skew/Here's a problem that I've found with ActivityBot - my little ActivityPub server. Sometimes it receives messages which were originally sent months ago. Why does that happen and is it risky to accept and process them?
My tl;dr is that it probably isn't worth worrying about. But I'd love someone to tell me why I'm wrong.
Here's my thinking:
Causes
All ActivityPub messages should have a "published" timestamp in their body. Some will have an "updated" timestamp. That tells you, unsurprisingly, when the message is alleged to have been originally published or updated. That time might be very different to the time you receive the message.
There are, I think, three different reasons why a server might receive a message which has an out-of-date timestamp.
The first is that sometimes servers are just slow. Processing thousands of messages at the same time means that some of those messages take a while to send. ActivityPub is one big chain-mail so it can take several minutes for a message to be sent to all your followers.
Similarly, your server might be slow. If it doesn't acknowledge receipt of a message, the original server will try sending it again. Sometimes that can take a while.
Finally, some servers take a relaxed view of standards. They send an update to an old message but keep the original publication date. Ideally, they'd use an "updated" timestamp but quite often they don't.
For the purposes of checking the legitimacy of the message, you do not need to check when a message says it was published or updated. You might want to check it isn't an obviously bogus date like far in the future or impossibly far in the past - but that's up to you.
It is normal that your server receives messages which appear to have been published at a totally different time from now.
Is that a problem?
Probably not.
As described above, there are various reasons why a message may be delayed in transit - or may appear to come from the distant past.
What we can check is when the message was cryptographically signed by the sending server. This is independent of its published or updated timestamp.
HTTP requests to your server will have a date header which looks like Tue, 01 Sep 2026 15:54:21 GMT - this is in the slightly peculiar and Anglocentric RFC 5322 format.
New style RFC 9421 headers will also have a signature-input header which will contain something like created=1788278061. That uses the slightly obscure UNIX / POSIX time which counts seconds since the "Epoch" of 1st January 1970.
If you convert the UNIX time to something more modern, you should get an identical value to the date header.
But that isn't always the case. For example, the RFC 9421 standard gives this example:
Date: Tue, 20 Apr 2021 02:07:55 GMT "@signature-params": ("@method" "@authority" "@path" \ "content-digest" "content-length" "content-type")\ ;created=1618884473;keyid="test-key-rsa-pss"
Converting 1618884473 to normal time gives Tue, 20 Apr 2021 02:07:53 - a two second difference.
If the date and created values differ significantly - that may indicate that the message is untrustworthy. Or that there was a delay between the signing and the sending.
The spec says:
The Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the created signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the created signature parameter for such calculations. An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages.
7.2.4. Choosing Signature Parameters and Derived Components over HTTP Fields
But, of course, it doesn't tell you how much skew is problematic. It's up to you how much skew you're prepared to accept.
So that's the difference between the sent time and the signed time. The next time to check is your own. As we've discussed, sometimes servers are slow sending things out. Would you accept a request that was signed five minutes ago? Five days ago? Five months ago? What amount of difference is dangerous?
Here's what various services and sages have to say:
Mastodon
The request contains a Date header. Compare it with current date and time within a reasonable time window to prevent replay attacks.
What is "reasonable"? The source code suggests one hour.
Grishka
Time in the Date header must differ from the recipient server’s clock by no more than 30 seconds
Evan Prodromou
static #maxDateDiff = 5 * 60 * 1000 // 5 minutes
SWICG
The standards don't give a concrete time window to use for this comparison. In practice, an hour plus a few minutes buffer in either direction may be a good value, to account for both clock skew and differences in time zone/daylight savings time configuration across systems.
Others
Without naming names, it looks like a bunch of popular servers don't check whether there's a significant difference between the date the request was signed and the date it was received.
Summary
Various documents and implementations recommend anything between 30 seconds to "a bit more than 60 minutes". Or they just ignore any date difference.
What's the right answer? What happens if the signed date is significantly different from the current date?
What are we trying to protect against?
Replay Attacks. Suppose someone is listening to the communications between the sending server and your server. They copy the message that is sent to you. Later they send it again!
At this point, you might be thinking "so what?" and… I'm inclined to agree with you!
What's the worst that could happen if you received the same message multiple times? Two things that I can think of.
Firstly, it might not be the same message. It is possible to send a new message but with old headers. An attacker could make someone post "I hate Taylor Swift" against their will and watch as legions of fans disembowel the victim.
Except, I don't think this is likely. The signature in the header contains a hash of the message being sent. If you are properly validating the signature, a changed message will have a different hash from the one in the original message. You don't need to check timestamps, you just need to check if the hashes match.
Secondly, idempotence. That's a fancy word for "pressing the button multiple times should only result in one action".
What happens if a user appears to send you multiple "like" messages for a single post? You only record one like.
What if they send multiple messages with the same content? Well, each will have a unique ID in the message - so you only post it once.
What if they send multiple anythings? I can't think of any ActivityPub action which would not be idempotent.
About the worst thing I can think of is this:
- Alice sends a message to you saying "I want to follow Bob".
- Mallory intercepts this message.
- You record Alice is now following Bob.
- Alice sends a message to you saying "I want to unfollow Bob".
- You record the severed relationship.
- Mallory replays the original follow message.
- You record Alice is now following Bob.
It's also possible the following could happen:
- Alice posts a message saying "I love The Beatles".
- You record Alice's message and display it on the timeline.
- Alice updates her post to say "I love the Rolling Stones".
- Mallory intercepts this message.
- You record Alice's updated message and display the new version on the timeline.
- Alice updates her post yet again to say "I love the Spice Girls".
- You record Alice's updated message and display the new version on the timeline.
- Mallory replays the original update message.
- You now display that Alice loves the Stones rather than Spice Girls.
Perhaps the same can happen with like/unlike, block/unblock, boost/unboost.
But none of that is significantly prevented by checking the date.
Ultimately, it is up to your sever to check the unique ID of each message and refuse to action any repeated messages. You may not want to trust the unique ID which is sent with the message. If that's the case, you can calculate your own - perhaps using a hash of the contents, the signature, or some other process which will generate an ID based on the message.
Putting it all together
Here's what you need to do to prevent replay attacks:
- Independently calculate the hash of the message received.
- Validate that your calculated hash matches the hash sent in the message's HTTP headers.
- If not, this is a potential replay attack and the message must be ignored.
- Verify that the signature received in the message's HTTP headers includes the message hash and is cryptographically valid.
- If not, the signature is invalid and the message must be ignored.
- Has the received message's unique ID already been processed?
- If so, refuse to process it again.
I don't see what checking the timestamp of the HTTP signature has to do with anything. Someone who has access to the original messages and their headers could send them milliseconds after the original delivery.
I think it is probably pragmatic to give messages 60ish minutes grace before dropping them. Delays happen, but anything more significant than an hour might indicate a attack. But, equally, might just mean that the Internet is having a slow day.
If you are correctly checking signatures and hashes, I don't think you need to worry about skew between signature date and delivery date.
No! You're wrong and I can prove it!
Please tell me where I have erred! Stick a comment in the box or drop me an email. If I've made a massive or subtle mistake, I'd love to know what.
#ActivityBot #ActivityPub #http #security
Apple says ‘Fold’ and competitors ask ‘how wide?’
https://www.theverge.com/tech/991141/apple-first-foldable-iphone-launch-influence-john-ternus?utm_source=flipboard&utm_medium=activitypub
Posted into Tech News @tech-news-theverge
La diminuzione della formazione stellare non è causata da una semplice “crisi di combustibile”, secondo quanto suggeriscono nuove misurazioni
@astronomia @astronomia@feddit.it @astronomia@diggita.com
L’universo sta producendo sempre meno “neonati” stellari. Negli ultimi 4,5 miliardi di anni, il tasso di nascita delle stelle è crollato a meno della metà di quello che era un tempo. Ma ecco il colpo di scena: il “carburante” essenziale per creare le stelle è diminuito appena.
https://umbertogaetani.substack.com/p/la-diminuzione-della-formazione-stellare
Britain's national grid operator claims that they are now "too reliant" on Palantir to stop using them.
That's Palantir's entire business model in a nutshell.
https://www.ft.com/content/f6a26a17-985f-4283-99c4-ba5d54e94e7f
LBT¹: Big props to whoever looked at lithium ion cells and thought "You know what would make them even better? FLUORINE!"
Pro-Russia, Nazi linked, Musk endorsed right extremists won the Saxony-Anhalt election short of a majority. At least two candidates under investigation for Nazi links.
AfD backs ending Russian sanctions, ending aid to Ukraine, leaving the EU, expelling migrants, and restoring Nord Stream gas.
Pro-Russia AfD wins Saxony-Anh...
How we talk about tech matters. Talking about AI as acting on its own lets companies swindle investors and escape responsibility for AI harms. The “AI agent” framing is a marketing tactic and a liability dodge.
@tiffanycli If I were looking for non-anthropomorphizing language about LLMs, the first place I'd look for inspiration is the article referenced in the post below.
The second place I'd look, in case a bit more of a humorous framing were in order, is a recent Cal Newport talk, based on which I've explained to non-technical clients: If you train a dog to trim grass with a weed whacker, and strap that weed whacker to the dog and start it up, and the dog runs off to chase a squirrel and injures someone in the process, the responsibility rests not with the dog, but with you who strapped the weed whacker to the dog.
If you're discussing legal liability or anything else academic, technical, professional, or otherwise serious, I'd go with such language as Prof. Bender and Dr. Inie recommend.
https://dair-community.social/@emilymbender/116811128152569506
Trump admin defunds bicycle lanes, calling them DEI –
The admin said bike lanes are "hostile to motor vehicles," and roads, bridges, and shipping ports are "the backbone of America."
It also took safety resources for bike riders off of its website and canceled grants to improve street safety.
1 of 2🧵
#USA #trump #TrumpAdmin #DEI #ClimateChange #transportation #infrastructure #roads #vehicles #bicycles #exercise
The American government; a wholly owned subsidiary of the fossil fuel industry
https://www.rollingstone.com/politics/politics-lists/climate-enemies-ceos-oilmen-politicians-975667/
The US Supreme Court
https://www.motherjones.com/politics/2026/06/supreme-court-amicus-briefs-investigation/
US Agencies
https://theintercept.com/2022/06/30/supreme-court-epa-climate-charles-koch/
https://www.citizen.org/article/tracker-trump-appointees-in-the-pocket-of-big-corporations/
Congress
https://www.theguardian.com/commentisfree/2016/nov/30/donald-trump-george-monbiot-misinformation
https://www.hcn.org/articles/donald-trumps-cabinet-choices-reflect-koch-influence/
https://www.newyorker.com/news/news-desk/koch-pledge-tied-to-congressional-climate-inaction
https://www.nytimes.com/2025/01/25/climate/epa-staff-oil-gas-chemical-industry-lobbyists.html
State legislatures
https://www.eenews.net/articles/oil-electric-cash-fuels-texas-gop-campaigns/
https://whyy.org/articles/koch-brothers-groups-sue-delaware-campaign-finance-law-donors/
🦨Fox Stamps' demo is now out! Check out 30 puzzles in this nonogram game designed to be approachable for new players and long time players alike!
Steam: https://store.steampowered.com/app/4802880/Fox_Stamps_Demo/
Itch: https://cyansorcery.itch.io/fox-stamps
1 more link(s)
Xiaomi’s wide foldable promises more power than Samsung’s
https://www.theverge.com/tech/991008/xiaomi-18-fold-hands-on-impressions-specs-wide?utm_source=flipboard&utm_medium=activitypub
Posted into Tech News @tech-news-theverge
