Restricted access to scary paths should be normative

[cynthia]

In response to: w3ctag/design-reviews#390

https://github.com/WICG/native-file-system/blob/master/security-privacy-questionnaire.md#27-does-this-specification-allow-an-origin-access-to-sensors-on-a-users-device

Suggests "no, /dev is off limits", but it feels like we should have some normative text to align behavior across limitations.

(e.g. "Please select your home directory", which a lot of Mac App Store apps do is even scary territory)

[lknik]

I'm also very interested in that (as In: #73). /dev and other dangerous paths (/proc? /sys?) should be explicitly out of scope. That said, we can assume that many files in /home are also pretty sensitive, but since it is easy to blacklist some big risk areas, that would be a reasonable default.

[mkruisselbrink]

I disagree that the spec should normatively require certain paths to be off limits. The spec can/should certainly document when/where checks should be done, and what should be done when a off-limits directory is selected, but the exact list of off limits directories really should be up to the individual implementations. For example I can imagine implementations to have different/less limitations when a particularly strong trust relationship exists.