Enforcing web platform security features

[Malvoz]

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:

  Content-Security-Policy: default-src 'self';
                         connect-src 'self' geogratis.gc.ca;
                         img-src 'self' geoappext.nrcan.gc.ca data:;
                         style-src 'self' 'sha256-P4nvk0+qiIx5/zAz4EEwcyUE3w/JYhx1p6AynA4FauI='
                                          'sha256-eo5LoOQ6vGE1TgplgVKmRN6i3TkRxeOJ5YVVeFUBevc='
                                          'sha256-gWLDNLsycvRcRqEScFHdCYPrg1OzxzQBXX7qYFP1Ww0='

  (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):

  Content-Security-Policy: default-src 'self';
                         layer-src geogratis.gc.ca

• 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-css

• HTML 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.