Finally, it works, on all macOS Sonoma devices. Great! Thank you️

Still the same, sadly.

Strangely enough, I have

two cookie containers on the new MacBook (where v7 works fine):

• shown as "Cookie", invisibly named: com.sweetpproductions.cookie.app
  (creation: 11/2023, last change: current date and time)
• shown as "Cookie", invisibly named: com.sweetpproductions.CookieApp
  (creation: 05/2022, last change: current date and time too)

one cookie container on the old MacBook (where v7 doesn't work):

• shown as "Cookie", invisibly named: com.sweetpproductions.cookie.app
  (creation: today, last change: current date and time)

ALL containers have identical permissions:

• "read+write" for "me"
• "none" for "everyone"

Well, it's strange, but it's not essential at the moment, since at least one of the MacBooks works fine.

So don't forget to have a nice and relaxing Sunday!
Looking forward to a good idea when it'll happen to come.

I have the same problem, but not on every MacBook!

ALL MacBooks have macOS 15.0, Safari 18.0, and Cookie v7.4.2 with full disk access and licence recognised in settings.

In Cookie v7.4.2 on MacBook Air (Mac14,15) with M2, Safari is activated. ️

In Cookie v7.4.2 on MacBook Air (Mac10,1) with M1, Safari is NOT activated.

On M1-MacBook, Cookie v7 should have been installed for the 1st time (with full disk access granted after installation/start of v7). Also Cookie v6 has been uninstalled (after having killed sandbox settings and macOS reboot, without data export/import, but data should be taken from iCloud from other MacBooks, later). Maybe I downloaded v7 first, before uninstalling v6, but then uninstalled both, and finally have v7 installed exclusively.

Anyway, the "Activate Safari" button is greyed out, and any click on "allow" buttons doesn't bring any reaction or change.

Great service – as always. Thanks️

After having changed some macOS Sonoma settings, regarding stage manager, desktop view, multiple displays, etc., Cookie 7.3.5 – and ONLY Cookie app – crashes on every attemp to switch the app to full screen view. Any other view (simple window, or hidden window, or no window) works fine. So it's not an urgent issue. Cookie works fine – just not in full window mode.

Restarting the app, the user or the system, doesn't solve the problem. Unfortunately, it is not possible to restore the macOS Sonoma settings changed bevor. Anyway, I'm not sure if that's the cause of the problem. It is coincident, but not necessarily causal. Anything I can offer is this:

Ausnahmename: NSInternalInconsistencyException
Beschreibung: Invalid parameter not satisfying: [self canBecomeMainWindow]
Benutzerinformationen: {
    NSAssertFile = "NSWindow.m";
    NSAssertLine = 14114;
}

0   CoreFoundation                      0x000000018dc8b2ec __exceptionPreprocess + 176
1   libobjc.A.dylib                     0x000000018d772788 objc_exception_throw + 60
2   Foundation                          0x000000018edfe42c -[NSCalendarDate initWithCoder:] + 0
3   AppKit                              0x000000019157fdcc -[NSWindow _changeJustMain] + 372
4   Cookie                              0x0000000100a1ec28 Cookie + 175144
5   libdispatch.dylib                   0x000000018d984750 _dispatch_call_block_and_release + 32
6   libdispatch.dylib                   0x000000018d9863e8 _dispatch_client_callout + 20
7   libdispatch.dylib                   0x000000018d994bb8 _dispatch_main_queue_drain + 988
8   libdispatch.dylib                   0x000000018d9947cc _dispatch_main_queue_callback_4CF + 44
9   CoreFoundation                      0x000000018dc57ad4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
10  CoreFoundation                      0x000000018dc15258 __CFRunLoopRun + 1996
11  CoreFoundation                      0x000000018dc14434 CFRunLoopRunSpecific + 608
12  HIToolbox                           0x00000001983b819c RunCurrentEventLoopInMode + 292
13  HIToolbox                           0x00000001983b7fd8 ReceiveNextEventCommon + 648
14  HIToolbox                           0x00000001983b7d30 _BlockUntilNextEventMatchingListInModeWithFilter + 76
15  AppKit                              0x0000000191473d68 _DPSNextEvent + 660
16  AppKit                              0x0000000191c69808 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700
17  AppKit                              0x000000019146709c -[NSApplication run] + 476
18  AppKit                              0x000000019143e2e0 NSApplicationMain + 880
19  dyld                                0x000000018d7ae0e0 start + 2360

Sent to support@sweetpproductions.com.

Thanks a lot for having a look at it.

Seems that after a bad mistake from my side (switching from app window to Safari extension icon while still having a domain name open for renaming in app) the app crashes immediately (while Safari extension icon keeps running) even after re-start (Safari and macOS) and even after re-installation of the app from App Store (whereas all marked domains still are active in Safari extension icon, whithout having iCloud synch active). — Very strange!

Sorry, can't try this. I'm using Mac AppStore versions only.

Currently, as a workaround, I just

• disabled iCloud synch for all Cookie app versions (5-7) on all devices,
• reinstalled the App
• imported B/W lists
• and set up all favorites manually.

So the app is running fine (without) iCloud synch, until the problem is solved.

Also, it feels a bit like getting an idea of how it came to thist trouble and where to locate it. Sadly, I'm just too tired to take the time for further explaination. Had a heavy day. But I'll keep you on trac, when I can describe it a bit more detailed - either the problem or the solution, if appliable, or both.

Finally, it's not essential any more, since it workes fine w/o iCloud synch.

Thanks anyway for your great job!
K.

When I activate iCloud synchronisation in a new installation of Cookie 7, the app takes over one apparently damaged entry from iCloud.

I can neither deactivate nor delete this entry or show it in the finder. I can no longer mark the domain in question as a favourite. However, it is displayed as marked (blue cherkmark), but it does not behave like a favourite.

I unchecked iCloud synchronisation in all other installations of Cookie App on all of my other divices conected with my Apple-ID. There's only one instance of Cookie 6 (without iCloud synchronisation) left. Exports of favorites and balcklist/whitelist are done.

It's all about Safari only, no other broswers.

Purchase/Abo is active, too.

What can I doo to kill this bad entry?!

@Cookies4Lunch: I love DDG, can't live without it, but inside Safari and not as an alternative to Safari. I think Safari and macOS (OSX), completed by Cookie 6 and Minim Safari extension, is the most secure browsing environment at all. And DDG works smoothly and full-featured as a simple website inside Safari. So, to make a long story short: I think, there's no need to use DDG as a separate browser on macOS (OSX). Just take Safari, Cookie and Minim – and your'e on the safe side.

And yet another feature request (proposal):

What about using wildcards also to include an IP range, e.g. 192.168.1.* or something even more detailed (e.g. 1-10,12-19) for local devices/resources? Lot's of devices in LAN/WLAN or VPN use browser based controls that could be handled more differentiated thanks Minim.

Sometimes I forgot to reactivate Minim after having it paused. For this, it would be helpful if the toolbar icon would indicate whether Minim is active or paused. It's just comfort, I know. But sometimes it just helps to avoid mistakes, especially when you are tired.

Aha, I see. Sounds reasonable. Thanks for the quick reply.

Sorry for the stupid question:

What exactly is the effect of activating or deactivating the "SVG documents" option in the rules?

You have now activated "SVG documents" in the settings of Minim as a "first-party-rule" by default (in contrast to v4.x), which seems plausible to me, since SVG documents probably do not pose a higher risk or potential interference than any other XML-based files.

But even if you block SVG documents, SVG images (as before) are still displayed, as long as at least images are activated.

That's why I don't quite understand what exactly you can block or allow with this option "SVG documents" (which wouldn't already be allowed by "images")?

Great job! Thanks!

• ️ Seems to work fine.
• ️ Main app and browser extension both show clear and simple UIs.
• ️ In browser extension, the popup text of the help symbol (?) should be changed from "open Minim" to "open Help".
• ️ Maybe for non-power users a short hint would be helpful that after update to v5 all rules need to be activated first by checking the new checkbox at the beginning of the line. (Otherwise one could think that Minim is running as before although all rules are not yet activated.)
• ️ After all, the help text is really understandable and easy to read with it's optical structure. Great!

Minim could become one of the most powerful tools to enforce generally strict browsing security settings by enabling precise exceptions.

The decisive factor here is not how simple or complicated the definition of a one-time rule is, but whether this rule will have a universal effect, e.g. by using wildcards, placeholders, regex… Especially aggressive websites or scripts will excessively make use of changes in URL structure and naming, just to block content blocker. So the more sophisticated the rules can be defined, the more universal it may work.

Whatever syntax you will use, it should be documented just "one click away" in a short overview, maybe with an additional help text incl. some examples below or beside. There won't be any confusion, if there's a clear explanation available. (The exact wording of a respective help text could be fine-tuned later, if necessary. And a reference to Minim's support forum could collect questions or feedback from users.)

If the syntax and behaviour of existing rules would change with a new version of Minim, there could be an issue with migration of old rules to a new syntax. So maybe it needs a warning or backup of existing rules or even a migration script. (Maybe later?)

Anyway, I'd prefer an automated iCloud backup (and/or local backup) of all changes to the exception list to remove changes step-by-step more easily. (Manual exports usually follow Murphy's law: outdated or not existing when you need it.)

@SweetP said in Wildcard Syntax:

Perhaps I should just accept regex…

I had an issue with one user who needed an exception for all those subdomains of podbean.com that start with letter "s" followed by a three-digit number, but no other subdomains, i.e.:

s###.podbean.com

I didn't even dream of Minim being so sophisticated one day that it could handle even such issues. But hey, maybe this day will come? Would be so GREAT!

Great job, as always. Thanks!

Does

*domain.com

affect to

my.domain.com

and also

mydomain.com

?

In other words: how to apply a wildcard to real subdomains only, instead of applying it to all other domains with a respective prefix within the domain name? Wouldn't it be more precise to accept a dot between the wildcard and the respective domain name, e.g.:

*.domain.com

What exactly is the meaning/behaviour of the first checkbox (something like "apply standard blocking rules to all domains" in English) at the General tab in Minim's settings?

Does it affect the rules/behaviour of listed (sub)domains or the application of rules to their secondary (i.e. third party) links?

Just want to understand, step by step, the general changes in behaviour after latest updates to 4.1.0~4.1.3, which appears to be a bit confusing to me.