• 4 Posts
  • 81 Comments
Joined 3 months ago
cake
Cake day: April 2nd, 2025

help-circle


  • who@feddit.orgtoPrivacy@lemmy.mlGrapheneOS vs LineageOS vs iodéOS
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    3 days ago
    1. I don’t know, but according to this page, it seems there is some kind of profile support. I assume it’s part of the Android Open Source Project.
    2. (Good thing I noticed that you edited your comment to insert this question.) I am not aware of an effective Google Play sandbox from any OS other than GrapheneOS. It doesn’t affect me either way, since I don’t use Google services.
    3. Storage encryption is built in to Android these days. I don’t remember whether the latest version does it with file-based encryption or full-device encryption. (Both have been used in the past.)
    4. It depends on who your adversary is. For example, a Google employee or a government might have remote access to a back door planted in a Pixel, but not to your boot loader. On the other hand, a TSA employee might be able to pwn your phone if granted physical access, but unable to do anything remotely. Pixels are generally more resistant to to physical access attacks because they allow user-supplied keys and boot loader re-locking, but there are companies that sell tools aiming to bypass even these protections, so I wouldn’t bet my life on them.

  • who@feddit.orgtoPrivacy@lemmy.mlGrapheneOS vs LineageOS vs iodéOS
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    2
    ·
    edit-2
    3 days ago

    GrapheneOS is better in principle, but it requires that you (directly or indirectly) give money to Google and depend on Google-controlled hardware, both of which are dealbreakers for some people.

    GrapheneOS also depends on hardware support files from Google, which are no longer readily available, making its future unclear.

    LineageOS supports a greater variety of devices. The privacy/hardening features aren’t as strong as GrapheneOS, but many people find it good enough when:

    • Google Play Services are not installed
    • Commercial apps are not installed (open-source apps from F-Droid are the usual alternative)
    • There is little risk of an adversary gaining physical access to the phone




  • who@feddit.orgtoPrivacy@lemmy.mlWhat is the catch with Epic Games' free games?
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    11 days ago

    Trying to discredit people because of the forum on which they discussed a topic, or because you view them as beneath your skill level, is a more than a little misguided, and frankly, disingenuous.

    Epic themselves have admitted to copying Steam data and scanning running processes, as has been documented in various news articles. (example, example)

    In any case, the point is not one particular incident or report, but rather that they have the capability, grant themselves permission to use it via their policy documents, and have earned distrust among a lot of gamers. Posting condescending emoji here doesn’t change that.

    Edit: P.S. In future comments defending Epic, you might do readers the courtesy of stating up front that you are moderator of an Epic Games forum.




  • who@feddit.orgtoPrivacy@lemmy.mlWhat is the catch with Epic Games' free games?
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    12 days ago

    You could download and play the games on a machine that is never used for any other purpose, but it would still be able to collect biometric data (mouse movement, keystroke patterns, voice if you have a microphone, etc.) and probe/fingerprint your network.

    Short of a dedicated machine, the closest you’re likely to get is a hypervisor-based virtual machine. Of course, that won’t safeguard your biometrics or (in most cases) your network, either.

    Such a machine would be safer if you never gave it network access, so it couldn’t exfiltrate any data that it had collected, but downloading games requires network access at some point, and it would only take milliseconds for a “helper” process (perhaps quietly installed or launched with the game) to leak the data.

    In general, hostile code will always be unsafe. If it concerns you, it’s best to avoid it entirely.






  • who@feddit.orgtoPrivacy@lemmy.mlBrowsers are complicit in browser fingerprinting.
    link
    fedilink
    English
    arrow-up
    25
    arrow-down
    1
    ·
    edit-2
    13 days ago

    Let’s be careful how we phrase things here. JavaScript form submission and navigation are choices, not needs.

    Also, progressive enhancement / graceful degradation exists. When competent developers (or bosses) want script effects on our sites, we can include them and make the sites continue to function with scripts disabled. It might require more work, but it is absolutely possible.

    Framing the script-based approaches to these things as if they were needs contributes to the problem, IMHO.

    (I am referring to the vast majority of web sites, of course, not special-purpose web applications like games.)


  • who@feddit.orgtoPrivacy@lemmy.mlBrowsers are complicit in browser fingerprinting.
    link
    fedilink
    English
    arrow-up
    78
    arrow-down
    4
    ·
    edit-2
    14 days ago

    Web developers are complicit in browser fingerprinting, by insisting that sites require JavaScript (or WASM).

    All of us are complicit in browser fingerprinting, because we tolerate this script dependence.

    IMHO, a web site being allowed to execute arbitrary code on visitors’ hardware should be an anomaly. The vast majority of them could be built to deliver the same information without requiring that inherently dangerous permission.



  • As Lemmy is federated but not fully decentralised, continuation of communities hosted on a dead instance is not currently possible. (Compare this to Matrix, where a room can carry on even if its original homeserver dies, so long as at least one other homeserver participates in it.)

    So that is indeed still a problem here, although not as severe, because I think the posts in those communities will still be available on instances that participated in them. Such communities would be forever frozen, though; carrying on from where they left off would require migrating to (or creating) communities on still-running instances.

    Lemmy does allow you to export your own data and import it into another instance. That includes settings, subscriptions, and links to saved posts/comments. So I guess maybe you could save your own posts, export your data, and import it elsewhere to keep links to what you wrote on the dying instance. I have not tested this to be sure.