cypherpunks

joined 3 years ago
MODERATOR OF
[–] [email protected] 27 points 1 week ago

because this is firmly in poe's law territory, i searched for "pibmow" which returned a wikipedia article for something called "pribnow box" which i figured was a set top streaming appliance, from which (until clicking it) i briefly inferred that everything in this post was real.

[–] [email protected] 9 points 1 week ago* (last edited 1 week ago)

Teknolust (2002)

CW: y2k aesthetic, Tilda Swinton in multiple roles.

Do not read wikipedia's synopsis of it first unless you want to spoil it. you can find it here on archive.org.

[–] [email protected] 6 points 1 week ago (3 children)

The English translation of ‘stukkie wukkie’ would surely be the train is ‘stuck’?

Google translates "stukkie wukkie" as "piece of shit" or "wonky", depending on other nearby words, and "stukkie" as "broken". but neither of these words is in a dutch dictionary afaict. And google doesn't translate anything i tried to those words.

I’m not a Dane though so could be wrong.

Dutch is the language (and demonym) of the Netherlands.

Dane is the demonym for people from Denmark, where they speak the Danish language.

[–] [email protected] 27 points 1 week ago* (last edited 1 week ago) (16 children)

this is obviously a joke but it contains more dutch than people unfamiliar with the language might guess.

here is google's translation of a verbatim transcription of the image:

oopsie woopsie! the train is a piece of shit!

we are working really hard to make this maybe you can fwietsen better owo

Here are a few other variations with even better translations

Maybe a Dutch speaker will comment here and tell us how many of the words in the image are actual Dutch words? I suspect google is probably providing plausible translations for some that aren't really.

[–] [email protected] 0 points 1 week ago

it's not a particularly long post; if you're really confident in the veracity of the narrative you're familiar with then you shouldn't need to be afraid to read something that contradicts it.

(and btw, neither of the two posts i linked claims nothing happened there.)

[–] [email protected] 7 points 2 weeks ago

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" 😂

[–] [email protected] 11 points 2 weeks ago (6 children)

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.

[–] [email protected] 2 points 2 weeks ago

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.

6
ELIZA effect (en.wikipedia.org)
 

obligatory xkcd#37 link

 
view more: ‹ prev next ›