Enforcing web platform security features #235
Labels
discussion: cost-benefit tags
all aspects of the priorities sections and cost-benefit tags
section: map viewer
Capabilities & use cases for declarative map viewer widgets
status: suggestion
this issue discusses a suggested addition to the report, that is not yet in the draft
Security features could be more easily enforced by authors in regards to maps/map data in a native implementation.
It'd be great if we could mention such features perhaps with a label of "Privacy/Security: potential improvement" in the conclusion of the Capability: Embed an interactive map viewer, using HTML markup(?).
Here are three examples of security features to showcase how developers may benefit (and in turn improve security/privacy for the end-user, as these measurements would be easier to apply) in a native implementation:
Content Security Policy
The groups' custom map component requires a rather lengthy ("strict" host-based) Content Security Policy:
(and Leaflet users have expressed some dissatisfaction with the CSP modifications needed to embed their maps.)
whereas in a native implementation perhaps only one directive could be sufficient (e.g.
layer-src
):Referrer Policy
It'd be ideal if a lax
Referrer-Policy
of HTML documents isn't inherited into map/tile resources, as is the case for stylesheets: https://www.w3.org/TR/referrer-policy/#integration-with-cssHTML Sanitization (draft specs)
Interoperability with Trusted Types/HTML Sanitizer API? I.e. I think this could mean less custom configuration required from developers to embed maps.
For the capability's conclusion section I hope we can at least briefly mention/list all or some of the above security features.
The text was updated successfully, but these errors were encountered: