Using insecure transports threatens the integrity of the content displayed to the user: even if the video and the TTML file are both delivered over HTTPS, loading a font over HTTP could lead to corruption or insertion of a misleading translation of the content. This would presumably also apply to image captions and subtitles loaded from external resources.
We should note secure transport as a security and privacy issue in TTML 2 and TTML 2 (2nd Edition) and reference that from IMSC 1.2. That change could be: 1) requiring secure transport; 2) prohibiting mixed content; or 3) non-normatively noting the risks to confidentiality and integrity.
It would be a good practice to use HTTPS as the scheme in examples throughout the specs.
Using insecure transports threatens the integrity of the content displayed to the user: even if the video and the TTML file are both delivered over HTTPS, loading a font over HTTP could lead to corruption or insertion of a misleading translation of the content. This would presumably also apply to image captions and subtitles loaded from external resources.
We should note secure transport as a security and privacy issue in TTML 2 and TTML 2 (2nd Edition) and reference that from IMSC 1.2. That change could be: 1) requiring secure transport; 2) prohibiting mixed content; or 3) non-normatively noting the risks to confidentiality and integrity.
It would be a good practice to use HTTPS as the scheme in examples throughout the specs.
From email: https://lists.w3.org/Archives/Public/public-privacy/2020JanMar/0055.html Issue noted while reviewing IMSC 1.2 for privacy and security, as raised in PING.