Support start_url property in safe app manifest.json

[mmv08]

trafficstars

What is this feature about? (1 sentence)

Support start_url property in the safe app manifest.json https://developer.mozilla.org/en-US/docs/Web/Manifest/start_url

Why is it needed? What is the value? For whom do we build it?

1. Some developers want to trigger custom behavior when their app is loaded as a safe app, also analytics. This can be achieved with the start_url property.
2. Somewhat related to https://github.com/gnosis/safe-react/issues/2403 Because we currently fetch the manifest relatively to app URL, there were apps that are hosted at url.com/app, but the manifest is hosted at url.com. In the end, we had to add url.com as a safe app and then users would have to navigate to the app themselves.

High-level overview of the feature

The following manifest:

{
  "name": "Drain Account",
  "description": "Transfer all your assets in batch",
  "iconPath": "logo.svg",
  "start_url": "/app?loaded_as_safe_ap=1",
}

Should open the app at <app_url>.com/app?loaded_as_safe_ap=1

High level motivation

Currently our manifest.json logic is not the same as the common manifest.json logic for web apps (or PWAs). Therefore we cannot take advantage of the existing manifest.json files in most apps without additional changes to it. By complying to the standard it will be possible to use existing apps as Safe apps without additional migration steps (at least in many cases).

[rmeissner]

Would the start_url relative or absolute (or both). I can remember that we discussed security considerations where an absolute start_url would allow you to navigate away from the app.

Also in this case it might actually be problematic to comply to the standard. The start_url should point to the entry point of a PWA. This might conflict with the use case to point to the entry point for a Safe App.

[mmv08]

According to the spec it should be relative: https://www.w3.org/TR/appmanifest/#start_url-member

If start URL is not same origin as document URL, return.

[rmeissner]

That depends on what documentation you look at, right? According to the one linked in the description there is no such limitation. I would make it explicit on the description how we want to support this.