The problem without having consent is that it's easy to track who is using your service. Because there's no consent, they can redirect you to login and back, and grab your identity, without you doing anything other than loading the page.
You can do the same thing - with the added burden of actually having to set it up once ... After you set it up, it's however just as trivial to add new systems like with this linked example.
I got pretty much everything I'm self-hosting like that via keycloak (which itself let's me do social with via GitHub and Google etc pp) and a very similar nginx config like it's shown in these docs.
But the initial setup took multiple hours, even if the adding new services which support forward/proxy auth is extremely easy now.
(Jellyfin sadly doesn't as an example)
Just saying it in case you want to check it out.
I think it's fantastic they added that/provide this to their platform - it's a wonderful value-add
I think running and managing and possibly misconfiguring a keycloak java monolith would be exactly what I'd want to avoid which is why it's cool that they offer this.
There are a lot other identity providers around you can pick from, I merely mentioned it as I personally use it, as it's so easy to run and integrate with social auth - and comes with features such as simple password-less auth.
The forward auth/proxy auth is not a keycloak feature, it's a proxy feature, which just need some identity provider. If you look for the mentioned term via Google or AI/llm you will find multiple options, some of which are as easy to setup as a simple docker run cmd with an open port
if you haven't read the factorio devblog before, please do!
after HN, it's one of my favourite places on the internet because i constantly learn new, random, insane things almost every time. imho it teaches you how to think + shows you what great engineering taste looks like. sorry if i'm overly effusive but each post is so deeply technical and well-written that i can't believe it's free.
you don't need to know anything about factorio or gamedev btw (i don't), just pick a random number between 1 to 438 and start reading :)
I used to say the same about the Eve Online dev blog, but at some point I stopped reading because they were creating an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang.
Concurrency is hard. Blizzard added progressively more and more concurrency over time to rescue orphaned resources assigned to a single shard that was undersubscribed while another shard in the same AZ was seeing flash mobs. But the way they documented it was more of a tea leaves situation. Only enough data to guess what they had done if you were familiar with the space.
>Note that there isn’t the slightest attempt to explain the planet trajectories (specifically, why the planets keep ending up where they do regardless of how many epicycles you bolt on) from a theoretical perspective. My impression is that they have absolutely no idea why the heavens behave the way they do; all they can do is stare at the night sky, record, and see what happens. That is not reassuring to me at least.
I think people have been selling things that they don't know how they work for a long time. Think herbalists selling medicinal plants, I'm pretty sure Romans didn't know how or why concrete works, but they still used it.
Vector embeddings are lossy encodings of documents roughly in the same way a SHA256 hash is a lossy encoding. It's virtually impossible to reverse the embedding vector to recover the original document.
Note: when vectors are combined with other components for search and retrieval, it's trivial to end up with a horribly insecure system, but just vector embeddings are useful by themselves and you said "all useful AI retrieval systems are insecure by design", so I felt it necessary to disagree with that part.
> Vector embeddings are lossy encodings of documents roughly in the same way a SHA256 hash is a lossy encoding.
Incorrect. With a hash, I need to have the identical input to know whether it matches. If I'm one bit off, I get no information. Vector embeddings by design will react differently for similar inputs, so if you can reproduce the embedding algorithm then you can know how close you are to the input. It's like a combination lock that tells you how many numbers match so far (and for ones that don't, how close they are).
> It's virtually impossible to reverse the embedding vector to recover the original document.
If you can reproduce the embedding process, it is very possible (with a hot/cold type of search: "you're getting warmer!"). But also, you no longer even need to recover the exact original. You can recover something close enough (and spend more time to make it incrementally closer).
I wouldn't say those two are equivalent. A cryptographic hash requires the exact full document to be available to "recover it" from the hash. With a vector embedding you can extract information related to the document from the embedding alone as long as you know (or can guess) what embedding model was used. You won't be able to reconstruct the document but you will be able to infer some meaning from the vector alone
Yes there have been multiple papers showing information extraction from embedding vectors if you know the model used. SHA by design maps similar strings pseud-randomly. Embeddings by design map similar strings similarly.
[1] https://exe.dev/docs/login-with-exe
reply