I've just been playing around with https://browserleaks.com/fonts . It seems no web browser provides adequate protection for this method of fingerprinting -- in both brave and librewolf the tool detects rather unique fonts that I have installed on my system, such as "IBM Plex" and "UD Digi Kyokasho" -- almost certainly a unique fingerprint. Tor browser does slightly better as it does not divulge these "weird" fonts. However, it still reveals that the google Noto fonts are installed, which is by far not universal -- on a different machine, where no Noto fonts are installed, the tool does not report them.

For extra context: I've tested under Linux with native tor browser and flatpak'd Brave and Librewolf.

What can we do to protect ourselves from this method of fingerprinting? And why are all of these privacy-focused browsers vulnerable to it? Is work being done to mitigate this?

Hi all! I recently built a cold storage server with three 1TB drives configured in RAID5 with LVM2. This is my first time working with LVM, so I'm a little bit overwhelmed by all its different commands. I have some questions:

1. How do I verify that none of the drives are failing? This is easy in case of a catastrophic drive failure (running lvchange -ay <volume group> will yell at you that it can't find a drive), but what about subtler cases?
2. Do I ever need to manually resync logical volumes? Will LVM ever "ask" me to resync logical volumes in cases other than drive failure?
3. Is there any periodic maintenance that I should do on the array, like running some sort of health check?
4. Does my setup prevent me from data rot? What happens if a random bit flips on one of the hard drives? Will LVM be able to detect and correct it? Do I need to scan manually for data rot?
5. LVM keeps yelling at me that it can't find dmeventd. From what I understand, dmeventd doesn't do anything by itself, it's just a framework for different plugins. This is a cold storage server, meaning that I will only boot it up every once in a while, so I would rather perform all maintenance manually instead of delegating it to a daemon. Is it okay to not install dmeventd?
6. Do I need to monitor SMART status manually, or does LVM do that automatically? If I have to do it manually, is there a command/script that will just tell me "yep, all good" or "nope, a drive is failing" as opposed to the somewhat overwhelming output of smartctl -a?
7. Do I need to run SMART self-tests periodically? How often? Long test or short test? Offline or online?
8. The boot drive is an SSD separate from the raid array. Does LVM keep any configuration on the boot drive that I should back up?

Just to be extra clear: I'm not using mdadm. /proc/mdstat lists no active devices. I'm using the built-in raid5 feature in lvm2. I'm running the latest version of Alpine Linux, if that makes a difference.

Anyway, any help is greatly appreciated!

How I created the array:

pvcreate /dev/sda /dev/sdb /dev/sdc
vgcreate myvg /dev/sda /dev/sdb /dev/sdc

pvresize  /dev/sda
pvresize  /dev/sdb
pvresize  /dev/sdc

lvcreate --type raid5 -L 50G -n vol1 myvg
lvcreate --type raid5 -L 300G -n vol2 myvg
lvcreate --type raid5 -l +100%FREE -n vol3 myvg

For education purposes, I also simulated a catastrophic drive failure by zeroing out one of the drives. My procedure to repair the array was as follows, which seemed to work correctly:

pvcreate /dev/sda
vgextend myvg /dev/sda
vgreduce --remove --force myvg
lvconvert --repair myvg/vol1
lvconvert --repair myvg/vol2
lvconvert --repair myvg/vol3

Fun fact: Torx screwdrivers are compatible with Torx Plus screws, but Trox Plus screwdrivers are only compatible with Torx screws that are one size larger

Context: LaTeX is a typesetting system. When compiling a document, a lot of really in-depth debugging information is printed, which can be borderline incomprehensible to anyone but LaTeX experts. It can also be a visual hindrance when looking for important information like errors.

Update

Apparently this is patched out by Brave, but it is enabled by default. See u/[email protected] 's comment below!

Vanilla chromium gives google's websites special treatment by offering detailed CPU info, among other things. This is implemented through a hidden browser extension. You can prove this by yourself by running chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {method: "cpu.getInfo"}, (response) => {console.log(JSON.stringify(response, null, 2)); }, ); on google.com through the browser console. For me, it gives the following info:

{
  "value": {
    "archName": "x86_64",
    "features": [
      "mmx",
      "sse",
      "sse2",
      "sse3",
      "ssse3",
      "sse4_1",
      "sse4_2",
      "avx"
    ],
    "modelName": "Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz",
    "numOfProcessors": 4,
    "processors": [
      {
        "usage": {
          "idle": 28238205,
          "kernel": 827581,
          "total": 32762960,
          "user": 3697174
        }
      },
      {
        "usage": {
          "idle": 1455131,
          "kernel": 743391,
          "total": 6209241,
          "user": 4010719
        }
      },
      {
        "usage": {
          "idle": 1448653,
          "kernel": 769970,
          "total": 6068506,
          "user": 3849883
        }
      },
      {
        "usage": {
          "idle": 1450274,
          "kernel": 744886,
          "total": 5948597,
          "user": 3753437
        }
      }
    ],
    "temperatures": []
  }
}

Note that this doesn't work on other websites like lemmy.world, only google.

What I am confused about is that I can replicate this behavior in Brave. Why does brave reveal this information to google, and to google only? From what I understand, it can be used for fingerprinting and tracking. Shouldn't this be patched out? Is my testing methodology flawed? Will this be fixed?

Brave version: Version 1.67.123 Chromium: 126.0.6478.126 (Official Build) unknown (64-bit) running on linux via flatpak

Context for newbies: Linux refers to network adapters (wifi cards, ethernet cards, etc.) by so called "interfaces". For the longest time, the interface names were assigned based on the type of device and the order in which the system discovered it. So, eth0, eth1, wlan0, and wwan0 are all possible interface names. This, however, can be an issue: "the order in which the system discovered it" is not deterministic, which means hardware can switch interface names across reboots. This can be a real issue for things like servers that rely on interface names staying the same.

The solution to this issue is to assign custom names based on MAC address. The MAC address is hardcoded into the network adaptor, and will not change. (There are other ways to do this as well, such as setting udev rules).

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve while making it much harder to type and remember interface names.

To disable predictable interface naming and switch back to the old scheme, add net.ifnames=0 and biosdevname=0 to your boot paramets.

The template for this meme is called "stop doing math".

Template source: https://web.archive.org/web/20210304000634/https://www.government.nl/topics/coronavirus-covid-19/visiting-the-netherlands-from-abroad/checklist

Template source: https://web.archive.org/web/20210304000634/https://www.government.nl/topics/coronavirus-covid-19/visiting-the-netherlands-from-abroad/checklist

Firefox on Debian stable is so old that websites yell at you to upgrade to a newer browser. And last time I tried installing Debian testing (or was it debian unstable?), the installer shat itself trying to make the bootloader. After I got it to boot, apt refused to work because of a missing symlink to busybox. Why on earth do they even need busybox if the base install already comes with full gnu coreutils? I remember Debian as the distro that Just Wroks(TM), when did it all go so wrong? Is anyone else here having similar issues, or am I doing something wrong?