Closed gracjankn closed 2 years ago
I've noticed this as well, I assume it works by injecting some sort of redirect after the page starts to load? Is there a way to instantly redirect to a privacy-conscious version of those websites without having to wait for the page to load and re-direct?
This is very serious issue, because by the time the redirection is completed, the server has already received some of the user's information.
If you need to use the extension and still block these domains in other apps, you have to figure out a way to use separate DNS servers in Safari.
I think that in the upstream project for Firefox and Chromium based browsers, the redirection happens instantly, regardless of wherever the original domain is reachable.
@ajkblue's assumption is correct: Privacy Redirect for Safari redirects the user once the page begins to load. As @gracjankn's assertion about the upstream project – that it redirects before contacting the original domain – is also correct.
Unfortunately, this is an issue with Safari and not something that we can solve: Safari doesn't fully support the WebRequest
API, which is used by the original extension. As it stands, an early redirect is the best possible in Safari.
He keeps closing tickets regarding this, but this ain’t Safari limitation. I just checked if there where any updates in the mean time. But this is just false privacy and not correct also. You can do this before reaching the original domain. All other Safari Extensions does.
I do keep closing tickets regarding this: the situation has not changed. To redirect before reaching the original domain, one must use the webRequest API. To prevent the original site from receiving any requests, you have to use webRequestBlocking.
Unfortunately, Safari doesn't support webRequestBlocking at all, and doesn't support webRequest on iOS. Please see "Assessing Your Safari Web Extension’s Browser Compatibility" for more information, though I will summarize relevant points below:
permissions.webRequestBlocking
Not supported. Usepermissions.webRequest
instead for macOS only.
webRequest
Not supported in iOS.BlockingResponse
not supported. Blocking requests not supported.opt_extraInfoSpec
not supported for any of the events.
For further documentation on the subject, you can review the "Browser compatibility for manifest.json" table on MDN.
I hope at this point you can understand the technical limitations and constraints that we have to work with. However, I'd like now to address your last idea: that "this is just false privacy." You are correct that this is not as effective as redirects utilizing the webRequestBlocking API in Chrom{ium,e} and Firefox in terms of privacy preservation, but, crucially, it's better than nothing. And sometimes you have to take what you can get.
Hello! Safari 16.4 is soon to be released and includes support for the declarativeNetRequest API. Here's the relevant section in the Safari 16.4 release notes. Do you know if this can be used to redirect requests before they load the site?
Good find. I'll check it out!
I'm blocking the domains this extension is supposed to redirect away from using DNS, which prevents it from working at all. When I add a domain like
YouTube.com
to a whitelist, the redirection works.