Request for auto-connection for Recollectr

Hello Snapcraft Team!

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:

'personal-files': {
   read: ['$HOME/.config/google-chrome/NativeMessagingHosts'],
   write: ['$HOME/.config/google-chrome/NativeMessagingHosts'],

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.

The Chrome extension that we’d be communicating with can be found here:

Happy to answer any questions, and thanks for reading!

This request is similar to ones we have had in the past - e.g Allow classic confinement for postman-agent and System-files under .mozilla/native-messaging-hosts . As such, access to native messaging allows snaps to escape confinement and so is akin to classic confinement.

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?

Also in either case we would want to perform publisher vetting as is done for Process for reviewing classic confinement snaps due to the security implications of such a request.

1 Like

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?

Thanks again!

Hey @Recollectr!

@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.

1 Like

@Recollectr please let us know whenever you update your snap declaration so we can proceed with the process. Thanks!

Yes, the idea is to install this system-wide via system-files rather than on a per-user basis via personal-files.


@Recollectr ping, could you try the system-files approach?

1 Like

@Recollectr ping, this request cannot proceed without the requested information.

1 Like

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?

Thank you again for your help and patience!

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.

Ping @Recollectr - can you please update your snap as requested above?

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 the snap yaml for revision 24 (ie. 3.15.105) doesn’t appear to contain any system-files references - are you sure this has been updated?

1 Like

@alexmurray thanks for letting me know and sorry about that! Looks like we had an error in the logic to merge build-related config files.

We just pushed 3.15.106 (rev 25) to the candidate track and I’ve confirmed that the config we provided to the builder script is correct now.

@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:

    interface: system-files
    - /etc/chromium/native-messaging-hosts/recollectr.json
    interface: system-files
    - /etc/opt/chrome/native-messaging-hosts/recollectr.json
    interface: system-files
    - /etc/opt/edge/native-messaging-hosts/recollectr.json
    interface: system-files
    - /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/recollectr.json

In this case, +1 from me for use of, but not auto-connect for these system-files instances, provided publisher vetting is completed.

1 Like

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:

"plugs": {
    "system-files": {
     "write": ["/etc/chromium/native-messaging-hosts/"]

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.

Whoops, silly mistake here. The configuration takes an array of objects, not an object.

Building and pushing a new version now, 3.15.107 / should be rev26.

Okay, successfully pushed and awaiting manual review!

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).

1 Like

@Igor could you please perform publisher vetting as requested? Thanks!

1 Like