22
submitted 3 days ago by [email protected] to c/[email protected]
9
submitted 3 days ago by [email protected] to c/[email protected]
[-] [email protected] 8 points 4 days 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" 😂

41
submitted 5 days ago by [email protected] to c/[email protected]
5
submitted 5 days ago by [email protected] to c/[email protected]
[-] [email protected] 11 points 6 days ago

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 6 days 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.

[-] [email protected] 7 points 6 days ago

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.

99
submitted 1 week ago by [email protected] to c/[email protected]

sourcei saw the photo on bluesky attributed to "seen on insta".

i searched and found a text version here on reddit from 2018.

22
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
119
pragmatic (lemmy.ml)
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
33
submitted 2 weeks ago by [email protected] to c/[email protected]
6
ELIZA effect (en.wikipedia.org)
submitted 2 weeks ago by [email protected] to c/[email protected]
77
submitted 2 weeks ago by [email protected] to c/[email protected]

obligatory xkcd#37 link

65
post-Hogg (lemmy.ml)
submitted 2 weeks ago by [email protected] to c/[email protected]
22
submitted 2 weeks ago by [email protected] to c/[email protected]
[-] [email protected] 192 points 2 months ago* (last edited 2 months ago)

No, SVG files are not HTML.

~~Please change this post title (currently "today i learned: svg files are literally just html code"), to avoid spreading this incorrect factoid!~~

~~I suggest you change it to "today i learned: svg files are just text in an html-like language" or something like that.~~ edit: thanks OP

SVG is a dialect of XML.

XML and HTML have many similarities, because they both are descendants of SGML. But, as others have noted in this thread, HTML is also not XML. (Except for when it's XHTML...)

Like HTML, SVG also can use CSS, and, in some environments (eg, in browsers, but not in Inkscape) also JavaScript. But, the styles you can specify with CSS in SVG are quite different than those you can specify with CSS in HTML.

Lastly, you can embed SVG in HTML and it will work in (modern) browsers. You cannot embed HTML in SVG, however.

[-] [email protected] 128 points 1 year ago

shoutout to the person who reported this post with "Reason: Bot meme, you can't even read it. whoever replies is a bot too" 😂

[-] [email protected] 175 points 1 year ago* (last edited 1 year ago)
[-] [email protected] 126 points 2 years ago

PSA: nobody should keep more money on paypal than they can afford to lose

[-] [email protected] 140 points 2 years ago

the famous "This incident will be reported" error was briefly removed last year before being replaced with a less ominous version.

[-] [email protected] 124 points 2 years ago* (last edited 2 years ago)

I'm disappointed in arstechnica for only supporting their provocative headline (Judge in US v. Google trial didn’t know if Firefox is a browser or search engine) with this vagueness in the article:

While Cavanaugh delivered his opening statement, Mehta even appeared briefly confused by some of the references to today's tech, unable to keep straight if Mozilla was a browser or a search engine. He also appeared unclear about how SEM works and struggled to understand the options for Microsoft to promote Bing ads outside of Google's SEM tools.

What did he actually say?!

view more: next ›

cypherpunks

0 post score
0 comment score
joined 3 years ago
MODERATOR OF