Permissions reference

Everything is denied by default. A widget declares what it needs in the manifest's permissions object, and the user consents at install time, permission by permission. Three rules shape the system:

• Consent can only narrow. What the user granted is intersected with the manifest; nothing can escalate past what the manifest declared, and the user may grant less.
• Updates re-prompt only for additions. An update that adds a permission asks again; removals apply silently.
• Ask for what you use. Every grant is shown to the user in plain language (the wording below). A widget requesting more than it visibly needs reads as suspicious in review and to users.

The permissions

The wording in the second column is exactly what the marketplace shows the user at install time.

The scoped grants

http and links are objects, not booleans, and their scope is part of the consent.

http

"permissions": { "http": { "hosts": ["api.open-meteo.com"], "rateLimit": 60 } }

• hosts: exact hostnames the widget may fetch through dd.http.fetch. Shown to the user as: "Talks to the internet, only to:" followed by the list. No wildcards; every hop of a redirect is re-checked.
• rateLimit: requests per minute, optional. Omitted means the host default of 30; values are clamped to 120. Never shown at install.

links

"permissions": { "links": { "prefixes": ["steam://run/"] } }

• prefixes: URL prefixes dd.links.open may launch, each a full scheme://... string. Shown to the user as: "Can open these link types on your PC:" followed by the list. Empty means no access, and dangerous schemes are refused at call time no matter what a manifest declares.

Read and control pairs

Two capabilities are split so that reading never implies acting:

• system reads vitals; systemControls changes volume, the microphone, the radios, Wi-Fi, the sound device, per-app volume, Bluetooth connections and brightness, and opens settings panels. The lists that name your apps, devices and displays are systemControls reads too. Controls without system are useless.
• media reads now-playing; mediaControls drives playback.

power is deliberately its own permission rather than part of systemControls: granting a volume slider is not granting the ability to turn the machine off.

Version floors

Some permissions did not exist in the earliest app releases, and others gained methods later. You do not declare anything for this: the store stamps every new version's minAppVersion from the release that last changed each permission it requests (see the feature floor). The entries above the oldest supported app, today:

Consent-bearing settings

Four setting types are part of the permission story: filePath (which file or folder), secretRef (which credential), instances (which other widgets), and url (which web address a feed comes from). Their manifest defaults are always ignored; only what the user actively picked counts. See the manifest reference. Bar widgets cannot declare these fields at all: the manifest refuses them, see Bar.

One API rides this model with no grant of its own: dd.image.load returns the image the user picked in a filePath setting as a data: URL. The picked file IS the consent; the method can read nothing else, and only sniffed image bytes with an 8 MB cap ever cross the bridge.

For the containment model behind all of this, see How the sandbox works.