Facebook
Google
GitHub
Linkedin
Privacy lost...
- Thread starter cmartinez
- Start date
While I have a lot of sympathy for his position, if he's using his lobster fishing boat for personal trips, he has other problems associated with using business assets for personal use. There are both tax and legal implications of doing that and I'd be surprised if he is doing it in a way that is proper and protecting himself from those implications.
That guy hasn't aged a day ...
While she was stupid for typing anything at a keyboard that she wasn't willing to see published on the front page of The New York Times, I'm really hoping that this gets thrown out. I don't think that writing something that you have no intention of sharing with anyone constitutes a threat. If they find something else that establishes any intent to take any action, by all means, go after her for that.
I agree ... one could argue that the situation is similar to the difference between a private conversation and a public statement
That could actually be argued either way, I suppose. If I write something in a diary, that shouldn't constitute a threat. But if I say something to my neighbor and they report it, that could trigger something. So you could argue that having a "conversation" with a chatbot is the same and that, like the neighbor, the chatbot could report it and that could trigger the same thing. Though, again, neither should by itself constitute a prosecutable offense (in my opinion). I think this is going to be an interesting case to watch because it is getting into where some boundaries are that haven't been clearly delineated.
Here's the relevant Florida statute.
So the prosecutors will argue that she clearly violated this law since posting something in a chatbot does so in a manner in which it may be viewed by another person. The law doesn't say anything about there needing to be any intent that it be so viewed.
But, in 2023, the U.S. Supreme Court ruled in Counterman v. Colorado that "the State must show that the defendant consciously disregarded a substantial risk that his communications would be viewed as threatening violence."
https://arstechnica.com/security/20...t-after-discovery-of-8-compromised-tls-certs/
Security personnel around the world are on high alert Tuesday following the discovery of eight TLS certificates with private keys so weak they could allow anyone to mint trusted browser and app credentials for any site on the Internet.
As of late morning Tuesday, browser makers and some major apps and programming languages had blocked all eight of the intermediate certificates. There are no reports of certificate transparency logs, which track the issuance of all browser-trusted certificates, showing the compromised keys being used maliciously. The threat remains far from over, however, because it will be hard and time-consuming to update other key parts of the Internet, such as Linux distributions and embedded and Internet of Things devices.
...
The compromised eMudhra keys were defective at a level that’s challenging the imagination of many of the engineers studying the incident. A normal size for a NIST P-384 elliptic curve cryptography private key contains roughly 384 bits of entropy, a size allowing almost 2384, or a number with 116 digits, different possibilities. The private key sizes of the compromised keys ranged from 3 to 8 bits. Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
“That is extremely in the ‘this should not be possible’ category,” Valdorda said. “Maybe some horribly dangerous key generation interface has a ‘size’ parameter and they set it to 1 by mistake???”
Ben Cartwright-Cox, director of BGP.tools, said: “My guess is that it’s example code that accidentally leaked to production, but hard to know. But it’s bonkers that no one noticed.”
Security personnel around the world are on high alert Tuesday following the discovery of eight TLS certificates with private keys so weak they could allow anyone to mint trusted browser and app credentials for any site on the Internet.
As of late morning Tuesday, browser makers and some major apps and programming languages had blocked all eight of the intermediate certificates. There are no reports of certificate transparency logs, which track the issuance of all browser-trusted certificates, showing the compromised keys being used maliciously. The threat remains far from over, however, because it will be hard and time-consuming to update other key parts of the Internet, such as Linux distributions and embedded and Internet of Things devices.
...
The compromised eMudhra keys were defective at a level that’s challenging the imagination of many of the engineers studying the incident. A normal size for a NIST P-384 elliptic curve cryptography private key contains roughly 384 bits of entropy, a size allowing almost 2384, or a number with 116 digits, different possibilities. The private key sizes of the compromised keys ranged from 3 to 8 bits. Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
“That is extremely in the ‘this should not be possible’ category,” Valdorda said. “Maybe some horribly dangerous key generation interface has a ‘size’ parameter and they set it to 1 by mistake???”
Ben Cartwright-Cox, director of BGP.tools, said: “My guess is that it’s example code that accidentally leaked to production, but hard to know. But it’s bonkers that no one noticed.”
https://www.php.net/archive/2026.php#2026-10-20-1
21 Oct 2026Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
21 Oct 2026Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
- RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
- RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
Fool me once, ...
https://www.yahoo.com/news/world/articles/supermarket-freezers-across-europe-struck-121728947.html
Supermarket freezers across Europe struck in second crippling cyberattack
https://www.yahoo.com/news/world/articles/supermarket-freezers-across-europe-struck-121728947.html
Supermarket freezers across Europe struck in second crippling cyberattack
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
|
Privacy and security tips for windows android and ios | Off-Topic | 0 | |
|
You're 4 microseconds late, Jetson! NTP at NIST Boulder has lost power | General Science, Physics & Math | 9 |
