nightpool

This is about the gemspec (e.g. the project or package file, like pyproject.toml or package.json) for each dependency. The lock file is in a custom plain text format to make it easy for both humans and bundler to understand

Really interesting post, but this part from the beginning stuck out to me:

   Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about dependency information, which is actually the normal way of getting dependency info (again, no eval required).

It would be interesting to compare and contrast the parsing speed for a large representative set of Python dependencies compared to a large representative set of Ruby dependencies. YAML is famously not the most efficient format to parse. We might have been better than `pip`, but I would be surprised if there isn't any room left on the table to parse dependency information in a more efficient format (JSON, protobufs, whatever).

That said, the points at the end about not needing to parse gemspecs to install "most" dependencies would make this pretty moot (if the information is already returned from the gemserver)

In some companies, this type of information is often very important and very easily available to everyone at all levels of the business to help prioritize and understand customer value. I would not consider it "sensitive" in the same way that e.g. PII would be.

> Fediverse itself doesnt know how to handle direct messages

What do you mean by this? Direct messages are not end-to-end encrypted, I don't know what you mean by "doesn't know how to handle". Almost every platform with direct messages doesn't have E2E today, that's the same as email, twitter, Discord... basically every other messaging platform on the web besides Signal and Matrix, for better or worse.

There is no way to access your DMs except using Bluesky's centralized backend server.

A lot of work can be wrapped inside a database transaction, but never everything. You're always going to want to interact with external APIs eventually.

These are clearly AI generated, not sure what you mean by "adding" to it.

Although I'm not actually sure how much the watchdog is "warning" here, despite the article claiming it is. The language from the report is the following:

    6.18. In each of these cases the motive of the app developer/ lobbyist/

journalist may be more sinister than first appears, so permitting an officer to examine whether the individual is a witting or unwitting agent of a foreign state might be described as necessary in the right circumstances. Serious responsibility is placed on police to use the power wisely.

The report doesn't make any recommendations or suggest any changes to the law, it seems to consider that it is good that this could be considered Section 3 "hostile activity". This later part about Schedule 3 investigations also makes this clear:

    The Joint Committee on Human Rights was of the view that there was an even greater risk of arbitrary use of Schedule 3 than of Schedule 7, owing to the broader and more ambiguous definition of “hostile activity” (than of terrorism). I would develop the point further:

    • For Schedule 7, the examining officer must at least have in mind the possibility that the examined person is morally blameworthy. That arises from the statutory question: whether the individual is a person “…is or has been concerned in the commission, preparation or instigation of acts of terrorism”
    
    • By contrast, under Schedule 3 a lawful examination may take place, with all the intrusion and inconvenience attached, of an individual for whom the question of moral fault does not arise at all. 

    6.22. Having said this, I am not yet able to draw any practical conclusions from this conceptual distinction. Firstly, most examinations are likely to be directed at the issue of witting or witting participation, which incidentally puts a premium on human as well as digital interrogation. Secondly, the possibility that an examinee is in fact entirely innocent also arises under Schedule 7. I will therefore keep under review whether this needs to be reflected in the Code of Practice, but make no recommendation at this stage.

"Creating apps like Signal could be considered 'hostile activities' under new Counter-Terrorism and National Security Acts, UK watchdog warns"

The language changes here are slight (claims -> warns) and includes more context about the reason this watchdog is speaking out (current debates around the Counter-Terrorism and Border Security Act, new implementation of the National Security Act), using language from the first 4 paragraphs (may be considered, could be considered, stark warning, report warns, etc).

You could also leave out the specific names of the acts—they're not super helpful to me as a non-UK news consumer, but I suspect they might be more crucial to someone who's tapped into the UK political news cycle:

"Creating apps like Signal could be considered 'hostile activities' under new laws, UK watchdog warns"

I see what you're saying, but IMO the actual vulnerability there is that Clickhouse (by default?) was exposed fully unauthenticated and without any header requirement. Allowing completely unauthenticated access to Clickhouse, even read-only, means that they're just asking for issues like this.

In another comment, a Posthog security engineer mentions that this was resolved previously for their cloud-hosted product: https://news.ycombinator.com/item?id=46307696

The author already had basically full Clickhouse querying abilities, and Clickhouse lets you run arbitrary SQL on postgres, the fact that the author used a read-only command to execute it wasn't the author bypassing a security boundary (anyone with access to the Clickhouse DB also had access to the Postgres DB), it was just a gadget that made the SSRF more convenient. They could have escalated it into a different internal HTTP API instead.

It looks like the entire class of bugs here are "if you have access to Posthog's admin dashboard, you can configure webhook URLs that hit Posthog's internal services". That's not particularly surprising for a self-hosted system like the author's, but I expect it would pretty bad if you were using their cloud-hosted product.

I don't understand this. Can you help explain it with a more practical example? Say that N1 (the root service) is a GraphQL API layer or something. And then N2 and N3 are different services feeding different parts of that API—using Linear as my example, say we have a different service for ticket management and one for AI agent management (e.g. Copilot integration). These are clearly different services with different responsibilities / scaling needs / etc.

And then N4 is a shared utility service that's responsible for e.g. performance tracing or logging or something similar. To make the dependency "harder", we could consider that it's a shared service responsible for authentication and authorization. So it's clear why many root services are dependent on it—they need to make individual authorization decisions.

How would you refactor this to remove an undirected dependency loop?

They link multiple sources, including a Sunshine Foundation report summarizing other research into the area, and a NewsGuard report where they tested claims from the Pravda network directly against leading LLM chatbots: https://static1.squarespace.com/static/6612cbdfd9a9ce56ef931... https://www.newsguardtech.com/special-reports/generative-ai-...

They weren't on any cloud provider previously. They famously had their own "metal cloud" of managed servers with everything being containerized and managed by Kubernetes. It seemed like it's worked pretty well, especially for their complex git operation tasks which had specific hardware requirements, but the official word is that apparently they're running into scaling limits with finding new datacenter capacity.

No, you're the one that's incorrect, typescript blocks mutations when you use Object.freeze too: "Cannot assign to 'immutable' because it is a read-only property. (2540)"

You can also use "as const" to get the same behavior without any runtime calls:

    const exploring = { immutable: true } as const
    exploring.immutable = false
              ^ Cannot assign to 'immutable' because it is a read-only property.(2540)

But yes, OP wasn't referring to the article, they were just pointing out the narrower fact that Typescript does in fact have compile-time errors for mutating Object.freeze's return values.

Apparently someone worked on it, but (IMO) the visualization is a lot less nice compared to the original: https://madnight.github.io/githut/#/pull_requests/2024/1

Interesting to see the number of JS pushes go down significantly, but actually realize that it's just because many more projects are using TypeScript:

https://i.imgur.com/AJBE9so.png

Yes, 100%. Lots of failures across the board here. Especially with large ships and how many different nations they might be registered in, I can't imagine it's easy to have a lot of regulatory oversight into their construction, mechanical inspection or maintenance schedules. I'm curious how modern ports handle this problem, feels like it could cause a ton of issues beyond just catastrophic ones like this one.

No, there was a larger failure: whoever designed the control system such that a single loose wire on a single terminal block (!) could take down the entire steering system for a 91,000 ton ship.

Unfortunately, because these types of preferences (font size, dark/light mode theme) are "non-essential", you are required to inform users about them using a cookie banner, per EU ePrivacy directive (the one that predates the GDPR). So if you don't use a cookie banner in this case, you are not in compliance.

Yes. I don't think you should have to show a popup to track the user's language preferences, whether they want a header toggled on or off, or other such harmless preferences. Yet, the EU ePrivacy directive (separately from the GDPR) really does require popups to inform users of these "cookies".

I really, really think there are better lessons there. Maybe more like "Lesson 0. Don't put distributed clusters in control of your light switches"

> given how many other companies have "created browsers" that are just Chromium forks and rubbed Google the wrong way

Has there been any indication that these folks are "rubbing Google the wrong way"? I think Chromium, as a project, is actually very happy that more people are using their engine.

Thank you dang!

Gah! Sorry, complete slip of the fingers. No offense to Cloudflare intended!

GP is saying that they were already one of Coinbase's vendors (they did the networking/IT setup for Coinbase's office). Whether you'd tolerate that kind of behavior from a vendor is one thing, but for an existing vendor relationship I think adding a few billable hours for "I found this issue in your network and documented and reported it for you" to an existing contract is not particularly unreasonable.

You mentioned that the DKIM headers "passed validation for coinbase.com". How could that have been possible, if the email was a phishing email? I'm not sure I understood that part, especially because you didn't provide any examples of the header data you received from the attacker.

It would be cool to also AI generate the favicon using some sort of image model.