cultural reviewer and dabbler in stylistic premonitions

  • 26 Posts
  • 167 Comments
Joined 4 years ago
cake
Cake day: January 17th, 2022

help-circle


  • machine translation of a paragraph of the original article:

    The police’s solution: It’s none other than a Trojan. Unable to break the encryption, they infect the traffickers’ phones with malware, subject to judicial authorization. This way, they gain full access to the device: apps, images, documents, and conversations. Obviously, GrapheneOS isn’t capable of protecting itself (like any Android) against this malware.

    original text in Castilian

    La solución de la policía. Esa no es otra que un troyano. Ante la imposibilidad de romper el cifrado, infectan los teléfonos de los traficantes con software malicioso, previa autorización judicial. De esta manera, consiguen acceso total al dispositivo: apps, imágenes, documentos y conversaciones. Evidentemente, GrapheneOS no es capaz de protegerse (como cualquier Android) ante este malware.

    🤔




  • this is an advertorial with a dishonest/misleading clickbait headline.

    of course google has trackers on lots of websites… that is not news, nor does it have anything to do with which non-gooogle search engine one might use to find a website.

    this particular google analytics competitor may or may not be more privacy friendly than others but the fact that they are advertising their product with this kind of garbage does not inspire confidence.












  • Arthur Besse@lemmy.mltoPrivacy@lemmy.mlI made a gpg Hat
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    1 month ago

    were you careful to be sure to get the parts that have the key’s name and email address?

    It should be if there is chunks missing its unusable. At least thats my thinking, since gpg is usually a binary and ascii armor makes it human readable. As long as a person cannot guess the blacked out parts, there shouldnt be any data.

    you are mistaken. A PGP key is a binary structure which includes the metadata. PGP’s “ascii-armor” means base64-encoding that binary structure (and putting the BEGIN and END header lines around it). One can decode fragments of a base64-encoded string without having the whole thing. To confirm this, you can use a tool like xxd (or hexdump) - try pasting half of your ascii-armored key in to base64 -d | xxd (and hit enter and ctrl-D to terminate the input) and you will see the binary structure as hex and ascii - including the key metadata. i think either half will do, as PGP keys typically have their metadata in there at least twice.




  • Arthur Besse@lemmy.mltoLefty Memes@lemmy.dbzer0.comno-state solution
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    1 month ago

    someone reported this comment with the report reason “Anti-AI Trolling in an AI friendly community”

    What makes this an AI-friendly community? I just read the sidebar and don’t see anything about AI.

    I do see however that this community’s list of rules includes this peculiar pair:

    • Only post socialist memes
    • Don’t idolize/glorify previous and current socialist experiments or (leading) individuals.

    🤔




  • 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.