External resources should be loaded securely

[npdoty]

External resources should be loaded securely, for example over HTTPS. Otherwise, threats would also include any network attacker when the book is being read (even separate from whether the book contents itself were securely transferred). This is currently a non-normative recommendation, but seems like a good candidate for a normative recommendation.

Network attackers are not currently described in the threat model of either the core or rs specs.

[iherman]

The issue was discussed in a meeting on 2022-05-26

List of resolutions:

• Resolution No. 2: Approve PR 2299, close issue 2265.

View the transcript

1.2. External Resources should be loaded securely.

See github issue epub-specs#2263.

See github pull request epub-specs#2299.

Dave Cramer: this issue comes with this PR.
… this is around remote resources, and recommended that they be served over HTTPS.
… avoiding person in the middle and other such network attacks.

Dan Lazin: my only concern is the PR itself is not super clear in its language.
… "RS may not load resources".
… what we mean is there is a chance RS may not load.
… I'll do a pass.

Dave Cramer: this is SHOULD level, so would we test whether a remote resource is served via HTTP, and that would result in a warning from epubcheck?.

Matt Garrish: yes, that is what I would expect.

Dave Cramer: this could affect existing content, but I expect it would be rare.

Matt Garrish: generally the direction of the web is HTTPS too.
… this will cause some warnings, but security outweighs. We should move in the direction of the web.

Dave Cramer: using backwards compatibility as reason not to fix security issue isn't where we want to be.

Proposed resolution: Approve PR 2299, close issue 2265. (Wendy Reid)

Brady Duga: +1.

Wendy Reid: +1.

Shinya Takami (高見真也): +1.

Matthew Chan: +1.

Masakazu Kitahara: +1.

Dan Lazin: +1.

Dave Cramer: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Resolution #2: Approve PR 2299, close issue 2265.