In the digital age, protecting your personal information might seem like an impossible task. We’re here to help.
This is a community for sharing news about privacy, posting information about cool privacy tools and services, and getting advice about your privacy journey.
You can subscribe to this community from any Kbin or Lemmy instance:
Check out our website at privacyguides.org before asking your questions here. We've tried answering the common questions and recommendations there!
Want to get involved? The website is open-source on GitHub, and your help would be appreciated!
This community is the "official" Privacy Guides community on Lemmy, which can be verified here. Other "Privacy Guides" communities on other Lemmy servers are not moderated by this team or associated with the website.
Moderation Rules:
Additional Resources:
Just an FYI that this extension redirects after the initial request is made, due to a limitation the WebRequest API from when the extension was implemented. This means it still reaches the destination before the redirect occurs.
The developer has been made aware of the declarativeNetRequest API which avoids this issue but he has yet to make any updates.
Okay, so I went and checked out that issue and I spent 20 minutes reading the linked documentation and checking through the codebase. As far as I can tell, implementing this would require a complete re-write to how the extension currently works. This is because declarativeNetRequest is designed as a more secure replacement for webRequest, which is probably why Apple supports it in the first place. It takes the job of writing redirects out of the hands of the extension and gives it to the browser instead.
In the current codebase, after the browser matches a url, the extension runs a .js file to chop out what it needs, rewrite it and finally trigger the redirection. webRequest would be able to block the domains and still run those .js files. declarativeNetRequest would require all of that to be rewritten as regex and JSON expressions. It also might not even be possible, as I'm not sure you can dynamically change those JSON expressions after the fact, say when you want to change which instance you're being redirected too.
Edit: Also the dev was made aware in late March, so if a full rewrite is needed I'm not surprised it hasn't been completed yet.
Rules can be updated dynamically using updateDynamicRules.
I wrote an extension that implements declarativeNetRequest redirects to private front ends just using a static hardcoded list. It only took a couple of hours. I’m using it on MacOS and iOS. I don’t think it’s the kind of thing that would take significant investment from the developer, I just don’t think they have any plans or motivation to make it more private than the current implementation.
I think you’re assuming a lot of the developer. It’s just one person, and selling this for a few bucks clearly isn’t their day job. The entitlement of some people on github is real. Like, why not help the dev out, submit a pull request? Instead of whining that they won’t ever implement something.
Edit: Before you tell me to put my money where my mouth is, before I made this post I submitted a pull request to this repo. Wanted to be able to set my invidious instance with yattee:// at the start so it would automatically open them in app instead. Actually found an issue with someone else requesting the same feature and linked the PR to it.
Who’s whining? I haven’t even contacted them. I paid for their app, but didn’t use it because the implementation didn’t meet my needs. So I wrote my own. 🤷🏻♂️
So I wrote my own
Is it available in the AppStore? I'm interested!
Not yet. I’ve renewed my developer account recently. I’ll try to get the code cleaned up and submit it. 🙂
Who’s whining?
You are.
You’re inferring a lot more emotion and tone in my comments than what I have felt as I wrote them. As such, your responses are making it an unpleasant experience to share knowledge with a community.
You mean how you inferred a lot more intention from the dev in your comments, and made it unpleasant to share a resource with a community?
It’s fair enough to share that it currently isn’t fully secure. But you complained the dev would never fix an issue they’ve known about for a few months. Then you went on about how you just coded an app yourself. Well then go put it on the app store so there’s a secure one if you think the dev won’t ever fix it. Or, contribute back to the open source community. Or, don’t cast aspersions about what other devs do with their time.
Edit: The dev’s also a human being. They might have had a significant life event happen during that time.
The app might be GPL, but it’s a paid app. I see no reason to submit a PR to do the work for the developer. I am also a customer of his, so I don’t think it’s unreasonable that I had hoped he would make his app fit for purpose. If I raise a PR to help his LLC sell apps, I have no control over whether he will actually accept changes or submit changes to the App Store, either. I don’t intend to give my time away like a charity to an LLC.
I wrote my own app to determine whether Safari had implemented enough of the properties of the declarativeNetRequest API to allow for redirects. It turns out that it does, and in this way, it avoids reaching destination servers and avoids cookies they may set or analytics they run, and counts towards MAU. It also works with DNS blocks to target sites.
If I release it on the App Store, it will be free.
In any case, I said nothing bad about the developer except that they are aware of the new API but have not shared plans or shown motivation to adopt it. That’s not a negative comment and does not detract from the possibility of significant life events etc. It’s simply an observation.
It seems like you’re crafting a straw man out of a few words I shared about a privacy app.
You really aren’t gonna stop until you “win” by me not replying, are you?
if he paid he has the right to complain.