We’re wondering about whether we can be approved for auto-connection to allow Recollectr to communicate with Google Chrome via its Native Messaging Hosts feature (and later we’ll request the same for Firefox when we support it.)
The rationale for this is that it allows us to piggy-back off of the browser’s notification system, which integrates seamlessly in the OS notification management panels of some distros.
The plug configuration we would need to enable that functionality looks like this:
We’ve been using this system for notifications for a few years now and it works great. Our built-in notification system is pretty clunky in comparison, so it seemed like it was time to make this request and get the Snap Store version of our app fully up to speed.
Would it make more sense in this case to use system-files as in the second case above since this is perhaps clearer overall what the result is to a user (possible sandbox escape), and would be more in-line with how this has been done historically for other snaps?
Thanks for your reply @alexmurray and sorry for the delayed reply! The concern about sandbox escape via the terminal command/batch file the browser will invoke makes sense.
Can you provide any clarity on the distinction between personal-files and system-files in this case? Is the idea only to better inform the user of the possible implications, or is there some additional rationale?
Can you clarify also, if we pursued this and went through the publisher vetting - the app would still be in strict confinement, correct? It’s just the publisher vetting level you’re discussing, not the actual containment level - ie, the user wouldn’t need to specify --classic to install it?
@alexmurray please correct me if I misunderstood your suggestion, but the explanation can be found here. In that case system-files is prefered since the snap is built with an interface hook, and hooks run once system wide.
Sure, your snap will still be kept under strict confinement. Publisher vetting is required due to the sensitiveness of this grant. Since this could allow sandbox escape (even under strict confinement), the user/ecosystem would have to trust the snap (and the publisher behind it) to behave rather than the sandbox. The linked post explains this as well.
Hey @emitorino and @alexmurray thanks for clarity! We just moved offices so some things have been on the back burner. Sorry for dropping the ball here and thanks @emitorino for your patience and pings!
We plan to try the system-files approach, but need to re-review all the info you’ve helpfully shared here since it’s been a couple weeks now.
Regarding publisher vetting, how do we kick-off that process? Do we need to first request system-files in our snap to begin that?
Yes if you could please request system-files in the snap then we can help ensure this declaration is done correctly and once complete we can look at voting / vetting etc to grant this access to the snap.
Apologies for the extended delay on this. Moving offices has been an ongoing fiasco.
We just pushed version 3.15.105 on the candidate track, including the system-files plug request. Apologies again for the extraordinary spottiness of our replies this past month and thanks @alexmurray for the ping.
@Recollectr - thanks but I still don’t see any mention of system-files there - can you please double check? Or alternately, can you post here what the system-files declaration is that you are using?
Also since I expect you would want this for firefox as well, based on the declaration which was used by jabref for similar purposes, I suggest perhaps the following or similar to allow you to support the various major browsers:
Ah jeez. So we passed a configuration to Electron Builder, and that’s what I checked, but indeed the output file, builder-effective-config.yaml, doesn’t include any reference to system-files, so I’m going to need to do some investigating there.
The JSON we’re passing for the builder-configuration looks like below, which we can tighten up to the specific JSON file:
And thanks very much for sharing the list of paths for major browsers, that’s a big help and supporting additional browsers is definitely on our todo list.
As an aside, I’m curious why the preference is to install the native messaging interface for all users though? I’m guessing this is something specific to Snap architecture? Because the default path is the per-user one.
Thanks again for all your help with this. It might be a couple days before I figure out what’s going wrong here.
I assume the main reason is then it only has to be done once when the snap is installed (this can be done via the install hook for instance) - and can be cleaned up easily when the snap is removed (via the remove hook).
