Single party consent for recording in public (or in places a person could be reasonably expected to be recorded) is the norm everywhere I’m aware of.
A private conversation would be one where you could claim that a person is expected to read a privacy policy to people but of course that would be preempted by the recording party following actual laws governing recording and would never be expected.
Yes of course this will only rewrite some number of blocks that total the disks reported capacity. In the case that a person is worried about hidden blocks being preserved by a wear leveling algorithm they could just run the same command again and that would get em all.
That’s only true for some environments.
E: this is the first time I’ve read that blog post since it was published (or at least a long time ago) and there’s now a comment specifically referencing the actual behavior I observed in the wild when I tried to sub other things in for “normal” uses of dd:
Nobody says: 2016-12-30 at 15:17
cat /dev/cdrom > myfile.iso
Works
cat myfile.iso > /dev/cdrom
Won’t – dd allows you do handle writes in various block sizes, so if a device can’t handle a one-byte write, cat could well end up writing your byte followed by zeros (and because of where the pointer now is, do it again for the next byte).
Still, all your other points stand – nice piece.
While that comment was written seventy years ago, in this age of people with questionable intent, capability and integrity rewriting system tools in rust there’s no better time to linger thoughtfully over cp or cat or any number of other commands that begin with the letter “c” before grabbing the ol’ reliable footgun whose fifty years of script backwards compatibility ensure that no one can get their dd replacement accepted in normal use until it behaves as expected.
Secure erase just drops the ssd controllers table of where logical blocks are in the physical memory and trims the disk. Which is good and you should do.
That means a person would have to address the memory directly with flying leads or a bed of nails or something. Or have special software that makes the controller tell them what’s on each physical block and then put that data together into a bunch of files.
If that worries you, do dd if=/dev/urandom of=/dev/ before you secure erase.
Then everything on the drive will be random static before the secure erase drops the block table and trims, so even if someone uses magic power to read the block contents directly they just get to see static.
That has the benefit of speeding up the drive by resetting read fatigue at the expense of one layer of writes which is always worth it.
Please do me the kindness of again reading this in the most sincere and respectful voice:
It’s best to put your privacy and safety needs above the possible results of a tiny fraction of the money you spend going to a foreign party you dislike.
Doh and dnssec will probably be good enough till you can sock back $20 to mail to Sweden.
This is happening because you touch yourself. It’s punishment from god for the sin of onanism.
E: actually probably everyone itt is forgetting about ssd read fatigue. Rewrite every block on your ssd and the problem will go away.
Yes it is.
Make sure you also have dnssec set up.
Even with doh set up, your computer reaches out to a dns server and trusts that server is what it claims to be. There are reasons and history that explain this behavior but there are also attacks that take advantage of it. Dnssec performs cryptographic identity verification to make sure you are asking the real dns server where Pornhub.com is as opposed to some on the wire or in the cloud interlocutor that might direct you to a website that looks alike or just sends you somewhere else entirely.
Please read the following in the voice of Glenda the good witch from the wizard of oz, or SpongeBob, or some other character who is on your side and would never say something mean to hurt your feelings, because I am on your side and would never say something mean with the intention of hurting your feelings:
A person who benefits from this kind of explanation would be best served by mullvad over any other vpn because it is much harder to misconfigure mullvad in a way that undoes your privacy goals.
DNS over https. It transmits your dns requests over https encrypted using tls so that the device handling them over the wire can’t inspect them.
When you type pornhub.com into your browsers address bar your computer doesn’t fucking know what that is so it asks the dns server what it is. Because of history and reasons it asks in plaintext. So your isp can see that a dns request was placed to some dns server for pornhub.com. Your isp could also edit or intercept that request. Isp means whatever WiFi you’re connected to as well. Assuming the isp allows your dns request and the servers response through, your browser will most likely connect to pornhub using https. In that case the isp won’t be able to record that you looked up shrek slime butts sheet cake sitting videos but they will know that you visited pornhub.
Doh prevents that situation.
I don’t know how you set up doh on your system because I don’t know what you’re running or how your dns is configured. I recommend you learn how to set this up yourself and verify that it’s working correctly so you can ensure your own security.
You also need dnssec, as noted above.
Doh and dnssec are more important than a vpn.
Do those first then save up some money and get mullvad.
Debian: the worst Linux distribution, except for all the other ones.
You’re barking up the wrong tree and fucking up your life by doing this.
Split the streaming/gaming duty to a different device that can be operated in the way the user expects.
Wherever you disconnect shutdown signals from will be relied upon by something down the road and you’ll end up with a weird messed up broken update when that happens.