Sparkle
Sparkle copied to clipboard
sparkle-project
Announce: Little Snitch Internet Access Policy
Not an issue, but I know that several of us use Little Snitch personally, and the latest version includes developer ability to include an Internet Access Policy in our app bundles that might make things easier to interact with our users using our apps with Sparkle.
Here's their developer documentation on the subject.
I'm not really reporting any proposed action at this time, but given how popular both Sparkle and Little Snitch are, I thought I'd give the heads up.
Thanks @balthisar for bringing this up. I’m one of the developers of Little Snitch and if anyone has any questions regarding the Internet Access Policy, I’m happy to answer them.
As to the issue at hand, I can imagine that the Sparkle project could include a template InternetAccessPolicy.plist file that developers can use as a starting point, as well as the localized strings that go along with it.
If this is desired, I can write up the necessary files and documentation about what developers who adopt the Internet Access Policy need to do.
@marcomasser For the ui-separation-and-xpc branch where access to the internet is done through a separate XPC process, where should InternetAccessPolicy.plist go?
The InternetAccessPolicy.plist always goes into the app.
Little Snitch uses the concept of “via connections”. For example, if you use ping in Terminal.app, Little Snitch will show a connection alert for “Terminal via ping”. The same is true for XPC processes, i.e. you could see a connection alert for “My App via NetworkService.xpc”.
Note that Little Snitch by default does not show the XPC helper (the above example shows as just “My App”) because that’s considered part of the app. To show XPC helpers, open Little Snitch Configuration > Preferences > Monitor > Show Helper XPC Processes.
A template for developers is another step in our already-too-long integration guide, so I'd rather avoid it. I'd prefer to add the template to Sparkle itself to automagically improve things for all Sparkle-using apps.
Would you be able to search Sparkle.framework for the policy file?
@marcomasser Also is there a way to customize the policy at run time?
Sparkle has an option to send system profile with the update request. We could disclose that when the option is enabled, but we need to read host app's info.plist first.
I think the message describing what gets sent is not the only thing that needs to be changed in order to avoid another integration step. The domain hosting the rss feed (provided to Sparkle by the app Info.plist or through APIs at runtime) as well as the domain hosting the downloaded file (determined by Sparkle from the feed itself) would also require the policy to be set at runtime.
@pornel: I see your point. More work to integrate Sparkle is not desirable. Automatic support for an IAP on the other hand, sounds very interesting.
Currently, there’s no way to customize the IAP at runtime.
We could search Sparkle.framwork, but the problem with bundling an IAP with an embedded framework is that Little Snitch doesn’t know why an app establishes a connection. It could be the app itself, or it could be the Sparkle Framework, but there’s no way to know about this from the outside. I’m reluctant to automatically showing an IAP for every request into the domain where the RSS feed is hosted because that’s very likely the same domain that hosts other things the app connects for.
We could then end up in a place where Little Snitch tells the user “App XYZ is connecting to example.com to check for software updates”, but in reality the app connects there because it loads something else entirely. And if developers didn't have to do anything to get an IAP in their apps, they wouldn’t even know about this.
@michelf: Your question already hinted to a solution to this. If Sparkle used an XPC process to handle its network requests, it would be safe to assume that the only connections that process establishes would be for software update checks and downloads of the software update itself. As I wrote before, the IAP currently must reside in the app itself. If we supported it in XPC bundles as well, automatic support for an IAP by Sparkle is almost done. Is the separation into an XPC service something that is planned for all users of Sparkle? What is the timeframe for that feature?
@pornel: Is the SUEnableSystemProfiling only ever set in the app’s Info.plist? Or can this be overridden e.g. by NSUserDefaults? If so, we’d have to read the app’s preferences, too.
If auto-IAP can only be supported for the XPC helper, I think that's fine. It'll be a motivator for us to finally switch to the new architecture :)
We’re very hesitant to add any runtime component to the IAP to make sure that whatever information is in the InternetAccessPolicy.plist file on disk is what is presented to the user. Little Snitch checks the code signature of that file and anything that gets dynamically inserted in user-facing strings at runtime is an attack vector that we would rather not have to deal with.
This would mean that any customization of the IAP would not be done at runtime, but at build time by the developer. If they don’t customize anything, Sparkle would contain a generic text that just informed the user that a software update check is being performed.
I would propose that I discuss with my team support for bundling an IAP with XPC services to Little Snitch (probably with a fallback to the enclosing app’s IAP, if the XPC doesn’t contain one). When that is done and implemented, someone (a Sparkle contributor or myself) could add the necessary files and documentation to Sparkle itself.
Then we’ll see if that is motivation enough to switch to the XPC branch 😉
Sparkle doesn't know feed and download URLs ahead of time. So I presume you'd show any connection from the XPC helper as auto-update activity?
Most or many applications that use Sparkle (including sandboxed ones) do not use the downloader XPC service that Sparkle.framework embeds.
Because of the mentioned "runtime component" I think the only path here would be adding an optional article to integration with Little Snitch either on Sparkle's documentation or in Little snitch's documentation (and I agree Little Snitch should not add a runtime component). I think this works out better because I'm also a bit hesitant to integrate something that isn't integrated into the OS and isn't massively popular.
For Sparkle's end, this would be a an issue for the website repo rather than here.
Thanks for the update. I’m not working on Little Snitch anymore, but I will ping my former colleagues about this update.