incredible self-own from ArduPilot co-creator Jason Short:

Not in a million years would I have predicted this outcome. I just wanted to make flying robots.

🤡

(of course, in reality, many people were discussing weaponization even on the day diydrones was announced…)

you wouldn’t need any AI to fake a video that “proves that Epstein was the only person who came in or out of his cell on the night he died” 😂

Due to the Norwegian language conflict there have been various competing forms of written Norwegian over time, two of which have been officially recognized as equally valid by the Norwegian parliament since 1885. Both apparently changed their spelling of “slut” to “sludd” in the 21st century, Bokmål in 2005 and Nynorsk in 2012, presumably in an effort to encourage English speakers to make jokes about Swedes and Danes instead of them.

TLDR: this is way more broken than I initially realized

To clarify a few things:

-No JavaScript is sent after the file metadata is submitted

So, when i wrote “downloaders send the filename to the server prior to the server sending them the javascript” in my first comment, I hadn’t looked closely enough - I had just uploaded a file and saw that the download link included the filename in the query part of the URL (the part between the ? and the #). This is the first thing that a user sends when downloading, before the server serves the javascript, so, the server clearly can decide to serve malicious javascript or not based on the filename (as well as the user’s IP).

However, looking again now, I see it is actually much worse - you are sending the password in the URL query too! So, there is no need to ever serve malicious javascript because currently the password is always being sent to the server.

As I said before, the way other similar sites do this is by including the key in the URL fragment which is not sent to the server (unless the javascript decides to send it). I stopped reading when I saw the filename was sent to the server and didn’t realize you were actually including the password as a query parameter too!

😱

The rest of this reply was written when I was under the mistaken assumption that the user needed to type in the password.

That’s a fundamental limitation of browser-delivered JavaScript, and I fully acknowledge it.

Do you acknowledge it anywhere other than in your reply to me here?

This post encouraging people to rely on your service says “That means even I, the creator, can’t decrypt or access the files.” To acknowledge the limitations of browser-based e2ee I think you would actually need to say something like “That means even I, the creator, can’t decrypt or access the files (unless I serve a modified version of the code to some users sometimes, which I technically could very easily do and it is extremely unlikely that it would ever be detected because there is no mechanism in browsers to ensure that the javascript people are running is always the same code that auditors could/would ever audit).”

The text on your website also does not acknowledge the flawed paradigm in any way.

This page says "Even if someone compromised the server, they’d find only encrypted files with no keys attached — which makes the data unreadable and meaningless to attackers. To acknowledge the problem here this sentence would need to say approximately the same as what I posted above, except replacing “unless I serve” with “unless the person who compromised it serves”. That page goes on to say that “Journalists and whistleblowers sharing sensitive information securely” are among the people who this service is intended for.

The server still being able to serve malicious JS is a valid and well-known concern.

Do you think it is actually well understood by most people who would consider relying on the confidentiality provided by your service?

Again, I’m sorry to be discouraging here, but: I think you should drastically re-frame what you’re offering to inform people that it is best-effort and the confidentiality provided is not actually something to be relied upon alone. The front page currently says it offers “End-to-end encryption for complete security”. If someone wants/needs to encrypt files so that a website operator cannot see the contents, then doing so using software ephemerally delivered from that same website is not sufficient: they should encrypt the file first using a non-web-based tool.

update: actually you should take the site down, at least until you make it stop sending the key to the server.

also “you may not remove or obscure any functionality in the software related to payment to the Licensor in any copy you distribute to others.” 🤡

FUTO’s license meets neither the free software definition nor the open source definition.

Btw, DeadDrop was the original name of Aaron Swartz’ software which later became SecureDrop.

it’s zero-knowledge encryption. That means even I, the creator, can’t decrypt or access the files.

I’m sorry to say… this is not quite true. You (or your web host, or a MITM adversary in possession of certificate authority key) can replace the source code at any time - and can do so on a per-user basis, targeting specific IP addresses - to make it exfiltrate the secret key from the uploader or downloader.

Anyone can audit the code you’ve published, but it is very difficult to be sure that the code one has audited is the same as the code that is being run each time one is using someone else’s website.

This website has a rather harsh description of the problem: https://www.devever.net/~hl/webcrypto … which concludes that all web-based cryptography like this is fundamentally snake oil.

Aside from the entire paradigm of doing end-to-end encryption using javascript that is re-delivered by a webserver at each use being fundamentally flawed, there are a few other problems with your design:

• allowing users to choose a password and using it as the key means that most users’ keys can be easily brute-forced. (Since users need to copy+paste a URL anyway, it would make more sense to require them to transmit a high-entropy key along with it.)
• the filenames are visible to the server
• downloaders send the filename to the server prior to the server sending them the javascript which prompts for the password and decrypts the file. this means you have the ability to target maliciously modified versions of the javascript not only by IP but also by filename.

There are many similar browser-based things which still have the problem of being browser-based but which do not have these three problems: they store the file under a random identifier (or a hash of the ciphertext), and include a high-entropy key in the “fragment” part of the URL (the part after the # symbol) which is by default not sent to the server but is readable by the javascript. (Note that the javascript still can send the fragment to the server, however… it’s just that by default the browser does not.)

I hope this assessment is not too discouraging, and I wish you well on your programming journey!

This is a very misleading headline and blog post.

Copy-pasting my comment from another thread:

Here is an excerpt of the CNBC article about this lawsuit:

On Dec. 3 — a day before Thompson was fatally shot — the company issued guidance that included net earnings of $28.15 to $28.65 per share and adjusted net earnings of $29.50 to $30.00 per share, the suit notes. And on January 16, the company announced that it was sticking with its old forecast.

The investors described this as “materially false and misleading,” pointing to the immense public scrutiny the company and the broader health insurance industry experienced in the wake of Thompson’s killing.

The group, which is seeking unspecified damages, argued that the public backlash prevented the company from pursuing “the aggressive, anti-consumer tactics that it would need to achieve” its earnings goals.

“As such, the Company was deliberately reckless in doubling down on its previously issued guidance,” the suit reads.

The company eventually revised its 2025 outlook on April 17, citing a needed shift in corporate strategy — a move that caused its stock to drop more than 22% that day.

The linked Medium post’s headline is not entirely false but its framing is sensationalist clickbait and misleads the reader: “BlackRock is Suing UnitedHealth for Giving “Too Much Care” to Patients After the CEO was Murdered” gives the incorrect impression that this lawsuit is demanding UnitedHealth go back to providing less care, but in fact the lawsuit appears to condemn their “anti-consumer tactics” while seeking damages from their “materially false and misleading” statement to investors in January.

The Medium article also lists only BlackRock as the plaintiff, when in fact it is a class action suit which presumably will include many far more sympathetic class members such as pension funds etc.

Which part of it is fake?

Here is an excerpt of the CNBC article about it:

On Dec. 3 — a day before Thompson was fatally shot — the company issued guidance that included net earnings of $28.15 to $28.65 per share and adjusted net earnings of $29.50 to $30.00 per share, the suit notes. And on January 16, the company announced that it was sticking with its old forecast.

The investors described this as “materially false and misleading,” pointing to the immense public scrutiny the company and the broader health insurance industry experienced in the wake of Thompson’s killing.

The group, which is seeking unspecified damages, argued that the public backlash prevented the company from pursuing “the aggressive, anti-consumer tactics that it would need to achieve” its earnings goals.

“As such, the Company was deliberately reckless in doubling down on its previously issued guidance,” the suit reads.

The company eventually revised its 2025 outlook on April 17, citing a needed shift in corporate strategy — a move that caused its stock to drop more than 22% that day.

The Medium post’s headline is not entirely false but its framing is sensationalist clickbait and misleads the reader: “BlackRock is Suing UnitedHealth for Giving “Too Much Care” to Patients After the CEO was Murdered” gives the incorrect impression that this lawsuit is demanding UnitedHealth go back to providing less care, but in fact the lawsuit appears to condemn their “anti-consumer tactics” while seeking damages from their “materially false and misleading” statement to investors in January.

The Medium article also lists only BlackRock as the plaintiff, when in fact it is a class action suit which presumably will include many far more sympathetic class members such as pension funds etc.

i’m not a chess expert but i think one of the pieces is at the wrong angle?

i wondered, who is this person who is so out of touch that she thinks that is a reasonable price, and… she is a former member of congress from orange county who is currently campaigning to be governor of california 🤡

see also

a bit of context:

• I Still Know What You Visited Last Summer

• https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_selectors/Privacy_and_the_visited_selector

• https://www.theregister.com/2025/04/07/chrome_135_history_sniffing/

it’s giving Zoë Roth

OP, did you find this article due to the likely-originated-from-soda-jerk-lingo term 86 being in the news today or is that just a coincidence? 😂

this guy knuths how units work

they do

When it’s libre software, we’re not banned from fixing it.

Signal is a company and a network service and a protocol and some libre software.

Anyone can modify the client software (though you can’t actually distribute modified versions via Apple’s iOS App Store, for reasons explained below) but if a 3rd party actually “fixed” the problems I’ve been talking about here then it really wouldn’t make any sense to call that Signal anymore because it would be a different (and incompatible) protocol.

Only Signal (the company) can approve of changes to Signal (the protocol and service).