Recent submissions

Comment · 1 month ago
It's needed in general-purpose models because there are billions of persons who can use these models to develop (personally or organizationally) valuable software, and all of these persons deserve the ability to test their software against the best exploit-development resources that exist.

The so-called "safeguards" preventing this, on balance, probably do more harm than good. The best argument in favor of these safeguards is perhaps the temporary one: today, there is simply too much deployed critical software that was developed in a more carefree age. Therefore, one might favor a tradeoff: try to introduce artificial friction against exploit development targeting old software (during the process of patching all of it), with the side effect that new software ends up less resilient than it could have been.

But in the steady state (which may be a very small number of years from now), every practical capability for exploit development should be a routine part of the software creation and maintenance lifecycle.

Comment · 2 months ago
Love this! Think you haven't pushed CONTRIBUTING.md yet? Anyways, is there data around what met the bar for patterns.py? Like, five instances in different projects got a patterns.py rule, anything less than that usually dropped?
Comment · 4 months ago
With more advance notice, someone could have found resources to fork curl with different vulnerability management expectations, e.g., "will not accept or otherwise handle any vulnerability reports during the month beginning 21 December 2026. We call it The Winter of Our Discontent."
Comment · 6 months ago
For many events, the demographics lean toward age groups where people have jobs with work schedules that aren't known more than a few weeks in advance. The initially planned friend group (e.g., four people) can have little overlap with who is actually free on the event date and actually attends. Also, if the event has assigned seating, people buying their own tickets typically has the adverse outcome that you can't sit together.
Comment · 1 year ago
feature request: AI-based risk analysis, with a model of which types of commercial vehicles at that location are likely to be controlled by organized crime
Comment · 1 year ago
To disambiguate, the person on the plane could learn to use hand signals (e.g., Cued Speech) and the AI model can be trained on that.
Comment · 2 years ago
Comment · 2 years ago
It is discuused here: https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-De... - the HPN-SSH maintainer says "I do have an issue with [the OpenSSH 9.6] release in that it breaks interaction with HPN-SSH. The client seems to be window limited to 2MB sending regardless of what is being advertised by the receiver."
Comment · 2 years ago
for "Thats exactly what we will be doing initially! Our tablets taste much better than Bite!" I might go with the brand "habitablets" and the tagline "where self-care meets planet-care"

the idea is that "habitablets" are a type of "tablets" that (when widely adopted to reduce packaging waste and shipping waste) will ultimately make our planet more "habitable"

Comment · 3 years ago
Suppose you have office space in the jail, and give him (or anyone else) the opportunity to apply for remote jobs at anyplace willing to hire him - with the caveat that he loses office access unless he demonstrates that he's maximizing his potential to earn money, all of which will go directly to compensating victims. (Assume that he can't have Zoom calls with arbitrary colleagues of his choice. He can only have Zoom calls with Bill Lumbergh.)
Comment · 3 years ago
Comment · 3 years ago
What data is stored about an employee's justification for viewing a customer account? Is there an enumerated set of justifications such as "direct customer inquiry" versus "to be used for upselling other banking products" versus "IT debugging" etc. or is it free-form text? Is the justification process more complex if the bank knows that the customer is a public figure, celebrity, or maybe anyone who meets Wikipedia'a notability requirements?
Comment · 3 years ago
Years ago, many decisions to hide error details were a cargo cult reaction to CVE-2012-4929. To review, CVE-2012-4929 works like this:

1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com

2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message

3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser

4. example.com compresses response data before encrypting it

5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data

6. after enough requests, the attacker knows the authentication data to login to example.com as the victim

One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.)

There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.

Comment · 3 years ago
Possibly because the firmware could be modified, and not print the required yellow dots or other tracking data:

https://www.eff.org/pages/list-printers-which-do-or-do-not-d...

"Some of the documents that we previously received through FOIA suggested that all major manufacturers of color laser printers entered a secret agreement with governments to ensure that the output of those printers is forensically traceable."

Comment · 3 years ago
If I were evaluating this, my top four concerns would be:

1. "NoSQL document database with MongoDB-like queries ... powered by the open source database engine RocksDB" doesn't give me enough confidence that my application will work. Some limitations are unstated. For example:

(easy question) MongoDB documents are limited to 16 MB. Facebook's RocksDB Overview says "There is no limit to the size of a key or a value." Your insertOne documentation doesn't state a limit. Is it 16 MB?

(harder question) Your getMany documentation doesn't describe its interaction with the RocksDB "snapshot" concept (one of the big advantages of RocksDB over other NoSQL products). Facebook's Iterator documentation says "If ReadOptions.snapshot is given, the iterator will return data as of the snapshot. If it is nullptr, the iterator will read from an implicit snapshot as of the time the iterator is created. ... be aware that in case an iterator getting stale, it can block resource from being released. So make sure you destroy or refresh them if they are not used after some time, e.g. one second." Does this imply that each call to getMany operates on a unique snapshot? If so, do you plan to add an API in which the user can specify that multiple getMany calls must operate on the same snapshot?

2. The name of a space (e.g., "dev") is part of the URL used by clients. Is this avoidable? It can interfere with migration of applications to codehooks from other platforms.

3. Your story about unanticipated use (or abuse) seems to be 'We've got you covered by creating a price "ceiling", which reduces the price with 90%.' That's good but I would probably also need billing alerts. I would probably also want request rate limits similar to AWS WAF (e.g., 100 requests per IP address in a 5-minute period) without writing my own auth hooks.

4. I didn't find a discussion of runtime secrets (e.g., something like "flyctl secrets").

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton