Talk:End-user Computer Security/Preliminaries

Free software & other free computer resources
Since emphasis is made on inexpensive security in this book, should there be a section or other information, dedicated to free software, and other free or low-cost computing resources?

--MarkJFernandes (discuss • contribs) 11:52, 16 April 2020 (UTC) 

Add a section called "Computer-driven event logging"?
Logs can be used to uncover hacking attempts whether they were successful or not, and can point a user in the right direction for where extra security may be needed in their systems.

Trammell Hudson briefly deals with whether computers should be completely shutdown, or suspended, in relation to security (see https://trmm.net/Heads_FAQ#suspend_vs_shutdown.3F). This comparison can be extended to whether computers should be powered-on, or powered-off, in relation to security. It may well be better for a computer to be powered-on as in such a state, it can be more difficult to carry out certain classes of attack. In conjunction with a computer being powered-on, computer-driven event logging can be activated, to provide even more security.

--MarkJFernandes (discuss • contribs) 13:54, 16 April 2020 (UTC)

Change section title "Psychic spying of password" → "Spying by mind-reading"?
Perhaps it would be a good idea to broaden the scope of this section by renaming it so that it is for the broader topic of mind-reading. MarkJFernandes (discuss • contribs) 17:31, 8 May 2020 (UTC)

Add section entitled "File-based security" somewhere?
Such a section would deal with the issues of malware in files, digital signing of files, secure communication of files, the backup of files, and probably a few other "file-based security" related issues. Section could be placed in the "Chapter  10:	Miscellaneous notes" chapter, but then again, it might be better to turn this section into a chapter in its own right. Doesn't seem appropriate to place the section in any of the other chapters. MarkJFernandes (discuss • contribs) 09:13, 16 May 2020 (UTC)

Index not complete as of 3rd June 2020
Realised that index would take quite a long time to complete, so decided to leave it in an unfinished state on the book page of this talk page (the Preliminaries page). Might ask for crowd-funding to fund its completion.

PS/2 keyboards are more secure than USB keyboards
According to Micah Lee in the Qubes OS video hosted here (go to 29m:47s), using USB instead of PS/2 for plugging in your keyboard, is something of a security risk. This has already been mentioned in passing in the §"Pros vs Cons" under the section dealing with whether Raspberry Pi Zero devices should be used as secure downloaders. But it should probably also be documented as standalone info in the book, perhaps in the "Miscellaneous notes" chapter.

Sources of computer-security information that perhaps provide further content for book, whether through direct inclusion or by indirect hyperlinking
The following sources were suggested by the Qubes-user "Catacombs":
 * https://riseup.net/en/security
 * https://www.schneier.com

Dealing with the situation where you want to work with potentially security-compromised equipment/software
Dealing with such situations is related to the "What to do when you discover your computer has been hacked" chapter.

Dealing with such situations is related to the note linked-to here entitled 'additions for "Sandboxing and cloud computing" section'. With that note in mind, old second-hand potentially-compromised smartphones and cameras might be able to be used simply for the purpose of capturing photos in order to send them to an on-site local printer for printing. Once printing completes, visual inspection of the print-outs might then be able to identify adequately whether the print-outs were sufficiently correct (you could perhaps compare print-outs to what was photographed, simply using your own vision, in order to ascertain accuracy), thus perhaps overcoming the potential security weaknesses of such potentially compromised technology.

Sand-boxing and cloud computing also work to contain the ill-effects of malware (possibly hidden within software), so that your other system components don't get damaged. This is touched upon in the §⟪Sandboxing and cloud computing⟫.

Personally, I am contemplating whether it might be possible to use the potentially compromised BIOS/UEFI firmware of my laptop. The COVID-19 situation doesn't help such potentially compromised circumstances.

I have wondered whether my laptop without Wi-Fi and Bluetooth capabilities, as a consequence of removing the Wi-Fi+Bluetooth card, is perhaps fairly secure so long as it is not networked, not connected to other computers/devices, and doesn't have malware on any of its disks or other connected media, even if there should be malware and/or backdoors in the firmware (including the BIOS/UEFI firmware) and/or the hardware. Such malware and/or backdoors, are perhaps not capable of facilitating the deceptive altering of natural-language texts without the aid of outside interventions (interventions such as those through wireless communication), because of the byte-size limitations of such security compromises. The amount of code you can fit in the BIOS/UEFI firmware is limited; such limitation seems to be a security principle for reducing malware potential (it might be worth documenting such principle elsewhere in the book, perhaps in the Digital Storage chapter). Such limitation is exploited in the security invention mentioned in the "Design feature for enabling the detection of malware in BIOS firmware" on the talk page of the "New security inventions requiring a non-trivial investment in new technology" chapter. However, it may still be possible for such malware in the firmware, to insert random snippets of back-door code in executable files. In light of such, if transferring executable files off the computer (such as perhaps as the result of a software-development project), it might be a good idea to run antivirus scans on such executable files. I suppose it could even be possible for such malware to insert random snippets of back-door code into source code. In such regard, it may be a good idea to run some checks on the code as present on a safe and trusted computer, after the code is copied to such computer. If such code then needs to be compiled, the user wouldn't compile it on the main computer, but somehow the copied-over code that had been checked (not the code on the main computer which could still be compromised due to malware) would be compiled on a safe system; cloud computing could perhaps be used.

In the situation where your main computing device may be compromised to some extent, getting your internet connection through an intermediate device acting as a kind of security buffer (like a canal lock or decompression chamber), might be a good idea. Such is dealt with at least in part, in the note linked-to here entitled 'Having intermediate device for internet connection might be more secure?'.

Cryptography can be leveraged to enable the safe use of potentially unsafe devices. Essentially, what happens is that the unsafe device only ever works on encrypted data, and is unable to decrypt that data. Such leveraging is perhaps used in the OS-level encryption of external SD cards in smartphones. SD cards in general are particularly worrying from a security perspective for a variety of reasons. However, if malware and/or malevolent hardware is contained on a compromised SD card, it likely can still be used safely if: i) it is only used for storing encrypted data; ii) it is impossible for any "maltech" on it to be able to get the decryption keys or the decrypted data; iii) and the keys aren't otherwise compromised. This can perhaps be partly implemented by only decrypting data on the SD card in the following way: 1) use a Nitrokey product for cryptographic services; 2) copy encrypted data off the SD card to RAM; 3) physically disconnect the SD card before finally decrypting the copy of the encrypted data, that is stored in the RAM. When reconnecting the SD card, there shouldn't be any decrypted data accessible by any "maltech" in the SD card. It should be noted that historically encrypted data can be hidden on SD cards, so if old cryptography keys become compromised, this could pose a risk to flash memory dating from when the old keys were in use, even if you elected to deep low-level format such media. Please consult the "Digital Storage" chapter for more about the risks of using SD cards.