frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Biomni: A General-Purpose Biomedical AI Agent

https://github.com/snap-stanford/Biomni
55•GavCo•2h ago•12 comments

Tree Borrows

https://plf.inf.ethz.ch/research/pldi25-tree-borrows.html
345•zdw•6h ago•49 comments

Show HN: FlopperZiro – A DIY open-source Flipper Zero clone

https://github.com/lraton/FlopperZiro
114•iraton•3h ago•29 comments

Jank Programming Language

https://jank-lang.org/
130•akkad33•3d ago•21 comments

A fast 3D collision detection algorithm

https://cairno.substack.com/p/improvements-to-the-separating-axis
142•OlympicMarmoto•7h ago•20 comments

Desktop Publishing Tools That Didn't Make It (2022)

https://tedium.co/2022/10/12/forgotten-desktop-publishing-tools-history/
33•rbanffy•3h ago•19 comments

Configuring Split Horizon DNS with Pi-Hole and Tailscale

https://www.bentasker.co.uk/posts/blog/general/configuring-pihole-to-serve-different-records-to-different-clients.html
38•gm678•4h ago•8 comments

Nuclear Waste Reprocessing Gains Momentum in the U.S.

https://spectrum.ieee.org/nuclear-waste-reprocessing-transmutation
60•rbanffy•5h ago•24 comments

Evolution Mail Users Easily Trackable

https://www.grepular.com/Evolution_Mail_Users_Easily_Trackable
80•mike-cardwell•3h ago•44 comments

Archaeologists unveil 3,500-year-old city in Peru

https://www.bbc.co.uk/news/articles/c07dmx38kyeo
87•neversaydie•2d ago•22 comments

Google fails to dismiss wiretapping claims on SJ, settles with app users

24•1vuio0pswjnm7•2h ago•1 comments

Ruby 3.4 frozen string literals: What Rails developers need to know

https://www.prateekcodes.dev/ruby-34-frozen-string-literals-rails-upgrade-guide/
183•thomas_witt•3d ago•89 comments

Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

https://medium.com/@gabiteodoru/why-llms-cant-write-q-kdb-writing-code-right-to-left-ea6df68af443
164•gabiteodoru•1d ago•107 comments

US Court nullifies FTC requirement for click-to-cancel

https://arstechnica.com/tech-policy/2025/07/us-court-cancels-ftc-rule-that-would-have-made-canceling-subscriptions-easier/
516•gausswho•22h ago•479 comments

The most otherworldly, mysterious forms of lightning on Earth

https://www.nationalgeographic.com/science/article/lightning-sprites-transient-luminous-events-thunderstorms
26•Anon84•3d ago•7 comments

I Ported SAP to a 1976 CPU. It Wasn't That Slow

https://github.com/oisee/zvdb-z80/blob/master/ZVDB-Z80-ABAP.md
113•weinzierl•2d ago•48 comments

Most RESTful APIs aren't really RESTful

https://florian-kraemer.net//software-architecture/2025/07/07/Most-RESTful-APIs-are-not-really-RESTful.html
257•BerislavLopac•14h ago•408 comments

Let Kids Be Loud

https://www.afterbabel.com/p/let-kids-be-loud
80•trevin•2h ago•86 comments

Bootstrapping a side project into a profitable seven-figure business

https://projectionlab.com/blog/we-reached-1m-arr-with-zero-funding
758•jonkuipers•1d ago•201 comments

Phrase origin: Why do we "call" functions?

https://quuxplusone.github.io/blog/2025/04/04/etymology-of-call/
218•todsacerdoti•17h ago•154 comments

7-Zip for Windows can now use more than 64 CPU threads for compression

https://www.7-zip.org/history.txt
236•doener•2d ago•159 comments

TaIrTe₄ photodetectors show promise for sensitive room-temperature THz sensing

https://phys.org/news/2025-07-tairte-photodetectors-highly-sensitive-room.html
11•wglb•3d ago•6 comments

Helm local code execution via a malicious chart

https://github.com/helm/helm/security/advisories/GHSA-557j-xg8c-q2mm
153•irke882•15h ago•73 comments

RapidRAW: A non-destructive and GPU-accelerated RAW image editor

https://github.com/CyberTimon/RapidRAW
241•l8rlump•18h ago•102 comments

The Architecture Behind Lovable and Bolt

https://www.beam.cloud/blog/agentic-apps
46•Mernit•5h ago•20 comments

QRS: Epsilon Wrangling

https://www.tbray.org/ongoing/When/202x/2025/07/07/Epsilon-Wrangling
6•zdw•36m ago•0 comments

A Emoji Reverse Polish Notation Calculator Written in COBOL

https://github.com/ghuntley/cobol-emoji-rpn-calculator
28•ghuntley•3d ago•5 comments

Is the doc bot docs, or not?

https://www.robinsloan.com/lab/what-are-we-even-doing-here/
182•tobr•13h ago•106 comments

X Chief Says She Is Leaving the Social Media Platform

https://www.nytimes.com/2025/07/09/technology/linda-yaccarino-x-steps-down.html
297•donohoe•6h ago•429 comments

ESIM Security

https://security-explorations.com/esim-security.html
119•todsacerdoti•12h ago•44 comments
Open in hackernews

Jurisdiction Is Nearly Irrelevant to the Security of Encrypted Messaging Apps

https://soatok.blog/2025/07/09/jurisdiction-is-nearly-irrelevant-to-the-security-of-encrypted-messaging-apps/
22•zdw•7h ago

Comments

mcherm•3h ago
I think this is missing one important issue: what if your encryption is highly reliable but the cypher test is hosted in a jurisdiction that has laws requiring the disclosure of the plaintext (perhaps with a court order or a "National Security Letter") and the ability to compel the system owners to obey.
some_furry•3h ago
> what if your encryption is highly reliable but the cypher test is hosted in a jurisdiction that has laws requiring the disclosure of the plaintext (perhaps with a court order or a "National Security Letter") and the ability to compel the system owners to obey.

This is a contradiction. If you have such a capability, then your encryption isn't sufficiently reliable. If it is sufficiently reliable, then this law cannot take effect.

If, for example, Australia wanted to compel me to backdoor something for their investigative purposes, there's nothing they can do. I live in America.

If I hosted ciphertext in Australia, the most they can hope is to terminate the service in their country. This is an availability concern, but the failure mode isn't "the government sees your nudes".

> (perhaps with a court order or a "National Security Letter")

National Security Letters don't do what you think they do. There are widespread misconceptions about their allowed scope, but they only allow the government to request "subscriber information" from a service provider. That doesn't include "we compel you to backdoor your app, and here's an automatic gag order". If they try to use non-NSL measures to accomplish this compulsion, talk to a lawyer not a cryptographer.

adrian_b•3h ago
The previous poster has not referred to a backdoor, but to the fact that in certain places, including USA, law enforcement can request from you the decryption key, and if you do not comply they can throw you in jail for an indefinite time, until you comply.

In my opinion, as someone who has been born and raised in a country occupied by external invaders, who had installed there a fake communist "democracy" and fake justice, the most fundamental human right is the right to refuse to answer to a question, regardless who asks the question.

If in a country such a refuse is sufficient for severe punishments, without the need of any other proof that the one refusing to answer has done anything wrong, then, regardless if such a refuse to answer is labeled "obstruction of justice", "contempt of court" or whatever, in that country any claims that human rights were respected are false.

It is a shame for the United Nations that this most important human right is not included in their declaration.

In order to be able to oppose an abusive government, the right to refuse to answer a question is much more important than the right to possess weapons (which will always be inferior to those of law enforcement and military, so they are not a solution).

some_furry•3h ago
The blog post makes it clear that, if the service operator ever even has access to the secret keys to surrender it in the first place, it doesn't qualify as "properly implemented cryptography". See: The Mud Puddle test.

The only way they would be able to acquire the key would be to push a backdoored update to the app. Reproducible builds (which implies open source to be meaningful) and binary transparency make that incompatible with gag orders, by design.

mananaysiempre•3h ago
> But What If The Host Country [...] Legally Compels the App Store to Ship Malware?

> This is an endemic risk to smartphones, but binary transparency makes this detectable.

> That said, at minimum, the developer should control their own signing keys.

So, don’t ship on the Play Store unless you’re grandfathered?

> If the developers for an app do not live in a liberal democracy with a robust legal system, they probably cannot tell their government, “No,” if they’re instructed to backdoor the app and cut a release (stealth be damned).

Or when the laws of said democracy make it illegal for them to say “no” (see: Australia, possibly the US per Lavabit, realistically every country in Europe if the government is willing to claim a grave enough threat per the German hoster of Jabber.ru attempting a MITM against them).

tabbott•3h ago
I think this is a dangerous view. As we've seen with the libxz attack, skilled developers are very capable of hiding backdoors/vulnerabilities in security software, even when it is open source. So it's very important whether the developers building the software are trustworthy.

Authoritarian jurisdictions with a modus operandi of compelling their businesses and citizens by force are thus much riskier than Western democracies, even flawed ones. I at least expect it's a lot harder to say no to demands to break your promises that come with credible threats of torturing your family.

I'll also say that it's quite hard to make a messaging app without the servers that run the service having a great deal of power in the protocol. Many types of flaws or bugs in a client or protocol go from "theoretical problem" to "major issue" in the presence of a malicious server.

So if end-to-end security is a goal, you must pay attention to not only the protocol/algorithms and client codebase. The software publisher's risks are important (E.g., Zoom has a lot of risk from a China-centric development team). As are those of the hosting provider (if different from the publisher).

And also less obvious risks, like the mobile OS, mobile keyboard app, or AI assistant that are processing your communications even though they're sent between clients with E2EE.

Reflections on Trusting Trust is still a great read for folks curious about these issues.

some_furry•2h ago
> I think this is a dangerous view.

I think you misinterpreted the most important nuance in this post. The rest of your comment is about jurisdiction in the context of who develops the client software.

The blog post is talking about jurisdiction in the context of where ciphertext is stored, and only calls that mostly irrelevant. The outro even acknowledges that when jurisdiction does matter at all, it's about the security of the software running on the end machine. (The topic at hand is end to end encryption, after all!)

So, no, this isn't a dangerous view. I don't think we even disagree at all.

tabbott•1h ago
I think we agree here that the US/Europe jurisdiction difference is relatively minor compared to questions about the software itself.

What's dangerous is the framing; many E2EE messengers give the server a LOT more power than "just stores the ciphertext". https://news.ycombinator.com/item?id=33259937 is discussion of a relevant example that's gotten a lot of attention, with Matrix giving the server control over "who is in a group", which can be the whole ball game for end-to-end security.

And that's not even getting into the power of side channel information available to the server. Timing and other side channel attacks can be powerful.

Standard security practice is defense in depth, because real-world systems always have bugs and flaws, and cryptographic algorithms have a history of being eventually broken. Control over the server and access to ciphertext are definitely capabilities that, in practice, can often be combined with vulnerabilities to break secure systems.

If the people who develop the software are different from those who host the server, that's almost certainly software you can self-host. Why not mention self-hosting in the article?

If you're shopping for a third party to host a self-hostable E2EE messenger for you. The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant. I can't agree with that claim.

some_furry•43m ago
> What's dangerous is the framing; many E2EE messengers give the server a LOT more power than "just stores the ciphertext". https://news.ycombinator.com/item?id=33259937 is discussion of a relevant example that's gotten a lot of attention, with Matrix giving the server control over "who is in a group", which can be the whole ball game for end-to-end security.

I'm a vocal critic of Matrix, and I would not consider it a private messenger like Signal.

https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...

When Matrix pretends to be a Signal alternative, the fact that the server had control over group membership makes their claim patently stupid.

> And that's not even getting into the power of side channel information available to the server. Timing and other side channel attacks can be powerful.

A lot of my blog discusses timing attacks and side-channel cryptanalysis. :)

> If the people who develop the software are different from those who host the server, that's almost certainly software you can self-host. Why not mention self-hosting in the article?

Because all of the self-hosting solutions (i.e., Matrix) have, historically, had worse cryptography than the siloed solutions (i.e., Signal, WhatsApp) to the point that I wholesale discount Matrix, OMEMO, etc. as secure messaging solutions.

> If you're shopping for a third party to host a self-hostable E2EE messenger for you. The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant. I can't agree with that claim.

It's more of an architecture question.

Is a self-hosted Matrix server that accepts and stores plaintext, but is hosted in Switzerland, a better way to chat privately than Signal? What if your threat model is "the US government"? My answer is a resounding, "No. You should fucking use Signal."

thadt•15m ago
> The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant.

In point of argument, it should not be relevant - beyond metadata exposure or failure to provide service. Metadata exposure is mentioned in the post, and is a rather important aspect to consider. Having service turned off when you need it also might be an important consideration depending on the threat model. If I were cabinet members planning military operations, it is quite likely that I would care about both of those.

Beyond that, the 2025 table stakes for a 'secure' messaging service are: "a totally compromised server should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages." [1]

[1] https://www.rfc-editor.org/rfc/rfc9750.html#name-delivery-se...