I've looked over the code, and some things seem a little odd to me.
The article starts by mentioning how insecure the browser is, apparently even cookies aren't secure. But then the API to talk to the BFF uses.... a server-side session tracked via a client cookie. If the BFF is holding the oauth credentials, then someone could steal the client cookie to make requests to the BFF to do whatever it can do.
It's not impossible to secure the browser from having credentials stolen from inside it, but it can be tricky to ensure that when the browser sends the credential in the request it doesn't leak somehow.
There's some irony as OAuth has DPoP now which can reduce the usefulness of stolen in-flight credentials but that can't be used in this BFF setup because the browser client needs the private key to sign the requests.
Properly securing the browser content on a login page, or the subdomain handling authentication credentials is definitely a challenge, and many don't like having to eliminate/audit any 3rd party JS they include on the page. I can see the appeal of a solution like this, but the trade-off isn't great.
Self-hosted FreshRSS, NetNewsWire on Mac, Fluent reader on linux/windows/ios. Any reader compatible with Google Reader API works with FreshRSS, and Fluent was the nicest UI I've seen (hasn't been updated recently, but I don't need new features).
I was able to make a uWebsockets adapter for NestJS pretty easily. It's a bit sensitive of a library to integrate though, a single write when the connection is gone and you get a segfault, which means a lot of checking before writing if you've yielded since you last checked. This was a few years ago, perhaps they fixed that.
I was under the impression that the underlying net/http library uses a new goroutine for every connection, so each websocket gets its own goroutine. Or is there somewhere else you were expecting goroutines in addition to the one per connection?
That's just an arms race. The kid will find a new favorite website to play games on, there seems no end to them. There's endless websites out there that are more appealing than doing homework. I have a very locked down network, there's always some new website that has games of some sort to play.
If schools are going to provide these things, they should have the sites the kids might need to access white-listed and block everything else. Telling parents to try and block things is not realistic.
Yes, that was kind of my point. Self-hosted negates the need, but most can't self host.... so that leaves end-to-end encryption the best intermediate step.
I self-host Immich and its definitely my favorite web photo system. One thing with Ente that aligns more with Mozilla's approach to data however is end-to-end encryption, which Ente has, but Immich doesn't. So I can see why Mozilla funded this option instead.
I personally wish that self-hosting was a more reliable and simplified process for the average person such that simpler and more powerful software like Immich was the best choice for all.
The mix package manger for Elixir has a release option which compiles and bundles everything to a single binary. It appears possible to use Gleam libraries/code with mix, which should allow one to compile it all down to a single binary as well (though I haven't attempted this myself).
I've been self-hosting a lot of things on a home kubernetes cluster lately, though via gitops using flux (apparently this genre is now home-ops?). I was kind of expecting this article to be along those lines, using the fairly popular gitops starting template cluster-template: https://github.com/onedr0p/cluster-template
I set one of these up on a few cheap odroid-h4's, and have quite enjoyed having a fairly automated (though quite complex of course) setup, that has centralized logging, metrics, dashboards, backup, etc. by copying/adapting other people's setups.
That was what the authors claimed when I asked them about the macaroon patent. It'd be nice if Google had a legal document associated with patents they never plan to enforce, or the constraints around when they might enforce them (e.g. only against patent trolls) that a company could rely on.
I remember when I saw a presentation by the macaroon authors a few years back, there were pending patents that Google filed around them. While the authors claimed Google wouldn't sue anyone, I'm always a bit skeptical about such claims. I thought macaroons would be helpful for some of my use-cases, but since I now knew there were patents that'd be wilful infringement so I didn't bother.
I can't find the patents now, so perhaps they were rejected or withdrawn. I had assumed that was why macaroons hadn't caught on more widely.
This is how I use the tool the author created, Structurizr. I auto-generate the initial diagrams, then manually fix it to make it more readable. We then check-in the JSON workspace export into our git repo. The first two levels of the C4 model don't change regularly, so this isn't a frequent process to repeat.
Not sure, it depends on what the numbers look like going back to the founding of the company. Tesla probably wouldn't have survived in the past without the credits, but as others in the comments noted the point of the credits is to enable companies selling EV's to survive and grow during their difficulties in the switch to EV's. So I definitely wouldn't consider this a mark against Tesla, the credits are doing what they're supposed to, to an extent.
That's a once type thing, the website is supposed to prompt you after that QR login whether you'd like to enroll your local authenticator (Chrome, Edge, Firefox,etc) after you login so you don't need to keep using the QR code.
The concept is that many people will frequently have multiple passkeys, thus not be 'locked in' to any one sync ecosystem.
> When signing in on a different computer, either the credential will already be locally present (if the computer is using the same sync fabric as the phone) and suggested by autocomplete, or else the user’s phone can be used to transmit the assertion to the computer. In the latter case, the service may invite the user to enroll a local platform authenticator for easier sign-in in the future. (Now the newly registered credential may be part of a different sync fabric, and thus enable local sign-in on other devices.)
Disclaimer: I've done some development on Home-Assistant (HASS), and work on the Nabu-Casa cloud service for Home-Assistant. I was contacted by a NixOS core contributor to see if there was a better solution for HASS in NixOS.
This is a bit misleading, a single HASS developer requested their packages not get repackaged because they didn't want the support burden of users who think the software is broken when its actually due to packaging.
Both the GitHub issues have since been closed and settled.
It's useful and important to note that Home-Assistant's turnkey ease-of-use is partly because its acting as a package manager of sorts. When integrations and components are added by the user, their package requirements are downloaded immediately from the Internet and installed. This is quite contrary to the intended operation of NixOS and its immutable and reproducible package installation concept.
This is where the concerns of Frank came in, as a user of HASS on NixOS will likely have a sub-par experience and the documentation on the Internet for HASS will not work correctly for them in many cases. On the other-hand, I'm sure a decent amount NixOS users are probably aware of this (as I was when I was using NixOS daily).
My suggestion (and supported by the HASS founder) was that NixOS repackage HASS and call it something else, like how the code behind Firefox is repackaged without the Firefox name. This way at least NixOS users of it will get more appropriate Google results when searching for an issue related to their install, and are unlikely to burden HASS developers with support issues that are likely related to the install approach and not a HASS issue.
This was back in July of 2021, and I haven't followed up on it since, so I don't know if NixOS is doing this yet, or what the current state is there. But if you're running NixOS and want that turnkey experience, you're not going to get it.
The article starts by mentioning how insecure the browser is, apparently even cookies aren't secure. But then the API to talk to the BFF uses.... a server-side session tracked via a client cookie. If the BFF is holding the oauth credentials, then someone could steal the client cookie to make requests to the BFF to do whatever it can do.
It's not impossible to secure the browser from having credentials stolen from inside it, but it can be tricky to ensure that when the browser sends the credential in the request it doesn't leak somehow.
There's some irony as OAuth has DPoP now which can reduce the usefulness of stolen in-flight credentials but that can't be used in this BFF setup because the browser client needs the private key to sign the requests.
Properly securing the browser content on a login page, or the subdomain handling authentication credentials is definitely a challenge, and many don't like having to eliminate/audit any 3rd party JS they include on the page. I can see the appeal of a solution like this, but the trade-off isn't great.