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.
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. 🤷🏻♂️
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !privacyguides@lemmy.one
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:
We prefer posting about open-source software whenever possible.
No soliciting engagement: Don’t ask for upvotes, follows, etc.
Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
Be civil, no violence, hate speech. Assume people here are posting in good faith.
Don’t repost topics which have already been covered here.
News posts must be related to privacy and security, and your post title must match the article headline exactly. Do not editorialize titles, you can post your opinions in the post body or a comment.
Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
No help vampires: This is not a tech support subreddit, don’t abuse our community’s willingness to help. Questions related to privacy, security or privacy/security related software and their configurations are acceptable.
No misinformation: Extraordinary claims must be matched with evidence.
Do not post about VPNs or cryptocurrencies which are not listed on privacyguides.org. See Rule 2 for info on adding new recommendations to the website.
General guides or software lists are not permitted. Original sources and research about specific topics are allowed as long as they are high quality and factual. We are not providing a platform for poorly-vetted, out-of-date or conflicting recommendations.
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
declarativeNetRequestis designed as a more secure replacement forwebRequest, 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.
webRequestwould be able to block the domains and still run those .js files.declarativeNetRequestwould 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. 🤷🏻♂️
You are.
if he paid he has the right to complain.
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.
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. 🙂