privacy is another good reason for paying with cash. What's the point of using encrypted comms or ad blockers or taking other privacy-preserving measures and then buying everything with a payment card? Payment cards allow data brokers to track every purchase you make, every business you visit and when. When you split a check with someone else, it lets them know who your friends and coworkers are. The amount of privacy lost using payment cards is astounding.
So many responses from people trying to find reasons to hold onto their payment cards. Fine, go ahead. Have your purchases, contacts and whereabouts permanently stored and tracked. Just don't lecture anyone about the dangers of unencrypted comms or website tracking.
If you're choosing locally owned businesses for your coffee, groceries or other things, kudos for supporting alternatives to corporate-owned outlets. A reminder that paying with cash allows them to keep the full proceeds rather than sharing them with moneygrubbing banks and payment processors.
A fork of the Signal Messenger known as Sessions has omitted several important security properties found in the original source code, making it a less secure alternative, a researcher says. The deficiencies include:
-- no forward secrecy
insufficient Entropy in Ed25519 Keys
no in-Band Negotiation for Message Signatures
using Public Keys as AES-GCM Keys
Stay away from this offering unless you really, really, really know what you're doing:
Color me unimpressed. Mark is continuing to use a platform he believes is has descended into "toxic masculinity and Neo-Nazi madness." So much for principles.
Do you have experience implementing passkey authentication on your organization’s website or network? Have you supported the use of passkeys for end users? Have you spent time testing the way passkeys sync/work across platforms (Apple, Windows, etc.) or on different sites that have rolled out this new authentication paradigm? If so, I’m eager to speak with for an article I’m working on. Please DM me on Signal (DanArs.82) or (if you must) DM me here. Please boost for reach.
Over at the bad place, @evilsocket has reported an unauthenticated RCE in all GNU/Linux systems.
Canonical, RedHat and others have confirmed the severity, rating it a 9.9. Despite this, no working fix or CVE has been issued. Simone says the devs responsible are being defensive and dragging their feet.
It’s not every day that a security researcher acquires the ability to generate counterfeit HTTPS certificates, track email activity, and execute code of his choice on thousands of servers—all in a single blow that cost only $20 and a few minutes to land. But that’s exactly what happened recently to Benjamin Harris.
The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-size device vulnerable to cloning when an attacker gains brief physical access to it, researchers said Tuesday.
The cryptographic flaw, known as a side channel, resides in a small microcontroller that’s used in a vast number of other authentication devices, including smartcards used in banking, electronic passports, and the accessing of secure areas. While the researchers have confirmed all YubiKey 5 series models can be cloned, they haven’t tested other devices using the microcontroller, which is SLE78 made by Infineon and successor microcontrollers known as the Infineon Optiga Trust M and the Infineon Optiga TPM. The researchers suspect that any device using any of these three microcontrollers and the Infineon cryptographic library contains the same vulnerability.
Malicious hackers likely working on behalf of the Chinese government have been exploiting a high-severity zero-day vulnerability that allowed them to infect at least four US-based ISPs with malware that steals credentials used by downstream customers.
The government has sued Georgia Tech for failing to use antivirus software as mandated by a DoD grant for years, knowing it wasn't in compliance, and then submitting invoices for DoD projects anyway.
@lauren has discovered that Chrome 128, released in the past 24 hours, no longer works on Ubuntu 18.04, a release that Canonical is supporting until 2028. Can anyone point me to Chrome 128 not working on other OS versions still in support?
When you put it like that ("boil down to 'requests html forms could make in the early 2000s") it sounds like there is NOT a lot of harm that can result from exploits. Am I understanding you correctly?