Request for Proposals: GNOME Desktop-Wide Web/Network Filtering Solution

[ramcq (Robert McQueen)]

As part of the Digital Wellbeing / Parental Controls work funded by Endless, the GNOME Foundation is seeking proposals from qualified contractors or teams to design and implement a comprehensive desktop-wide web/network filtering solution for the GNOME desktop.

Project Overview

The proposed solution should address the following key objectives:

1. Avoid tracking and advertising
2. Manage distractions on a time basis
3. Filter undesirable content from a wellbeing perspective (e.g., avoiding gambling or other addictive/triggering content)
4. Allow enforced settings to filter undesirable sites, or only allow access to specifically approved sites, through GNOME’s existing Parental Controls framework

Required Experience and Knowledge

Candidates should demonstrate expertise in:

• Gtk/Adwaita user interfaces
• GNOME technology stack (D-Bus, Control Center, Settings, etc.)
• Networking layer (e.g., iptables, systemd-resolved)
• Containerized applications (e.g., network namespaces, BPF, Flatpak and Snap)

Technical Approach

We believe that working at the DNS level provides a pragmatic approach to offering a comprehensive implementation, to account for all browsers and applications that users can use to access network content. We can draw on technology and/or community-maintained site lists from projects such as Pi-hole, and implement at the desktop or system level so that the filtering is available to users on any network or with any application. It may also be necessary to consider when any network-level sandboxing or filtering is also needed to ensure the proper functioning of the filtering.

The successful candidate(s) will be expected to:

1. Design technical approaches in collaboration with relevant upstream projects
2. Implement according to the agreed technical approaches and designs from the GNOME Design Team
3. Submit implementations upstream
4. Allow for time within the project scope to respond to and incorporate upstream review feedback

Budget

Available budget: $26,000

Individual hourly rates are not to exceed $55 USD per hour without prior agreement with the Foundation.

Eligibility

We welcome applications from:

• Individuals
• Teams
• Consultancies active in the GNOME and wider Linux desktop community

We strongly encourage candidates from diverse and underrepresented backgrounds, as well as those who are not already employed full-time in this space.

Application Requirements

Please submit your application including:

1. An introduction to yourself and/or your team
2. Details of your relevant previous work in this domain
3. A breakdown of your proposed work in packages, including:
   • Estimated time for each work package
   • Estimated cost for each work package

Partial applications are also welcome, which propose to implement a necessary part of the system, and we may choose to appoint multiple such contractors to build the complete architecture. e.g. I will implement this filtering in systemd-resolved together with this new Flatpak feature to ensure all DNS traffic is handled by systemd-resolved, but I will not do the policy or UI work.

Additional Support

Support will be provided by the GNOME Foundation and GNOME Design Team throughout the project. The existing team working on Digital Wellbeing, Philip Withnall and Sam Hewitt, can advise on technical and design requirements and how to integrate with the existing work on screen and app time limits.

Submission Instructions

For more information or if you have any queries to prepare your submission, please post here on Discourse or join #digital-wellbeing:gnome.org to discuss with the team.

Proposals must be submitted to wellbeing@gnome.org by the end of Wednesday 18th December.

[mcatanzaro (Michael Catanzaro)]

The NetworkManager and GNOME architecture for DNS configuration is already going to need significant changes to support secure DNS, which currently nobody is working on. Some of the challenges there will be shared with this project; e.g. currently DNS configuration is per-network, but to do DNS-level filtering we’ll certainly need to change NetworkManager to make it global.

[ramcq (Robert McQueen)]

I think secure DNS is kind of… orthogonal isn’t it? If anything if you’re trying to (voluntarily, or intentionally) interpose your own software in the DNS pathway, it’s kind of unhelpful.

In Endless OS’ very rudimentary “safe defaults” settings which enable Cisco OpenDNS on a system wide basis (which you can find at eos-theme/safe-defaults at master · endlessm/eos-theme · GitHub) we drop in a Chromium policy to enable a mode which tries to use the OpenDNS DoH server but permits fallback to the system-provided resolver. Network Manager is directed to use dnsmasq and we use that as the point to configure a global resolver in preference to the network-provided ones.

It works pretty well except when it really doesn’t, because some networks, particularly cell/mobile broadband operators mess with DNS traffic to external resolvers, so if DoH and dnsmasq fail, it eventually fails open to avoid breaking the system’s networking. An on-system resolver wouldn’t have this problem as its upstream servers could be the normal network-provided ones.

You can also see the heinous downsides of using a third party system to do DNS filtering which is we also need to enable a CA so that we trust the https “this is blocked” page. Much much much MUCH better to… not do this. Or if you did need to add a snakeoil cert, it could perhaps be generated, served and trusted locally?

A simple/naive implementation might be to direct NetworkManager to literally FTL which is Pi-Hole’s dnsmasq fork which implements filters. However I think we can do better considering we have a number of approaches (filesystem/network namespaces) that might allow us to influence/restrict resolver configurations within a namespace, maybe on a per-session or even per-app basis, and not need to mess with the system resolver at all which I’m sure is better from a DNSSEC and other perspectives.

That’s kind of the point of the RFQ. There are certainly people who know more about this than me and I’m sure there are multiple ways to trade-off between technical complexity/feasibility and how comprehensive the approach can be.

[mcatanzaro (Michael Catanzaro)]

So I originally wrote a long essay that was actually entirely irrelevant, because I didn’t read past your first paragraph until after I finished typing it. Oops. Deleted.

I guess you could implement a filtering resolver locally that would work regardless of the network’s DNS server, and place the new local resolver between systemd-resolved and your network’s DNS server. Sounds like that’s your plan? It seems rather heavy, but yes it’s certainly doable without rearchitecting how NetworkManager and GNOME handle DNS configuration.

[ramcq (Robert McQueen)]

That’s a way to do it. Sure. Not the only way! Maybe systemd-resolved could be taught how to filter, and/or be taught how to manifest different horizons in different namespaces? Could you run resolved in a user session? I don’t know that’s why I am asking for proposals.

[Sid]

1. I think we should pin this topic for a few days, as proposal deadline is 18th December.

2. We should also create a topic for

   Request for Proposals: Flathub Program Management - Announcements - Flathub Discourse

   in GNOME Discourse with a link to original content in https://discourse.flathub.org and close the topic here, to encourage discussions in Flathub Discourse. Also we should pin this topic, as proposal deadline is 18th December.