BOTS ARE EVERYWHERE. 50% of all Internet traffic are bots, 66% of bot traffic is malicious, 43% targets SMBs. @robert

Vibe Coding ist solange lustig bis alle internen Daten abgeflossen sind: https://www.heise.de/news/Sensible-Unternehmensdaten-ueber-Sicherheitsprobleme-bei-KI-Firma-kompromittiert-10731728.html
I get the impression that most people don't understand how important metadata such as phone numbers is when it comes to privacy.
For example, by requiring phone numbers, Signal, despite its good encryption, inherently builds a social graph. The server operators, or anyone who gets that data, can see a map of who is talking to whom. The content is secure, but the connections are not.
🧵

We've just fought #ChatControl - now Ireland 🇮🇪 wants its own backdoor law. 🔓
But we, together with ~40 orgs, are saying no.
Read our open letter to Ireland: 👉 https://www.globalencryption.org/2025/10/open-letter-irish-communications-interception-and-lawful-access-bill/

Well done for making us all safe online:

Want to send messages and video calls with:
* no installs
* no sign-ups
* no tracking
* end-to-end encryption
This new prototype uses PeerJS to establish a secure browser-to-browser connection. Everything is ephemeral and cleared when you refresh the page—true zerodata privacy!
Check out the [testable demo here](https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story).
I am working towards a look-and-feel to match Whatsapp as seen in this [hardcoded UI demo](http://glitr.positive-intentions.com).
IMPORTANT NOTE: This is still a work-in-progress and a close-source project. It is based on the open source MVP see [here](https://github.com/positive-intentions/chat). It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app.
* Docs: https://positive-intentions.com/docs/category/sparcle
* Reddit: https://www.reddit.com/r/positive_intentions
* GitHub: https://github.com/positive-intentions
#P2P #WebRTC #PeerJS #ZeroData #EphemeralData #Encryption #E2EE #BrowserToBrowser #NoInstall #Privacy #Security #Decentralized #Messaging #VideoCall #NoTracking #PrivateMessaging #Prototype #Demo #WorkInProgress #CloseSource #OpenSource #WebDev #GitHub #TechDevelopment #WhatsApp #ChatApp #InstantMessaging
Well done for making us all safe online:
We've just fought #ChatControl - now Ireland 🇮🇪 wants its own backdoor law. 🔓
But we, together with ~40 orgs, are saying no.
Read our open letter to Ireland: 👉 https://www.globalencryption.org/2025/10/open-letter-irish-communications-interception-and-lawful-access-bill/
Want to send messages and video calls with:
* no installs
* no sign-ups
* no tracking
* end-to-end encryption
This new prototype uses PeerJS to establish a secure browser-to-browser connection. Everything is ephemeral and cleared when you refresh the page—true zerodata privacy!
Check out the [testable demo here](https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story).
I am working towards a look-and-feel to match Whatsapp as seen in this [hardcoded UI demo](http://glitr.positive-intentions.com).
IMPORTANT NOTE: This is still a work-in-progress and a close-source project. It is based on the open source MVP see [here](https://github.com/positive-intentions/chat). It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app.
* Docs: https://positive-intentions.com/docs/category/sparcle
* Reddit: https://www.reddit.com/r/positive_intentions
* GitHub: https://github.com/positive-intentions
#P2P #WebRTC #PeerJS #ZeroData #EphemeralData #Encryption #E2EE #BrowserToBrowser #NoInstall #Privacy #Security #Decentralized #Messaging #VideoCall #NoTracking #PrivateMessaging #Prototype #Demo #WorkInProgress #CloseSource #OpenSource #WebDev #GitHub #TechDevelopment #WhatsApp #ChatApp #InstantMessaging
@sveckert berichtet im MoMa über die Sicherheitslücken in der Buchungssoftware von Motel One (und einigen Jugendherbergen)
https://www.tagesschau.de/investigativ/ndr-wdr/hotel-daten-sicherheitsluecken-software-100.html
/ cc @bjoernsta
#MotelOne #security
Vibe Coding ist solange lustig bis alle internen Daten abgeflossen sind: https://www.heise.de/news/Sensible-Unternehmensdaten-ueber-Sicherheitsprobleme-bei-KI-Firma-kompromittiert-10731728.html

The 8 most common attacks on marketplaces, and how to defend against them.
Super interesting and important article by Mira and @boyan from Sharetribe.
Includes a sneak peek at our company Slack showing what really happens when there's an ongoing DDoS attack!
https://www.sharetribe.com/academy/most-common-marketplace-attacks/

I submitted a Pull Request to update MacPorts' OpenSSH to 10.1p1 here:
https://github.com/macports/macports-ports/pull/28592
GitHub Continuous Integration checks passed OK!
Alas, the agent.patch that iamGavinJ had created, doesn't apply cleanly, in large part because ssh-agent.c has been reworked significantly with this release.
Subsequently, I closed this previous Pull Request: https://github.com/macports/macports-ports/pull/28592 not because I didn't want to restore that functionality to launchd, but because it will require more effort than I can give such things at this time.
But, check out these improvements to ssh-agent from the OpenSSH 10.1 release notes:
"ssh-agent(1)](https://man.openbsd.org/ssh-agent.1), sshd(8): move agent listener sockets from /tmp to
under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
in sshd(8).
This ensures processes that have restricted filesystem access
that includes /tmp do not ambiently have the ability to use keys
in an agent.
Moving the default directory has the consequence that the OS will
no longer clean up stale agent sockets, so ssh-agent now gains
this ability.
To support $HOME on NFS, the socket path includes a truncated
hash of the hostname. ssh-agent will, by default, only clean up
sockets from the same hostname.
ssh-agent(1) gains some new flags: -U suppresses the automatic
cleanup of stale sockets when it starts. -u forces a cleanup
without keeping a running agent, -uu forces a cleanup that ignores
the hostname. -T makes ssh-agent put the socket back in /tmp."
Anyway, I updated this as well:
https://trac.macports.org/ticket/72482
I should probably actually close this ticket now that I think of it (fingers crossed that adding that to the PR is sufficient, since I forgot to add that note to the commit message as is typically preferred: https://trac.macports.org/ticket/73084).
#OpenSSH #MacPorts #SecureShell #macOS #encryption #security #infosec
I submitted a Pull Request to update MacPorts' OpenSSH to 10.1p1 here:
https://github.com/macports/macports-ports/pull/28592
GitHub Continuous Integration checks passed OK!
Alas, the agent.patch that iamGavinJ had created, doesn't apply cleanly, in large part because ssh-agent.c has been reworked significantly with this release.
Subsequently, I closed this previous Pull Request: https://github.com/macports/macports-ports/pull/28592 not because I didn't want to restore that functionality to launchd, but because it will require more effort than I can give such things at this time.
But, check out these improvements to ssh-agent from the OpenSSH 10.1 release notes:
"ssh-agent(1)](https://man.openbsd.org/ssh-agent.1), sshd(8): move agent listener sockets from /tmp to
under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
in sshd(8).
This ensures processes that have restricted filesystem access
that includes /tmp do not ambiently have the ability to use keys
in an agent.
Moving the default directory has the consequence that the OS will
no longer clean up stale agent sockets, so ssh-agent now gains
this ability.
To support $HOME on NFS, the socket path includes a truncated
hash of the hostname. ssh-agent will, by default, only clean up
sockets from the same hostname.
ssh-agent(1) gains some new flags: -U suppresses the automatic
cleanup of stale sockets when it starts. -u forces a cleanup
without keeping a running agent, -uu forces a cleanup that ignores
the hostname. -T makes ssh-agent put the socket back in /tmp."
Anyway, I updated this as well:
https://trac.macports.org/ticket/72482
I should probably actually close this ticket now that I think of it (fingers crossed that adding that to the PR is sufficient, since I forgot to add that note to the commit message as is typically preferred: https://trac.macports.org/ticket/73084).
#OpenSSH #MacPorts #SecureShell #macOS #encryption #security #infosec

