• 5 Posts
  • 546 Comments
Joined 4 years ago
cake
Cake day: January 21st, 2021

help-circle
  • It would be nice if there was a shortcut to go “back to previous site”. Because on one hand using back to navigate around map moves is often very convenient, but sometimes I want to go to the site before the map. Having a two-level history with page and site would be super useful.


  • This is a case of the streetlight effect. Evaluating the skills needed to do the job is very difficult in an interview setting, so most of the focus going on evaluating skills that are easy to evaluate in an interview (such as people skills).

    It isn’t wrong, as all else being equal it is still better to hire the person with better skills that you can measure but obviously is not a strong evaluation of candidate quality.






  • The short answer is that Docker (and other containerization technologies) share the Linux kernel with the host. The Linux kernel is very complicated and shouldn’t be trusted to be vulnerability free. Exploitable bugs are regularly discovered in the Linux kernel (and Windows and Darwin). No serious companies separate different tenets with just container technology. Look at GCP, AWS, DigitalOcean… they all use hardware virtualization which is much simpler and much more likely to be secure (but even then bugs are found on occasion).

    So in theory it is secure, but it is just too complex to rely on. I say that docker is good for “mostly trusted” isolation. Different organizations in the same companies, different software that isn’t actively trying to be malicious. But shouldn’t be used to separate different untrusted parties.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldMini pc arriving tomorrow
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    1 month ago

    IMHO Arch is actually a great choice. They do have a minimum update frequency you need to maintain (I don’t recall exactly, I think it is somewhere between 1 and 3 months) but if you do, and read the news before updates (and you are usually fine if you don’t, usually the update will just refuse to run until you intervene) things are pretty seamless. I had many arch machines running for >5 years with no issues and no reason to expect that it would change. This is many major version updates for other distros which are often not as seamless.

    That being said I am on NixOS now which takes this to the next level, I am running nixos-unstable but thanks to the way NixOS is structured I don’t need to worry about any legacy cruft accumulating from the many years of updates.

    And after all of that I don’t think it really matters. I think any major distro you pick, weather stable, release-based or LTS will be fine. They all have some sort of update path these days. (unlike in the past where some distros just recommended a re-install for major updates).



  • require a separate device that looks like a calculator to use online banking

    To be fair this actually provides a very high level of security? At least in my experience with AIB (in Ireland) you needed to enter the amount of the transactions and some other core details (maybe part of the recipient’s account number? can’t quite recall). Then you entered your PIN. This signed the transaction which provides very strong verification that you (via the PIN) authorize the specific transaction via a trusted device that is very unlikely to be compromised (unless you give someone physical access to it).

    It is obviously quite inconvenient. But provides a huge level of security. Unlike this Safety Net crap which is currently quite easy to bypass.


  • which is supposed to enforce to run apps in secured phones

    The point of the Google Play Integrity API is to ensure that the user is not in control of their phone, but that one of a small number of megacorps are in control.

    Can the user pull their data out of apps? Not acceptable. Can the user access the app file itself? Not acceptable. Can the user modify apps? Not acceptable.

    Basically it ensures that the user has no control over their own computing.







  • There are three parts to the whole push system.

    1. A push protocol. You get a URL and post a message to it. That message is E2EE and gets delivered to the application.
    2. A way to acquire that URL.
    3. A way to respond to those notifications.

    My point is that 1 is the core and already available across devices including over Google’s push notification system and making custom push servers is very easy. It would make sense to keep that interface, but provide alternatives to 2 and 3. This way browsers can use the JS API for 2 and 3, but other apps can use a different API. The push server and the app server can remain identical across browsers, apps and anything else. This provides compatibility with the currently reigning system, the ability to provide tiny shims for people who don’t want to self host and still maintains the option to fully self host as desired.


  • IMHO UnifiedPush is just a poor re-implementation of WebPush which is an open and distributed standard that supports (and in the browser requires, so support is universal) E2EE.

    UnifiedPush would be better as a framework for WebPush providers and a client API. But use the same protocol and backends as WebPush (as how to get a WebPush endpoint is defined as a JS API in browsers, would would need to be adapted).