Skip Navigation
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)UN
Posts
0
Comments
159
Joined
10 mo. ago
  • Some of those countrymen are conscripts. 2/3rds? Which makes continuation of battle far less justifiable IMO.

    Some people will choose to fight in Ukraine, to possibly die in Ukraine. Conscripts face punishment for refusal.

    How many of those fighting would refuse the peace deal?

  • High memory usage isn't a problem by itself.

    The issue is when it's used inefficiently or for useless purposes. An unoptimized application takes 500MB of extra memory and that is 500MB that cannot be used for read/write caching nor another application, and 500MB closer to an OOM situation.

    In theory, an application can suffer from issues of underutilization of memory, just as one that over-utilizes memory. In practice, I find that lower-than-expected memory use is a much more positive indicator of an optimization-focused project than one that uses more memory than expected.

    In the meantime, it's not sitting there, unused and useless.

    If your system uses caching, then "usused" memory may not be so. Memory used for caching is also cleanly "Available" for use if needed. This is not the case with the 500MB of extra memory a process might decide to capture. Of course this is complicated further with swap (I wouldn't use it).

  • Overreaction is the only tool that works to stop enshittification before it starts.

    Overreacting can undermine your cause. I don't see how reacting accordingly cannot "stop enshittification before it starts".

  • Do you lock your door at night? Why? Anyone could just use a fireman's axe and open it. Or they could just drive through your living room and steal everything.

    For kernel-level anti-cheats its quite simple. Those in opposition to kernel-level anti-cheats likely view locking a door as a small task with minimal downsides, which could reasonably deter an opportunistic criminal, or buy you time to escape with your life or call the police.

    They also likely view kernel-level anti-cheats as, for the benefits they provide, having too large of downsides. (providing a third-party company kernel-level access via a closed-source program)

    If you're concerned about privacy just dual boot windows in a separate SSD to play games and use Linux and Graphene OS.

    In another thread in this comment section I mention UEFI rootkits and firmware implants (kernel-level access is strong starting point for this). Your solutions do not address these issues, which could be important to someone. (Depending on their threat-model)

  • If you tell me that all I need to do to negate the security concern of the kernel level anticheat is to run the dualboot windows partition...

    ...it makes intuitive sense that installing a kernel level anticheat would only affect the windows kernel it was installed on not the linux kernel on the other drive partition.

    The intuition is incorrect as the kernel-level anticheats are not necessarily trusted. Operating systems interact with low-level hardware and firmware on the system. As such, it is not self-contained.

    https://www.kaspersky.com/about/press-releases/more-elusive-and-more-persistent-the-third-known-firmware-bootkit-shows-major-advancement

    There exists both UEFI bootkits and firmware implants. Its intuitive if you understand it like this: if there exists a communication pathway from (A) lower-privilege code -> (B) higher-privilege code, there exists the potential for vulnerabilities.

    This is due to (A) now having an effect on the code execution for (B).

  • So, I'm not allowed to ask you for proof of your statement? And if its unrelated, then why did you post it? Its unrelated. Also, you're saying you have an absence of evidence, ergo you have no evidence. Having no evidence does not qualify as evidence

    Asking for evidence wasn't the issue, believing that the truth relies solely upon a discussion providing such evidence is.

    I think you are confusing having an option with something being mandatory.

    You misunderstood. Some of your own statements say it matters and is used. Mandatory wasn't mentioned nor implied.

    And Tor nodes are not the same thing as VPN multi-hop.

    I just realized you think that Tor is built using multi-hop.

    I didn't state they were the same. Tor uses "multiple hops" (you can find that string the the link I posted earlier). It is critical to the limiting of information seen by any single entity.

    And again, if you connected your Firefox browser to Tor, we could still track you. You'd get cookied or localStorage() tracked. When you disconnect from Tor, that stuff is still present in your browser. Almost like the number of hops you take or the IP address used doesn't seem to really matter, huh?

    All that state can be removed. And the server might not be tracking that. Situations vary, adversaries vary. If you cannot imagine a scenario in which hops or IP address would matter, I would suggest doing some research.

    Its a real life Dunning-Kruger effect! I've never encountered this. You are going to do something really stupid and end up in prison.

    Personal swipes mark the end of this discussion. I would suggest you to leave those out next time as It detracts focus from constructive learning.

    This will be my last reply. You can also reply if you want (but I won't see it).

  • Evidence, or it isn't true.

    Unrelated, but absence of evidence is not evidence of absence.

    Anyways, your own statement:

    Adtech relies on the OpenRTB 2.5/2.6 spec for tracking, you would have removed 1 identifier out of a hundred (one that isn't really used anyway given SSAI is so popular).

    Removing an identifier that is used. (1/100 = matters, "isn't really used" != unused). This contradicts your other statements:

    Yeah, multi-hop is pointless for tracking.

    ...IP addresses and multi-hop don't matter...

    Broad statements that don't take into consideration the threat model of other users. Servers you connect to might not be using source IP in any way to track. You might be leaking so many other identifiers, that its completely useless to worry about multi-hop. But this is not true for everyone in every situation.

    If its worth anything to you, the Tor Project seems to think multi-hop and IP addresses matter.