BUG - IOS15/MacOS Monterey - Apple Mail Security 'your network settings prevent content from being loaded privately'

should be off/false at least should be a setting-option in the webinterface.

found this workaround - is this the recommended way?

  1. SSH to your Pi-hole server
  2. Run the following command: sudo nano /etc/pihole/pihole-FTL.conf
  3. Append the following setting to this file and save the file: BLOCK_ICLOUD_PR=false
  4. Either restart your Pi-hole server, or just restart the DNS Resolver service

cheers
tom

2 Likes

Please see the release notes for Pi-hole FTL v5.10.1, Web v5.7 and Core v5.5 released

1 Like

thanx! but again - in my opinion it's a wrong decision to disable apple prvate relay by default. and on top it is a second wrong decision to not make it an option in webinterface where lots of real superfluous bullshit options are availible and some really important are missing.

just my two cents
cheers
tom

If BLOCK_ICLOUD_PR=false would be the default, Pi-hole would be by-passed by default via Apple's Private Relay. Personally, I wouldn't consider that a sane default.

1 Like

you can think what you like about apple. but it is without question the only tech giant that respects the privacy of its users halfway. the operators of the other nameserver selectable via which is otherwise resolved are unquestionably rather more questionable than apple. and the ip obfuscation etc of apple for mail makes sense without question.

I'm not at all commenting on the pros and cons of any specific OS feature.

I just advise you that by setting BLOCK_ICLOUD_PR=false, you are allowing your device to by-pass Pi-hole, provided it is employing Private Relay. Don't expect Pi-hole to do much filtering for such a device.

If you set BLOCK_ICLOUD_PR=true, Private Relay is blocked according to Apple's recommendations for returning network traffic control to normal.

Whether you opt for filtering by Pi-hole or for enjoying the benefits of Private Relay is entirely your choice, of course.

Note that it would seem that Apple made the choice of Private Relay network dependent, e.g. you could opt to not use Private Relay when connected to your home network where Pi-hole resides, while still employing it when using mobile data from an iPhone on the road.

apple-private-relay

1 Like

It always again comes down to one and the same question: Whom do you trust?

You are trusting Apple to offer the service as they describe. Sure, you can spin up tests to ensure it is really working as they promise and I'm not thinking they're cheating here. However, I don't think this is the ultimate solution but it comes down to this one question.

For me, the privacy solution looks differently, it is all webbed around Pi-hole and manufacturer-independent:

  1. Use a local unbound recursive resolver so I'm independent of the large data-harvesters
  2. I use Pi-hole to do filtering based on lists
  3. I use a Wireguard connection to get the same protection when on the road
  4. I do never download images and rarely (really never) look at HTML mails, plaintext always has all information you need.
    Further note that attachments are stored on the mail server, you are not downloading them from the sender's server. If you have to go through a link, Apple's mail protection wouldn't protect you.

My framework is:

  1. I do not think my ISP is inspecting my traffic. They are not allowed to even look at my traffic in Germany.
  2. I'm reasonably protected against man-in-the-middle by DNSSEC (all root servers and all TLD, more and more websites enabling it, too)
  3. I have a floating IP. On the next day, I will get a new one out of a pool used by millions of other users. This does not touch my privacy feeling.

Everyone is allowed to disagree on my solution, obviously, I just want to point out that there are manufacturer-independent and completely free-of-cost solutions that can easily be combined with Pi-hole.

3 Likes

i agree with most of your views and do the similar. but:

  • i think not using html emails limits you too much in today's environment
  • apple solution for just this mail tracking i think is very good
  • considering the illegal use of covid19 visitor lists by the police in restaurants i wouldn't be too optimistic about german providers
  • if you set BLOCK_ICLOUD_PR=false you get the best of both worlds as i understand it everything that should go to apple goes through apples server and big parts of the other advertising/tracking garbage will still be blocked on apple devices by pi-hole.

" [BUG - IOS15/MacOS Monterey - Apple Mail Security"

It is not a bug, and that is not a workaround - it is the designed method to change the Private Relay setting in Pi-hole.

What would you consider examples of each category?

We handle this potential Pi-hole bypass in exactly the same way we handle the potential Firefox bypass. We followed the recommendations of the developers of those software packages.

The default of enabled for blocking iCloud Private Relay domains is done so that devices on your network won't bypass Pi-hole unless you take specific action to allow this. It seems reasonable that if you are running Pi-hole on your network as an ad-blocker, you would like it to block ads for all connected clients - thus the default setting of enabled.

How to change this setting (and the Firefox canary domain setting as well) is fully described in our documentation.

https://docs.pi-hole.net/ftldns/configfile/#icloud_private_relay

The distinction between (DNS) traffic that goes through the relay and traffic not going there might rapidly vanish. At the moment only Safari's traffic uses the private relay. But this feature is still in beta phase and tomorrow all traffic might go through the tunnel.
And why would users want one part of their traffic be filtered by Pi-hole and one to be not filter?

pretty easy to answer: the setting for the apple privacy solution is not global for the computer - you can run the emails via the apple servers and safari etc via the pi-hole.

This is a decision made by apple - they tied the Mail Security to the Private Relay function.

just write them that you don't like it.

I'm lost in your discussion points. If you want to use Private Relay, do so. If you want the email download feature, you have that option. We don't have a position on (nor do we care) which option you choose and have provided methods in Pi-hole configuration to do either.

my points were:

  1. i don't think it's a good idea to react so indecisive on the step of a giant like apple. if you would have set this by default you can be controversial about it. but that this should have been an important menu item in the webinterface is out of question for me. especially because there are much less important things in the webinterface.

  2. to store the same constants/variables (here ip-addresses) redundantly at several place/files is simply a sign of bad programming habits.

  3. not displaying the current ip-address in the webinterface of a network device is very strange. to have displayed the address before from a dead file unreliable is completely bizarre.

that's all. but since no one here cares anyway, i don't care too. that simple.

nice greetings from bavaria

I wouldn't say nobody is caring, in face, a vivid discussion going on here. Part of discussion things is that the involved parties are allowed to be of different opinion.

Here are my reactions to your three points. Further feedback can help us to improve.

    1. Why do you say "indecisive"? Pi-hole is a "network-wide ad blocking solution". Hence, we assume you want all your devices to be part of this network-wide action. With privacy relay they don't. Apple themselves suggest in this case to do exactly the steps we did. I cannot see any indecisiveness therein.
    2. I agree on the point of less important options being there and more important ones missing. The truth here is that the settings you see there are there since early days of Pi-hole. The current system does not allow for a straightforward addition of new settings. I agree this is really worth improving. Hence, we are actively working on this behind the scenes with the work on Pi-hole v6.0. And when I say "behind the scenes" I don't mean hidden - everything is on Github accessible for everyone who is interested. As part of this reworking, we also plan to add all the settings onto the web interface. Let's see what will be the best solution in the end. There will be a big alpha/beta round on this and user feedback will be highly appreciated.
  1. The file setupVars.conf is a relict from the very early days ans we used to store what options you chose during install (hence the name). This is slowly being replaced by better config files.
  2. There may be multiple IP addresses on your device. I don't see much value to show them as you will always be able to reach your Pi-hole under pi.hole or the device's hostname and get the most suitable IP address being served to the requesting client. The IP address stored in setupVars.conf died at the same time when the displaying was removed. We do not show any "dead" information.
1 Like

hello dl6er - thank you for the friendly factual and comprehensive answer!

  1. with 'indecisive' I mean such an important function not directly in the web interface to take over. that would have been with the ever increasing market position (especially mobile devices) of apple really more than wise. and not everyone who deals every few months or years with the pi hole may then first deal with the configuration over the cli again.
    i didn't know that you are aware of the partly not very useful functions in the webinterface and the missing important points. but then we are mostly of the same opinion anyway and the whole thing is already in progress - and with a freeware project it takes some time until all the work is done because it all depends on your free time.

  2. thanks for the info! then i don't need to complain anymore :wink:

  3. i find it very good and useful to see the most important network parameters in the webinterface (best already on the startpage). it's mostly like that with expensive routers switches firewalls etc.

so here again all the things i miss and which i think are very useful/important and would make pi-hole an even greater tool:

  • apple icloud private relay settings in webinterface
  • display of network parameters on the start page of the webinterface
  • all configuration parameters of the pi-hole in one place in one file
  • possibility to create more than one network (rev-server) in the webinterface
  • possibility to delete and backup entire history (pihole-ftl.db) via webinterface
  • possibility to exclude single clients from data logging (in webinterface)

have a nice sunday + greetings from munich (home of the oktoberfest)
tom

I don't think this is true. I checked a few pages (e.g., this) and the share seems to be pretty constant or even slightly decreasing. This isn't really clear. I also wouldn't expect their share to grow significantly mainly due to the quite extreme prices of new products (used phones don't seem an alternative for many). The problem I see with Apple is that they intentionally ship a pretty closed ecosystem for a comparably high price. They may be selling good hard- and also software but it seems the majority (currently 85% according to the link above) is not ready to pay the price or chose alternatives for other reasons. I'm myself not part of the Apple ecosystem with computer, laptop, etc. both due to the price but also due to disliking the interface and workflow. I'm used to Linux workflows and when my employer offered me a Mac Book laptop, I tried it and later decided that I get a much better laptop (in terms of fitting my workflows) running Linux for the same price. And when I hear rumors (not sure if they are still true) that iPhones actively refuse to exchange files via Bluetooth with Android devices, this does not emphasize them in a positive way IMO.
Please be assured that this all is personal opinion and I have nothing against Apple users or their products just in case this isn't really clear. Android on my phone and Linux on other machines just works a lot better for me.


I know, it would involve some work but I see best possibility to get things implemented when you can open feature requests for the individual components. There we could discuss details like what you mean exactly with "network parameters" (IP addresses or more). If we'd start such petty details herein, it'd likely that things get lost. And there may already be feature requests for one or the other point. Maybe they can be revived by giving votes and detailing them.

1 Like

i think that the market share (also concerning the pi hole) should not be seen worldwide. in europe and usa the market share is 30-50% and i would consider that a very serious player. as soon as people understand more how stupid it is to use huawei etc. this will bring apple further forward in eu and usa. and the disgusting data octopus google is also no alternative. the market power of apple could also be seen well in the story with macromedia/adobe flash. whether the pi-hole is now very widespread in china etc i think rather not - but you will know better. in any case we are no apple fan-boys and know about the sectarian character of the company but because of their exobitant profits with the hardware they are not dependent on the data theft of google facebook etc. for us it is simply the best of both worlds - even easier to use than windows - similar stable and secure as linux. and the devices are incredibly durable, cheap and powerful if chosen correctly. linux is excellent for server applications - but as a desktop os it still has far too many weaknesses and important software doesn't run on it. unfortunately, far too little has been done in the last 20 years - let's see if ubuntu/debian can do it one day.

putting things on github has the disadvantage that only real nerds will do that - reasonable ideas or bug reports from the majority of (normal) users will never find their way there. which won't lead to an improvement of the market share of a software.

cheers
tom

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.