Can someone explain to me why this factually correct[1] comment is so heavily downvoted, as opposed to explaining how I may be mistaken?
I’m baffled to say the least.
I’m baffled to say the least.
Any suggestions on where to go next?
I also still enjoy irc, usenet, and deepnet sites (such as onion sites, etc) for the less mainstream, old school hacker vibe.
1. Are there any probable/plausible examples of such manipulation? I say this from a 100% naive standpoint - literally: I've never seen it myself, so it unfortunately does work. Not to say I doubt it exists; I've read about the concept enough times that I accept that it exists.
2. Regarding (3), do you think it would be possible to cultivate that mindset again, in a different setting/environment, or are these trends influenced by the contemporary status quo? :/
2a. If you _do_ think it might be possible, I'm very interested to absorb ideas on how to create constructive discussions online. People have had more than enough interactions with the current mainstream (twitter, facebook, reddit, here, etc) to probably have _some_ idea on how to massively improve tooling/UX/etc.
2) I do think it is possible, but it is much more difficult to gain those users back who have fled due to those issues. It would require a public shift in forum management style that openly acknowledges it's issues, which especially in a place like this would be hard because for the most part dang et al actually do a great job and the issues we are talking about are very nuanced...
2a) If you come to some conclusions on this I'd like to hear them too. Its something I think about often, and I'm yet to find some silver bullet. I tend to gravitate towards some mishmash of past techniques, for example, I really liked Slashdot mod system, where random users were given mod ability, and instead of just points, you could label something informative, funny, etc. I also think exclusivity can be a boon, so for example invite-only forums or some other exclusion method can naturally curate conversations, but on the flip side you will tend to keep otherwise good commentators silent that way. steemit's idea of monetization via crypto of good content is another approach... none of them alone seems to be enough...
One idea I've had that's technically challenging would be some sort of AI comment judge with preselected criteria, so let's say a commentor makes many logically fallacious comments, then that person gets a temp-ban.
Another has been just purely based on comment depth/length. If a user often goes in depth, a few one sentence quips would reduce their score-weight but they could still post, but another user who only does one line quips would get a temp-ban.
in short, I don't know, but whoever figures this out is going to be a big deal
MS allows its employees to comment on matters in a personal capacity with a disclaimer indicating such.
Apple employees are not supposed to comment at all, and can be terminated for doing so.
Both explicity forbid shilling, and there is no encouragement by the company to do anything like what you’re describing. This should be obvious if one considers how many lawyers they employ whose sole job it is to prevent them from being sued, charged, or investigated.
I know folks at both companies, and while everyone is unique, I noticed that many have a lot of pride in their employer, have a strong dislike for competitors, and would likely engage in expressing their disagreement voluntarily.
> UEFI let’s the FW signal to the OS upon boot “please install this driver blindly”, but it can’t force the OS.
> Only Windows obliges to this request. Linux is immune.
UEFI firmware runs before the OS and with greater privileges – e.g. it has control over System Management Mode (SMM), which is hidden from the OS. It can force the OS to do whatever it wants. For example, it can modify system files on disk, which should be enough to compromise most Linux installations. If that isn't possible (because something verifies the files), it could, e.g., patch the next stage bootloader it loads (which could be GRUB or the kernel itself via EFISTUB), in memory before executing it. Or, as an easier approach, it could just add a SMI handler that patches the kernel later on.
It is true that Windows 8 and later exposes a way for UEFI to "ask it nicely" to load a given driver, without having to patch anything, namely the WPBT (Windows Platform Binary Table). As you note, this is the mechanism Lenovo used to persist Superfish. The reason it exists, however, is for anti-theft software such as Computrace/LoJack. Earlier versions of Computrace took a "brute force" route to installing its persistence driver, patching system files on disk, and there wasn't really anything Microsoft could do to stop it. So instead they decided to give them a sanctioned route to accomplish the same thing, which at least is less likely to break something in the process.
However, at least according to the white paper, the LoJax UEFI rootkit does not use WPBT at all. Instead it uses an approach that seems to be inspired by older (pre-WPBT) versions of Computrace. [1] Specifically, it drops a binary "autoche.exe" into the filesystem, then modifies the registry to execute autoche.exe on boot instead of the normal autochk.exe (note that the last letter is different).
Thus, WPBT is irrelevant in this case. The malware hijacks Windows by modifying its filesystem, and if the authors cared enough to target Linux, they could hijack most Linux installations the same way (and all installations with a somewhat more difficult approach). But then, even if some piece of malware did decide to use WPBT when targeting Windows, it could still use the more elaborate methods to target Linux. At most, WPBT makes it slightly easier for UEFI malware to target Windows than it would otherwise be. But it really doesn't make much difference.
[1] To clarify: As the white paper describes, a later stage of the bootstrap, rpcnetp.exe, is actually copied from an older version of Computrace and merely patched to change the C&C server address. However, the UEFI part of the malware is custom, and merely uses a similar (but slightly different) overall approach. Computrace's own UEFI driver worked by actually modifying autochk.exe, whereas the malware modifies the registry to execute a different filename instead.