• 1 Post
  • 27 Comments
Joined 8 months ago
cake
Cake day: March 6th, 2024

help-circle
  • Here’s the actual paper of the technology (Prio) that it’s based on.

    Some problems stand out:

    • It requires that the organisations (Mozilla and ISRG) not collude to decrypt the secret share (probably reasonable)
    • The paper suggests registering end users to protect against Sybil attacks.
    • The scheme requires the organisations to correctly withhold results from advertisers until there are sufficient results.

    I’m not overly familiar with the tech stack but I’d be concerned about browsers using a persistent UUID to send impressions to Mozilla’s API.

    The biggest elephant in the room is that seemingly nobody wants the damn thing. It offers nothing to users, except maybe a good feeling inside that they’re supporting AdTech. It offers AdTech less than the current deal where they can collect obscene amounts of personal information for targeted advertising.


  • PSA: if your financial institution/government/<other website> is using SMS codes (aka PSTN MFA) for multi-factor authentication they are practically worthless against a determined attacker who can use SIM swap or an SS7 attack to obtain the code. Basically you are secured by a single factor, your password. If your password is compromised it may be sold via black hat marketplaces and purchased by an attacker who would then likely attempt to break that second factor.

    The best way to protect yourself is to use a unique password; a password manager especially helps with this. Sometimes institutions will offer “Authenticator” (TOTP) as a second factor, or PassKey authentication, both secure alternatives to SMS codes.

    Here in Aus I’m working with Electronic Frontiers Australia to try and force some change within government and financial institutions (via the financial regulator). Most banks here use SMS codes and occasionally offer a proprietary app. One of the well-known international banks, ING Bank, even uses a 4 pin code to login to their online banking portal. 😖

    Unfortunately SMS codes are a legacy left from old technology and a lack of understanding or resourcing by organisations that implement it. Authenticator/TOTP tokens have been around for 16 years (and standardised for 13 years), and PassKeys are relatively newer. There is a learning curve but at the very least every organisation should at least provide either TOTP or PassKeys as an option for security-minded users.



  • That’s probably a fair point. I can’t say too much as I haven’t touched Windows desktop or server too much.

    Could be apples vs oranges here though as we’re talking about getting started versus well established setup, but my current employer is looking at adopting Ansible + Packer for imaging and partially Ansible-managing Windows servers where it makes sense because of limitations in SCCM and GPO. As far as I can see across the divide Windows Server isn’t all smooth sailing.


  • I can’t say I’ve managed Linux desktops at scale (so technically I should leave it there) but I do manage several hundred Linux VMs with Ansible, and I manage all of my PCs with Ansible. Desktops are a different ballgame to servers, dealing with end users and all, but I still don’t think it would be that hard once it’s been set up.


  • That sucks :( I’m pretty much in the same boat. I get to use a Linux desktop at work on the proviso that I don’t raise support requests. We use Microsoft for nearly everything so naturally it’s an uphill battle. The web UI is quite buggy and “not recommended” by my org. Teams doesn’t support Firefox so I have to run a separate browser especially for it.

    But aside from interfacing with Microsoft everything just works, and really nicely.









  • The biggest issue I’ve had with I2P so far has been lack of content.

    postman.i2p only permits torrents which includes its tracker in the torrent file, which means popular torrents from 1337x, TPB et al can’t be uploaded there (at least not without changing the infohash). Torrent clients like qBittorrent and BiglyBT can cross-seed on I2P and clearnet networks which is a recent development since libtorrent 2.0 came out (software packages take a while to bump to.the latest library), but from what I’ve tested nearly all of the infohashes I put into my client from “clearnet” torrent sites have stalled, probably because I2P is a little too bespoke at the moment.

    The potential is definitely there IMO, but unless you’re just watching mainstream movies and TV it’s not a replacement for clearnet/VPN.

    If I’m missing something I’d like to know :)


  • You can absolutely download apps from F-Droid on GrapheneOS, what makes you think you can’t, and how did you conclude that LineageOS is more private and secure?

    I never said that GrapheneOS couldn’t download apps from F-Droid. I didn’t mention GrapheneOS being able to use F-Droid in my dot points but that was just an oversight, not intenttional.

    GrapheneOS doesn’t ship with any Google services by default. We do provide an easy and safe way to install the Google Play components if desired, they are run under the same sandbox and constraints as any other ordinary app you install.

    The problem with this is that so many apps use Google Play Services. If I didn’t want a phone that used Google, I wouldn’t use an OS that bent backwards to make it work.

    The sandbox model is OK in theory, except when your bank app asks for permissions for microphone, camera, contacts and files, and refuses to start without them.

    The app model is a bit broken IMO and GrapheneOS both enables and perpetuates it.

    LineageOS is pretty commonly behind on updates. As an example, it seems that LineageOS 21 (based on Android 14 QPR1) came out in February of this year. You cannot ship the full security patches without being on the latest version of Android, which is Android 14 QPR3 now.

    I might be being a bit naïve here, but Android 14 came out in October, 4 months prior to LOS 21, which is not particularly long. Android 13 is still supported by upstream. This sounds a bit like running RHEL or Debian vs bleeding edge Arch, no? It’s a common debate whether RHEL systems are constantly out of date, the counterargument being that vulnerabilities are often found in new software versions. Without real statistics about security vulnerabilities over time it’s difficult to make an informed decision about software version policies.

    LineageOS does make connections to Google by default, as does AOSP. GrapheneOS changes those connections while LineageOS doesn’t.

    That is excellent, I’m glad to hear GrapheneOS is changing some of the defaults to be a bit better.


  • Lineage is kinda bad privacy and security wise, from the little I know its not fully degoogled

    My understanding is kinda the opposite:

    • GrapheneOS ships with a sandboxed, FOSS Google Play Services which can optionally do a bunch of Google things (use their APIs, login to Google etc.) plus they have some hosted services that can substitute Google services (like geolocation).
    • LineageOS basically doesn’t ship with any Google Play style API/frameworks at all. It’s a pure AOSP experience. Any apps on F-Droid work but third party apps (like ones found on Google Play) are hit and miss. If you can just use F-Droid for all of your apps then LineageOS is probably a much more private and secure offering.
    • LineageOS for microG is an unofficial fork of LineageOS which includes a FOSS Google Play Services compatibility layer, a bit like GrapheneOS. As far as I know it doesn’t have the same level of sandboxing as Sandboxed Google Play on GrapheneOS.

    Both GrapheneOS and LineageOS publish monthly updates with upstream security patches for all supported devices.

    Both GrapheneOS use network-provided DNS by default.

    Apparently both GrapheneOS and LineageOS connect to connectivitytest.gstatic.com via http as a Captive Portal test by default,althoughh this was as of 2019-2020 and both might have changed since then.


  • Something that often gets missed is the difference between packaging conventions between distros.

    For example, Debian has Apache httpd packaged as “apache2” and has wrapper scripts for enabling sites. Fedora/RHEL has “httpd” and includes conf.d from the main conf. Arch also has “httpd” but doesn’t have a conf.d out of the box. Of course you can pretty much configue Apache to your heart’s content and have an identical setup between all three distros.

    From what I’ve read, Debian tends to patch and change software to fit more into their overall system whereas Fedora and Arch tend to be more upstream.

    RPM and Arch both have group packages and metapackages. Debian just has metapackages AFAIK. Debian also has “recommended” and “suggested” levels of soft dependencies, the former which is enabled by default. RPM has the capability for weak dependencies but AFAIK most RPM distros don’t use it. Arch doesn’t have soft/weak dependencies AFAIK.

    When you install a new system daemon on Debian, it’s generally enabled and started by default, whereas RPM-based and Arch don’t do that.

    When I think of the base of the system I tend to think of some of those more subtle idiosyncrasies that tend to spread around the ecosystems, like Ubuntu and Debian behave quite similarly for instance.



  • Bash scripts will only get you so far and I can wholly recommend Ansible for automation.

    Basically the main advantage of Ansible is that its builtin tasks are “idempotent” which means you can re-run them and end up with the same result. Of course it is possible to do the same with bash scripts, but you may require more checks in place.

    The other advantage of Ansible is that there are hundreds of modules for configuring a lot of different things on your system(s) and most are clear and easy to understand.