• 0 Posts
  • 3 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle
  • I agree that the bitwarden UI isn’t very good on the desktop app and in the browser extension. I don’t even use the desktop app at all anymore. One positive for protonpass is that the ui is looking pretty streamlined and it feels fast. I think for just the endless regular internet accounts either is fine.

    It’s a fair point about small vs. big. I mean security by obscurity doesn’t really seem like a strong point for small, but who knows. I think higher value targets will always end up using the bigger ones anyway.

    Important stuff (banking/development secrets) maybe use something like gpg based and offline like https://wiki.archlinux.org/title/Pass or the Qt frontend https://qtpass.org/.


  • I’ve been using bitwarden for the past few years and I’ve been pretty happy with it. I have proton unlimited though so I figured I’d try it out.

    It looks nice but there is some functionality missing. No categories. Can’t store credit card info. Session locking only has the option to relogin with a pin code and not full password or even 2FA.

    There is still some work to be done here for sure.


  • There are many phones you can unlock/relock the bootloader on. That’s not why pixels are used. https://grapheneos.org/faq#future-devices

    "Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.

    Devices need to be meeting the standards of the project in order to be considered as potential targets. In addition to support for installing other operating systems, standard hardware-based security features like the hardware-backed keystores, verified boot, attestation and various hardware-based exploit mitigations need to be available. Devices also need to have decent integration of IOMMUs for isolating components such as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image processor, etc., because if the hardware / firmware support is missing or broken, there’s not much that the OS can do to provide an alternative. Devices with support for alternative operating systems as an afterthought will not be considered. Devices need to have proper ongoing support for their firmware and software specific to the hardware like drivers in order to provide proper full security updates too. Devices that are end-of-life and no longer receiving these updates will not be supported.

    In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.

    Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."

    I think basically the higher standard of security on pixel devices allows/makes it easier to setup verified boot so you can relock the bootloader and retain that chain of trust it provides. Rather than an leave it unlocked in something like lineageOS where there is no verified boot and therefore all software isn’t coming from a trusted (verified) source.