Thank you, that helped :)

I am not entirely sure why you need to do all that but I am trying a different approach and allowing a small entrypoint to set PGID and PUID (which you should be able to set as env variables in the docker-compose.yml file).

This should allow you to run the app as whatever user you wish. It works for me locally, it’s currently on the develop image if you wanna give it a spin and report back. Otherwise it’ll be added in the next release.

Defaults are still 1000:1000.

Hey sorry for the delay, dealing with a lot right now, but I didn’t forget about it.

1 - Fixed this, the api key is now only forwarded if the destination hostname matches the plugin’s stored url. 2 - As I was saying, the allowlist is opt-in by design (null = allow all), and plugins legitimately need to make arbitrary outbound requests. Enforcing it globally would break the plugin system. 3 - Fixed this, it was quite simple 4 - I have added an env var (DEGOOG_DISTRUST_PROXY), if set to true it’ll make it so all users share the same rate limit regardless of their IPs, I left it as an opt in as most users currently running it are only keeping it private behind their own in house reverse proxies. This will be handy for a public instance for example 5 - Extension settings modal now correctly sends x-settings-token on save. 6 - As I said, auth is intentionally lax until a more structured auth system is added, may need to be a few weeks after stable is live, after all there’s no real auth and the setting password protected and private view should be secure enough as it is

btw all this is not live yet, it’ll be sent live with the next release ♥

Madness, wasn’t expected to get any coverage for it until it was out of beta 😆

Thanks, I’ll individually look into all of these ♥️ I’ll say some of them are more conscious compromises for the sake of an open scalable system where third party extensions can truly edit anything (intentionally) and everything around Auth/secure cookie is also fairly lax due to the fact the Auth is just a protection for the settings (which literally stop the settings from being served by the client), in the moment I decide to add some more structured Auth system/maybe users I’ll look into proper secure cookie handling.

This is an awesome report, thank you so much for sharing it!!!

degoog Dev here, definitely not vibecoded. Would you be able to tell me all these whack of privacy issues? I thought I had everything covered, but if you found something concerning it’d be nice to know before I get it out of beta :)

Absolutely ♥️

I’d have a read here :)

www.google.com/patents/opnpledge/pledge/

Whilst you’re generally right, Google does not have a history of suing open source projects and they very much care about optics in this specific aspect (at least so far and for now). Whilst I’m not a fan generally, it’s undeniable how much they contribute to open source in general :) it’s always good to give credits where credits are due as it’s the kind of behaviour we want to encourage you know

I think it’d be a very bad look for a company the size of Google to file something against a tiny open source application.

Colors are slightly different, the word “Google” can’t be copyrighted and it’s an aggregator and not an engine, that said I do want to rebrand before going out of beta, mostly due to this being impossible to find when searching for it 😆

I’ll look into it, depends if the engines allow that natively and is part of the URL search query

Well yeah, the absolute best way to make sure you get consistent results would be to privately selfhost this of course! There aren’t enough public instances yet, hopefully more people step forward ♥️