Skip to end of metadata
Go to start of metadata


The basis of an accountability application is the ability to see what the user does: what web page do they open, what pictures are they fetching in their app, etc. A generic way of doing this would be to intercept the network traffic. A more specific way would be to reply on a browser plug-in. This page describes the the alternatives that are known to us, with their pros and cons.

Implementation alternatives

Below, a graphical representation of the various alternatives is given. Below the picture, you find a short description.

We see four options:

  • Use a custom browser
    The benefit is that the browser has access to all sites, whether using HTTPS or not. There are major drawbacks however: forcing the user to use the custom browser is a severe limitation in usability (the users cannot select their favorite browser, they cannot leverage features like bookmark sync and (on iOS) the cannot directly open links in e-mail anymore, as that would lead to Safari, which is to be disabled in favor of the custom browser). A custom browser is obviously unable to track what happens in native apps.
  • Use VPN
    It's possible to transparently set up a VPN connection to an Accountability cloud backend. With that, it is possible to intercept all network traffic, both originating from browsers and from apps. HTTPS traffic can be intercepted through a man-in-the-middle approach, where the customers trust a certificate provided with the Accountability application.
  • Intercept the network traffic on the device
    This is the favorite option, but to the best of our knowledge, this is impossible on iOS and difficult, if at all possible, on Android. The idea here is that the device allows setting up an interception hook in the HTTP stack, allowing applications like accountability, parental control and governance to see the HTTP request. If this is possible on the level where the HTTPS traffic is not encrypted yet/anymore, then it's an ideal solution allowing us to track everything, both for apps and regular browser usage. If it's possible for regular HTTP traffic but not for HTTPS, it's a major reduction in usefulness, making this alternative comparable to VPN.
  • Intercepting user input through accessibility framework in the device
    Mobile devices have an accessibility framework which can be used to intercept the input that users enter in browsers. This option supports all apps that support the accessibility framework. Most browsers support this.  

Preferred alternative

There are two solution alternatives that fulfill all requirements: "Device-level network interception" and "VPN with HTTPS support through Yona certificate". The Device-level network interception alternative is good in theory, but we are not aware of any practical possibility do implement this. Because of that, the alternative "VPN with HTTPS support through Yona certificate" is the only real option.

This approach is detailed out on the page Intercepting HTTPS traffic.

  • No labels