[–] 19 points 4 days ago

Yeah, it's taken me a similar time to migrate away from Gmail and I'm not keen to repeat the process. But if this is what Proton's code quality control is going to be like going forward - employees forced to push improperly-tested code because of their unhinged CEO - I'm going to have to go through the whole process again. Sigh.

  • source
  • parent
  • context
  • [–] 3 points 1 week ago

    I wonder if you could fake it by naming it something that sounds like an unmanned diagnostic simulation instead... Visitors not familiar with the maintenance routines of starship holodecks might be fooled by it.

    (And as we've seen, cybersecurity in the 24th Century leaves a lot to be desired, so spoofing a diagnostic is probably still possible)

  • source
  • parent
  • context
  • [–] 41 points 2 weeks ago (1 child)

    Not a particularly well-written article. The referenced Ars Technica article actually explains the problem:

    Muse has allowed users to share searches, conversations, images, and similar content with other people. Such share features usually involve clicking an option to create a unique URL that anyone can use to load a page hosting the content. To keep potentially sensitive information from being accessible to unintended people, the URLs typically contain a long sequence of text that can’t be easily guessed.

    ... a central design decision for constructing URLs has made the links easy to discover. As a result, researchers from security firm Claroc said they were able to enumerate 6,800 links Muse users created for sharing conversations with others. After opening a few hundred of them, the researchers found information that was clearly not intended to be publicly available.

    Claroc researchers were able to discover the Muse share links because all of them use the domain name cf.metaaiusercontent.com. Discovery is further made easy by the decision to add the conversation name to the URL, along with a long string of text... It’s this last design decision, putting the conversation title in the subdomain rather than in the URL path, that makes public discovery possible.

    https://arstechnica.com/security/2026/10/meta-muse-exposes-users-personal-and-business-secrets-when-they-share-conversations/

  • source
  • [–] 41 points 2 weeks ago (1 child)

    You see, comms networks have nice, straightforward protocols for interaction. There's defined handshakes, everyone's clear on who the message is for and what's the actual content versus just the packaging (headers, etc.).

    Human to human communication? Now that's a complicated mess. Can't always tell what the actual message is, there's multiple carrier types (body language, voice, etc.) and it's really bad at handling packets from multiple senders over short periods!

  • source
  • [–] 15 points 2 weeks ago (1 child)

    It's really a lot of trial and error to find a toothbrush and toothpaste that you can tolerate. I recently had to swap toothbrushes because the product I had been using for years was redesigned, and the new version was difficult for me to use. Likewise with toothpaste I had to go through a few options before I found one I was happy with.

    And brushing with water is better than not at all! 👍️

    As for how clean the bristles are, make sure you toothbrush can dry out properly after brushing. I always rinse mine before and after, and monitor for any mould at the base of the bristles. Generally it's recommended to replace your toothbrush every 3 months regardless of its condition.

  • source
  •  

    Note: this refers to a small portion of autism cases that are not due to inherited genetic factors. I find it rather ironic (after decades of misinformation on the subject thanks to Wakefield) that the conclusion of this research is that vaccines can prevent autism in specific cases!

     

    Hi all,

    I'm looking at exposing some self-hosted web-based services externally so that some relatives can access them and would appreciate some advice.

    Vikunja is the starting point (mostly to facilitate my spouse and I using it when away from home) but in future I want to set up Immich or similar to replace Google Photos, and that in particular will need to be shared with friends and family (especially so that immediate family can have camera uploads on automatically).

    I understand that ideally I'd use SSH, a VPN, or tailscale or similar (although I don't have experience with tailscale), but that's not going to be feasible. Most of the family will not be able to set up those connections themselves (which means I would need to) and several are far enough away that it is impractical for me to provide on-site support or do it myself. Even if I could get a VPN or similar deployed on all their devices, I suspect that they're going to struggle with needing to connect to it just to upload or view photos, then disconnect afterwards to resume using the Internet -- I really need this to "just work" for them.

    So this brings me back to safely exposing these services to the outside world. My network architecture complicates this a little, so for context:

    • Modem/router has basic firewall and points to a Raspberry Pi for DHCP. I already have No-IP set up with a domain name so that I can SSH into my LAN when away from home.
    • RPi runs Pi-hole + dnscrypt, acting as DHCP and DNS server for the network.
    • I want to use nginx as a reverse proxy running on this RPi, as I have experience with it and it can add SSL using certbot. The router would be configured to use port forwarding to direct external traffic for ports 80 and 443 to the RPi.
    • Vikunja is hosted on a separate Raspberry Pi (with other things like Shiori)
    • I have not yet determined where Immich or similar is going to go. I have existing home server that I use for backups and important family stuff, but I really don't want this to be vulnerable to the outside world. If I were to install Immich here, I'd need it to be well-isolated from the rest of the system. The other option is to get a NUC or similar, which is what I am leaning towards as the less stressful option.

    So my main questions are:

    1. Beyond fail2ban and my router's firewall, what else can I do to protect my network once I open ports 80 and 443?

    2. How do I handle fail2ban configuration when the services are on different devices to the nginx proxy? I understand the best place to put fail2ban would be on the Pi running nginx (since it's the access point to the outside world), but that it also needs to read the logs from Vikunja, etc. to be effective.

    3. Where would you put Immich in my network architecture?

    Any other tips/recommendations for making this easy to use for my less tech-inclined friends and family would be much appreciated as well. Thanks.

     

    Sorry, this is a bit of a rant...

    I had to assemble an IKEA flatpack cabinet today.

    I always find this process painful because, to me, the instructions are always lacking (and a lot of other flatpack kits have followed IKEA's trend of picture-only guides). How hard is it to put a name below each component on the parts page (so I know what this weird thing is when it appears on page 22!), or indicate what's the top/front/back/etc.?

    Today it would have been really helpful to know which edge was the top and front for the sides of this kit, rather than flipping back-and-forth through the manual to work it out. The irony is that they got so close to realising this was a factor, since the instructions did actually have two procedures (depending on whether your ceiling was high enough to stand the cabinet up after assembly or whether you needed to assemble it in-situ).

    Is it just me and does everyone else just find it easy to follow the instructions, or do a lot of other people struggle with them too?

     

    I have a bit of an odd issue with my Surface Pro 3, which is running Debian 12.

    Occasionally (perhaps 1 in 15 to 20 boots) it fails to detect the keyboard properly (this is a genuine Microsoft keyboard cover that connects via the pins on the edge of the Surface, not one of the generic bluetooth ones you can get now). When that happens, the onscreen keyboard logo appears in the top right corner whilst the grub boot menu is displayed.

    When it then tries to boot Debian, it throws some kind of Secure Boot error and displays this error message:

    SbatLevel variable initialization failed
    Something has gone seriously wrong: SbatLevel UEFI variable setting failed: Invalid Parameter
    

    I then have to force it to power off and then try booting again. Usually it works the next time around.

    This one's got me stuck, as I don't know much about the Secure Boot process and I've struggled to find any other references to this error online apart from this question on Reddit (which unfortunately didn't resolve it).

    I find it particularly odd that this error only seems to occur when there's an issue with the physical keyboard, despite me being able to use the onscreen keyboard in grub. I can replicate this behaviour by detaching the keyboard and it consistently produces this error.

    Apart from trying to address the intermittent keyboard issues, which I am looking into (I may need to buy a new one), I have no idea where to start with the Secure Boot issue. Any suggestions would be much appreciated. Thanks.

    Update:

    Whilst I don't fully understand why this error was occuring, I did manage to resolve it.

    My Debian installation was using the default kernel (6.1.0-35-amd64 and 6.1.0.37-amd64 were installed) and selecting this would consistently cause the SbatLevel error with the keyboard removed.

    Installing the Linux Surface project kernel (currently 6.15.1-surface-2) per the instructions allows me to consistently boot without the error with the keyboard detached.

     

    Australia needs to rethink its relationship with the United States. We've done quite well maintaining a wary, non-trusting trade relationship with China. We now need a wary, non-trusting security alliance with the US, if that's even possible.

    view more: next ›