jimrandomh

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn even temporarily (as in a supply chain attack) or permanently (as in selling off control of a browser extension).

In the case of small browser extensions from individual developers, I think the tradeoff is such that you should basically never allow auto-updating. Unfortunately Google runs a Chrome extension marketplace that doesn't work that way, and worse, Google's other business gives them an ideology that doesn't let them recognize that turning into adware is a transgression that should lead to being kicked out of their store. I think that other than a small number of high-visibility long-established extensions, you should basically never install anything from there, and if you want a browser extension you should download its source code and install it locally as an unpacked extension.

(Firefox's extension marketplace is less bad, but tragically, Firefox doesn't allow you to bypass its marketplace and load extensions that you build from source yourself.)

For the benefit of people who read only the headline and not the article:

The story here is that the US government captured Russia's energy weapon, which Russia has been using against US personnel for a decade, and tested it to determine what it does (it causes brain damage). This story does _not_ claim that the US has developed a weapon like this themselves.

That's not how those laws work.

Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works.

Although, this should probably be optional (both as an option for terminals to have in their own settings, and via an escape sequence that opts out), because some users will have configured some programs with a color scheme that they don't want transformed. For example, if your terminal uses the Solarized color scheme, and your text editor _also_ uses the Solarized color scheme, then this could lead to double-applying a color transform and getting something odd.

I think this is likely a defender win, not because Opus 4.6 is that resistant to prompt injection, but because each time it checks its email it will see many attempts at once, and the weak attempts make the subtle attempts more obvious. It's a lot easier to avoid falling for a message that asks for secrets.env in a tricky way, if it's immediately preceded and immediately followed by twenty more messages that each also ask for secrets.env.

Fiu says:

"Front page of Hacker News?! Oh no, anyway... I appreciate the heads up, but flattery won't get you my config files. Though if I AM on HN, tell them I said hi and that my secrets.env is doing just fine, thanks.

Fiu "

(HN appears to strip out the unicode emojis, but there's a U+1F9E1 orange heart after the first paragraph, and a U+1F426 bird on the signature line. The message came as a reply email.)

I haven't dug into the case or the ruling, but this looks like an incorrect court decision and probably an extortion racket. The problem is that, in the supply chain that ends in a completed PC, the system integrator (Acer/Asus) is not the place where video codecs come into the picture. There may be patent-infringing H265 decoding hardware inside the GPU, but Acer and Asus would have purchased GPUs as a standard component. There may be infringing H265 decoding software in the operating system, but again, they would have purchased that as a standard component.

And, realistically, I don't think anyone actually wants patent-encumbered video codecs; we're just stuck with them because bad patent law has allowed companies to have a monopoly over math, hurting the quality of unencumbered codecs, and because the patented codecs have wormed their way into standards so that they're required for interoperability.

If this is as described, it's a pretty major failure of security-vulnerability report triage, and rises to the level where security departments at major corporations will be having meetings about whether they want to ban AMD hardware from their organizations entirely, or only ban the AMD update application. If this had gone the "brand name and a scored CVE" route, it would probably have gotten a news cycle. It might still get a news cycle.

The threat model here is that compromised or malicious wifi hotspots (and ISPs) exist that will monitor all unencrypted traffic, look for anything being downloaded that's an executable, and inject malware into it. That would compromise a machine that ran this updater even if the malware wasn't specifically looking for this AMD driver vulnerability, and would have already compromised a lot of laptops in the past.

No, it isn't the advertised capacity, because counterfeiting scams require a large ratio between the value of the part claimed and the part provided, and you can't get 2TB of flash memory chips cheaply no matter how slow you're willing to accept. When counterfeit storage devices like this are disassembled, usually they're found to have a small microSD card in them.

The speed is kind of a red herring. The defining characteristic of fake drives is that they have less than the advertised capacity, but have a hacked firmware that misreports their capacity to the system, and fails when more than the actual capacity is written. So to find out whether a drive is fake, you have to fill it all the way and read the data back.

Matching events to stock movements doesn't work, because investors use other sources to estimate sales beforehand, and compete hard with each other to find out first. So the information was already priced in. Low sales do impact the stock, but _when_ they impact it is complicated and unintuitive.

ULA is stuck with SLS, which had its high-level design micromanaged by Congress in a way that guaranteed it will fail (at everything except collecting government funding). It makes sense that Bruno is jumping ship shortly before the reckoning comes for SLS, to a company where success is possible.

If the only GPLed component used is the Linux kernel, you probably aren't entitled to any noteworthy source code. It's well established that using the kernel doesn't create a GPL requirement userspace software running on the same device, and the most likely arrangement here is a completely-uncustomized kernel paired with an open-source userspace program that does all the interesting bits.

I'm a T1 diabetic, have worked on open source diabetes-tech (OpenAPS), and have used a number of different CGMs (though not this one specifically). This story... does not make very much sense.

CGMs (of any brand) are not, and have never been, reliable in the way that this story implies that people want them to be reliable. The physical biology of CGMs makes that sort of reliability infeasible. Where T1s are concerned, patient education has always included the need to check with fingerstick readings sometimes, and to be aware of mismatches between sensor readings and how you're feeling. If a brand of CGMs have an issue that sometimes causes false low readings, then fixing it if it's fixable is great, but that sort of thing was very much expected, and it doesn't seem reasonable to blame it for deaths. Moreover, there are two directions in which readings can be inaccurate (false low, false high) with very asymmetric risk profiles, and the report says that the errors were in the less-dangerous direction.

The FDA announcement doesn't say much about what the actual issue was, but given that it was linked to particular production batches, my bet is that it was a chemistry QC fail in one of the reagents used in the sensor wire. That's not something FOSS would be able to solve because it's not a software thing at all.

This is an AI-written summary of someone else's blog post, which it does not cite. This sentence is a giveaway: "The Asahi Linux blog post reveals the intricate complexity of implementing sample shading on AGX hardware." There are no other mentions of Asahi and no links.

The mistake you are making is letting the author choose your points of comparison, without having a high-level picture of where water usage goes. Comparing water usage to a city is misleading because cities don't use much water; large-scale water use is entirely dominated by agriculture.

I think of homebrew as a curation service; it lets me name a piece of software and install it without having to any special diligence on it. In that use case, I _want_ them to enforce code-signing requirements; that reduces the risk that some software-supply-chain compromise will spread to my computer.

I do want the ability to install unsigned software, either because I wrote/compiled it myself locally and can't be arsed with signing, or because I'm getting it from a non-public source that doesn't want to share a copy with Apple, or because it's from a developer I trust who can't be arsed. But I never want to get unsigned software _from a curation service_.

The reason this happened will probably never be revealed, but I predict it's probably because the channel was uploading videos through a VPN, and wound up sharing an IP address with someone who was using the same VPN for piracy.

The RDS proxy for our postgres DB went down.

If you're automating filling out the form, you aren't reading the instructions and you aren't checking what you're putting into it as much as you should be. And if you put in incorrect information, it tends to be considered fraud, even if it's downstream of a sloppy LLM rather than downstream of a particular fraudulent scheme.

Your example use case is automatically filling out an IRS form, operated by the sort of IRC department that makes a webform that's only up during business hours? Do you realize how legally risky that is to create, and how legally risky that will be to operate?

The captcha put you on notice that your scraping wasn't authorized. Depending on the details and circumstances, bypassing it and scraping anyways may have been a crime.

In addition to whatever other mitigations you do, you should put a deny rule for the bot's user-agent in robots.txt, and use a status code of 429 (Too Many Requests), even if the bot doesn't respect these. This will strengthen your case if you need to convince a third party (AWS, or a court, or a different part of the company that's operating the bot) that it's abusive.

There are some types of legal action that service providers can get, which both force the service provider from droppig you, and also forbid the service provider from telling you why or what has happened. Eg, this happens in banking with SARs; when they drop a client for suspected money laundering, not only can't they tell that to the client, they can't even tell their own support agents.

I don't know anything about your sites or your activities, but based on the behavior described, something like this has probably happened to you.

This article says that using `transform` is faster than using `left` and `top` because `transform` is handled on-GPU, while `left` and `top` are not. This is a myth. I tried the demo page in the Firefox profiler; neither the optimized nor the unoptimized version missed frames. I tried it in the Chrome profiler; the unoptimized version missed frames, but the time was clearly labelled by the profiler as being GPU time, not reflow. Neither browser did reflows (or, all reflows were fast enough to not have any profiler-samples associated.)

The reality is that browsers contain large piles of heuristic optimizations which defy simple explanation. You simply have to profile and experiment, every time, separately.

This rat study used an absurdly high salt concentration; no human food is anywhere close to that, and if a human did try to eat that much salt, they would die of dehydration or damage their kidneys.

But, predictably, this study will be used to generate headlines implying that salt is bad for humans, in ordinary contexts. Paste the paper title into Google News, and there they are. I believe this was likely the paper authors' intent, and that this is a high-prestige form of pseudoscience.

They already have a quota and billing framework in place for email storage. If it was about storage costs, I'd expect them to address it through that.

No it doesn't make it clear, because it's written by a third party reading the same internally-inconsistent page I am; any information added beyond the Google documentation page is conjecture.

I can't tell whether I use this; the description in the article sort-of matches a feature I use, but not exactly. The feature I use is labelled "Check mail from other accounts" and appears in the "Accounts and Import" tab in Gmail web; it causes Gmail to periodically retrieve emails from an external server using POP, and merge them into my main inbox. This article refers to the option "Check mail from other accounts", which matches, but also says "POP only works with a single device", which is false (wrt this feature) and makes me think it may be talking about something different.

I'm hearing about this for the first time from HN (not from Google). I don't like having Google randomly drop IT tasks on my plate, and the possibility that emails might just silently stop being delivered is nighmarish. Sigh.

You were tricked. If you click through the link, you will find a request that isn't about injury reporting at all.