HTTPS
farski opened this issue · comments
I would be in favor of being very opinionated on HTTPS. I would require feeds being available over HTTPS. Media seems like a trickier thing to absolutely require, but I would lean towards that as well.
worth noting that many social sharing platforms require delivery via https
👍 for requiring it
One tricky part of this is that it's very uncommon for a feed to change based on how it is accessed. Assuming that the requirement is that a feed is available over HTTPS and not only available over HTTPS, that means any given feed would still be available insecurely. It's not likely that the insecure version would switch to using insecure media file URL's, which essentially means if someone is adopting the HTTPS requirement, and they still over an insecure version of the feed, all of the media would still be HTTPS-only. I've never seen anyone do schemeless URL's in a feed; does anyone have a sense of how http libraries would handle that? It may not even matter.
I've never seen anyone do schemeless URL's in a feed; does anyone have a sense of how http libraries would handle that?
It's called a "protocol-relative URL", but it's considered an anti-pattern when HTTPS is available. When HTTP URLs are used, the recommendation is for CDNs to redirect them to HTTPS.
It looks like protocol-relative URLs are not supported in popular networking libraries[1], in which case applications would have to convert them to valid URLs before passing them along.
That's what I figured. I think it be good to strongly recommend HTTPS support for all request that a client would be expected to make in an early spec, and note that in a later spec it will be a requirement. Part of me also thinks it might be okay to make requirements that we know people will fail for a while, especially when there will be exterior motivators, which is the case with HTTPS.
One option we do have is to encourage clients to disable new features on feeds that do not support HTTPS.
I'm also for being opinionated re: HTTPS. That said, there are existing standards for upgrading insecure HTTP requests to HTTPS when the client supports it. I would propose that HTTP be allowed, but that it's strongly encouraged to use the aforementioned standard to upgrade those requests to HTTPS.
The move to HTTPS is inevitable and the only real holdback these days is the iTunes Podcast Directory with its confusing and unnecessarily limited list of CAs they currently support. See the HTTPS section my post about the most recent release of Podlove Publisher: https://podlove.org/2016/12/05/podlove-publisher-2-4/.
I do not think we should assume anything about HTTP and HTTPS for feeds as HTTP will be around for a while and HTTPS adoption will take may years even if we see a huge acceleration in this field. Apart from setting up websites properly with certificates, moving existing WordPress and other CMS sites to be able to reliably deliver all assets (images etc.) via HTTPS will take extra efforts.
However, HTTPS should be recommended and even required for PRIVATE feeds (see #45).
@timpritlove now that this has happened: https://feed.press/blog/2016/12/16/apple-silently-adds-support-lets-encrypt-certificates-podcast-feeds/ are we comfortable saying that having an HTTPS version available is required for full SynMed compliance?
This is a 2-way street, and clients and feeds both need to be on board. What do clients need to do? Is it as simple as requiring that they support upgrade-insecure-requests?
@ziggythehamster this seems to be mostly designed for linked resources and doesn't cover the initial redirect, which is hard to recommend doing while itunes support is still in such a weird place. Do we think it's worth coming up with a recommendation (like using a <link rel="alternate" href="https://..." />) for feeds to enable HTTPS?
are we comfortable saying that having an HTTPS version available is required for full SynMed compliance?
I'm not. I recommend against an HTTPS requirement for a few reasons:
-
The specification should be transport-layer agnostic. Yes, HTTP is most commonly used to deliver feeds and media at the moment. In 5 years, most feeds and media will be delivered using HTTPS and HTTP/2. In a decade, HTTP/3 and/or P2P protocols may be widely used.
-
It's unnecessary. The world is moving to HTTPS and HTTP/2 regardless of what our merry band of awesomeness does. 🙂 Google is rewarding it via SEO, Apple is adding resistance with things like App Transport Security (ATS), etc.
-
It's out of our control. As Google notes, "Several technical and political challenges stand in the way of attaining full traffic encryption. […] Certain countries and organizations block or otherwise degrade HTTPS traffic." If Google can't mandate it yet, neither can we.
-
Scope-creep is the #1 cause of stillborn specifications. Anything we can do to omit inessential requirements without clear and unique benefits helps the odds that people will pay attention to this specification.
@CharlesWiltgen Good points, but a few thoughts. We're definitely not getting into the weeds of transport layer issues with this topic. It may be true that some day it's worth considering how feeds would operate outside of web technologies, but for now it's realistic to assume that keeping everyone on the same page means using HTTP (whether that's 1.1 or 2 or whatever, it kind of doesn't matter; we haven't seen any fracturing of the web because of the introduction of HTTP/2. It's always been supported in addition to 1.1). I don't think we'll be making any recommendations about TCP or other transport protocols any time soon.
If we were to stay so agnostic as to not even put HTTP in the spec, that would mean someone could offer their feeds only via FTP and be compliant. Which means that now every app has to support every protocol out there to say they are also compliant. That's impractical. We know that, for now, podcasting is built on web technology, I don't think we need to shy away from stating that.
Also I think this recommendation does come with clear benefits. There are, today, podcasting platforms out there which will only accept HTTPS feeds. If we make a requirement that feeds are available via HTTPS (but not only via HTTPS), our spec is now compatible with existing and in-use specs. I think it's a slippery slope to publish the "one spec to rule them all", have someone follow it to the T, and then find out their feed isn't compatible with some systems. (e.g. "Hey NPR One, here's my 100% synmed compliant feed, please put me in your app" "sorry, your feed isn't up to our very basic specs").
If we were to stay so agnostic as to not even put HTTP in the spec, that would mean someone could offer their feeds only via FTP and be compliant.
In theory, yes—RSS 2.0 supports any IANA-registered URI scheme just as HTML does. In practice, this has never been and will never be a problem.
"Small pieces, loosely joined" is why the web works, and the clean division between formats and network protocols is important. It's why HTML email (i.e. HTML over SMTP) exists, why we can "move the web forward" to HTTP/2, etc.
Which means that now every app has to support every protocol out there to say they are also compliant.
A misunderstanding. The RSS spec notes, "Aggregators may have limits on the URI schemes they support. Content developers should not assume that all aggregators support all schemes."
So, we can (and should) use HTTPS in all examples and list it as a "best practice". But there's no need to make it a requirement.
There are, today, podcasting platforms out there which will only accept HTTPS feeds.
Excellent, vendors should have that choice! In that spirit, I think I laid out reasonable points for why it'd be better not to mandate it, and I'm pretty sure there are others.
this seems to be mostly designed for linked resources and doesn't cover the initial redirect
It does, though it might be easy to miss. If a client sends an Upgrade-Insecure-Requests: 1 header, the server can respond with a HTTP 307 redirect to a HTTPS endpoint. See § 3.2.1.
Do we think it's worth coming up with a recommendation (like using a
<link rel="alternate" href="https://..." />) for feeds to enable HTTPS?
No. The user agent is responsible for declaring that it supports HTTPS and is willing to upgrade, or for treating enclosure URLs and embedded resources as HTTPS (via the upgrade-insecure-requests CSP). If the user agent supports Upgrade-Insecure-Requests, then this additional <link/> is noise. If the user agent doesn't, but does support HTTPS, then this additional <link/> is noise because it would need to know to prefer the HTTPS URL over the HTTP URL, at which point, the user agent should have just implemented this CSP.
If we were to stay so agnostic as to not even put HTTP in the spec, that would mean someone could offer their feeds only via FTP and be compliant.
I don't see an issue with that. Imagine a connected car scenario - the transit protocol for the XML and audio might not be HTTP/HTTPS (it could be QUIC, RTMP, etc.), but the application parsing the feed and playing the audio might otherwise be Syndicated Media compatible.
Which means that now every app has to support every protocol out there to say they are also compliant.
Apps are going to say they're 100% compliant regardless of their actual level of compliance. The canonical example is Media RSS - lots of apps claim to support Media RSS, but truly only support a tiny subset of Media RSS (how many people actually list the credits of an episode using the EBU credit types?).
@CharlesWiltgen nailed my opinion in his reply above - "small pieces, loosely joined".
I don't see an issue with that. Imagine a connected car scenario - the transit protocol for the XML and audio might not be HTTP/HTTPS (it could be QUIC, RTMP, etc.), but the application parsing the feed and playing the audio might otherwise be Syndicated Media compatible.
What I'm arguing for is requiring support for certain sensible protocols. It's really hard for me to believe that it makes sense for a podcast (as we all currently understand that term) to not be available via HTTP and still be considered in-spec. It's great if a feed is available over Gopher and some nuclear reactor takes advantage of that. I'm talking about a baseline, not a restriction.
I guess I'm not understanding the advantage to saying a publisher MAY offer a feed only via QUIC. We're trying to define and build a system that promotes widespread compatibility. Without a baseline for how the most basic aspects of the system get moved around the internet feels really risky to me.
It's really hard for me to believe that it makes sense for a podcast (as we all currently understand that term) to not be available via HTTP and still be considered in-spec.
I could have an RSS feed that is only available over RTMP or SIP that is still conforming in every other way. RSS itself is agnostic to the transport mechanism (file:// can work too); I don't think we should change that.
I think it's totally reasonable to say that a publisher SHOULD offer a conforming feed over a TLS encrypted stream, and if they are also hosting an unencrypted feed, they MUST support insecure connection upgrading if supported by the underlying transport method. Publishers MAY choose to upgrade requests without requiring a user agent to opt in, or they can choose to only upgrade requests when the user agent opts in (e.g. HTTP + Upgrade-Insecure-Requests).
I think it's also reasonable to say that a publisher SHOULD offer a feed over HTTP, but I wouldn't say they MUST offer a feed over HTTP. Podcasting as a whole has started to get less traditional people interested in delivering podcasts (telcos, auto manufacturers, terrestrial radio companies), and they have similar needs to ours, but often use protocols that we don't use. For instance, a connected car might use SIP to get a podcast feed and play back the episode because it's the voice network rather than the data network (and thus is available in more places). I would want to be able to claim compliance with the SM standard even though I'm not delivering the file over HTTP(S).
@ziggythehamster @CharlesWiltgen This fundamental question being raised here is whether it should be possible to assume as a consumer that any Syn.Med feed can be consumed by any Syn.Med client.
To this point, it's largely been the case that the most popular podcatchers have worked with any arbitrary feed. I have argued in the past that the assumption of interoperability between essentially any show and essentially any app is the core benefit of podcasts over other proprietary systems. If a company invents a proprietary transport mechanism and offers their shows only over that protocol in only their app, can it still be considered a podcast?
@ziggythehamster RE: the connected car scenario, wouldn't it make more sense for the manufacturer of the car to introduce a proxy system than for the car manufacturer to require every show offer their feed over an alternate protocol?
To this point, it's largely been the case that the most popular podcatchers have worked with any arbitrary feed.
That's still the case, we just largely assume that podcatchers support http:// and https://. They might use a library (like NSURLSession in Foundation.framework) which also supports ftp://, and can be theoretically extended to support other protocols.
Today, the problem we have is that some clients cannot support TLS, even when the end user does (due to firewalls, governments, routers, etc.). This prohibits HTTPS from working, but it would similarly prevent FTPS or RTMPS from working.
What the Syndicated Media specification should, in my opinion, tackle is:
- Recommending to serve feeds and files over TLS.
- Requiring that if TLS is supported by servers, an upgrade path for insecure requests is either forced (which can break user agents that do not support the particular set of TLS features/configuration used) or announced (if supported by the user agent - e.g., Upgrade-Insecure-Requests).
- Providing a non-normative section about Upgrade-Insecure-Requests so podcatcher and RSS feed generator developers alike know about that option for upgrading HTTP requests.
I don't think it should specifically say "your feed has to always be available over HTTP or HTTPS", because there are instances where a feed won't be available over HTTP or HTTPS. Let's say that someone wants to ship a Syndicated Media RSS feed over a blockchain (there's a ticket for this, I didn't look up the number). In that case, the URLs will be something like podchain://d32c4893b4757fce5bf6d982c7e383aa5edc25416dd138e4c51c0a0bc269f5cd. Similarly, the feeds could be distributed over a P2P filesystem like IPFS, and not necessarily be HTTP URLs.
I get that requiring HTTP or HTTPS means that a client that purports to support Syndicated Media will always work with a HTTP feed that purports to support Syndicated Media. I'd much rather the standard have a procedure to "fall back" on HTTP(S) if an unsupported URL scheme is entered into a supporting podcatcher (which still may fail if neither HTTP nor HTTPS are supported) than to make compliance with the standard dependent on supporting HTTP or HTTPS.
If a company invents a proprietary transport mechanism and offers their shows only over that protocol in only their app, can it still be considered a podcast?
Yes. We have podcasts which do not have public RSS enabled and are only available via our web player and in the customer's app. Some sports-related companies require that their podcasts are only available via their closed systems due to licensing issues. In our case, our web player doesn't speak RSS, but it could (and it might in the future), and still could conform to Syndicated Media without supporting the traditional transport mechanisms that RSS feeds are delivered from.
wouldn't it make more sense for the manufacturer of the car to introduce a proxy system than for the car manufacturer to require every show offer their feed over an alternate protocol?
It might, but the feed delivered over some-proprietary-protocol should still be Syndicated Media conforming. It's also much more likely that the show themselves do not concern themselves with this issue and their host does instead.
If a company invents a proprietary transport mechanism and offers their shows only over that protocol in only their app, can it still be considered a podcast?
Yes in the sense that many podcast apps (Google Play Music Podcasts, Spotify, etc.) don't use RSS between the user-facing app and the back-end.
No from an interoperability POV—a podcast is RSS. IMO that's another pretty good reason to defer to the RSS specification rather than specifying conflicting requirements.
Again, I think it's a great idea to use HTTPS in all examples (even enclosure URLs), and note the general benefits of using HTTPS instead of HTTP in our best-practices recommendations.
The RSS spec makes no recommendations re: how the feed itself is to be accessed, so this isn't an issue that can simply be deferred to that spec. The closest the current spec gets to this topic is: "RSS is a Web content syndication format" (emphasis mine). Contemporary and legacy representations of the web imply HTTP.
And the way the Google app hits it's own API has absolutely no bearing on this discussion. We're talking about how a published feed is being made available for consumption, not how data from an already-consumed feed is handled by a specific app.
I think it's important to remember that one of syndicated.media's primary goals is to maintain the core concepts of being distributed and decentralized. Just because someone calls something a podcast doesn't mean it's podcast in the way we are, purposefully and strictly, talking about in this group.
Audio programs that are exclusive to Audible Channels, even if there's an RSS feed backing them, are not podcasts. They simply don't operate within the system that we're talking about here. Sports programs that for licensing reasons are only available via closed system...sorry, those also aren't podcasts anymore than the books in my Audible library.
@ziggythehamster what good does it do anyone to say that a service is Syndicated.Media compliant if it cannot be consumed by any Syndicated.Media compliant client? This is a genuine question.
Re: your proprietary programs, one of the nice things about proprietary systems is that you can implement as much or as little of a public standard or spec as you like, with modifications as necessary. Since you control both the server and the client, any deviations you make are totally fine, as long as you don't represent them as being available in other apps, which you wouldn't want to.
So it seems to me like maybe there's a difference of opinion here on what a theoretical Syndicated.Media badge should mean and it comes down to a fundamental question of whether there is a benefit to blessing certain things as spec-compliant without them being interoperable. I confess this question hadn't really occurred to me before, because again in my mind, interoperability and portability is the entire point of open standards.
@CharlesWiltgen It's true that those providers do not transmit RSS to their clients, but it is also true that they require that podcasts be ingested over HTTP+RSS, so it's not really clear to me why this matters. Overcast and PocketCasts also don't transmit RSS directly to the client, but as podcatchers they consume RSS over HTTP.
The RSS spec makes no recommendations re: how the feed itself is to be accessed…
The reason for that is that it's generally considered poor design to lock a file format to a specific over-the-wire protocol.
Additionally, once you require HTTPS you have to weigh in on all other transport-level considerations. Is HTTPS/2 required? Why or why not? What happens when HTTP/2.1 arrives? Are apps allowed to do binary encoding, and if so which is required? Can podcasts never be distributed via IPFS and other "distributed web protocols"?
Audio programs that are exclusive to Audible Channels, even if there's an RSS feed backing them, are not podcasts.
Agree 100%. But as use cases go, creators and vendors will also use this spec to create and consume podcast feeds for content not necessarily distributed on the open web.
And if we were also designing a specification for a file format I suspect we would follow suit. But we're building a spec that encompasses the entirety of the podcasting distribution system. And we are doing so to solve problems for who are choosing to use that system, not their own system that happens to look a bit like podcasting.
I'm not sure that this spec should get into the semantics of what is and isn't a podcast. I've traditionally stuck with the "MP3s of spoken word content delivered via RSS" definition, but there are edge/corner cases that should be called podcasts but don't strictly meet that definition.
I'm also not sure this spec should be a kitchen sink that everyone is required to implement equally unless you're willing to police misuse. That means that it's impossible to say that "app X supports Syndicated Media, so it would support feature Y". App X is going to implement whatever features they want to, and claim full support for Syndicated Media. This happened with Media RSS, and this is currently happening with regular RSS, if you've had to deal with the idiosyncracies of the latest versions of iTunes/Podcasts.app. It is unwise to attempt to solve that cultural issue with a specification. Similarly, publishers and hosts are going to support whatever tags/features they find useful, and ignore the rest of the specification.
Given that point of view, there should be only a few MUSTs in this specification unless they're predicated on a SHOULD.
In my opinion, one of the MUSTs should not be to require HTTP or HTTPS. I think we should have language like:
RSS feeds SHOULD be made available over TLS. If an RSS feed is available over both TLS and an unencrypted connection, feed providers MUST do one of the following on the unencrypted connection: force an upgrade to TLS by redirecting the user agent, honor a user agent's request to upgrade to a secure connection, or announce the ability to upgrade to TLS using the underlying protocol's standard practice. Conforming user agents SHOULD support TLS, and SHOULD support upgrading an insecure request to a TLS-secured request when announced or required. Conforming user agents MAY announce their desire to upgrade to a secure connection on an insecure channel if they support TLS.
This is non-normative information: At the time of this writing, the standard way to upgrade HTTP requests to HTTPS requests is by using the Upgrade Insecure Requests content security policy. This standard allows user agents to announce they want to be upgraded to TLS, if available, as well as allows the server to announce they prefer
http://URLs to be treated ashttps://URLs, if the client supports it.
I also think that we should have some language like this in another section:
Conforming user agents SHOULD use the following algorithm when given a URL with an unsupported scheme:
- Resolve the URL's hostname. If it doesn't resolve, stop.
- Attempt to use the URL with a
https://scheme. If the server responds with an error, stop. If the server responds with a redirect, consider the resource redirected to when checking if the server responded with an error. If the server responds with data, stop. If the server didn't respond over HTTPS, continue.- Repeat step 2 using the
http://scheme. If the server didn't respond over HTTP, return an error to the user.
@chrisrhoden:
what good does it do anyone to say that a service is Syndicated.Media compliant if it cannot be consumed by any Syndicated.Media compliant client?
I think you and I have different views - and that's totally fine. I take the pessimistic view that an arbitrary Syndicated Media compliant user agent and an arbitrary Syndicated Media compliant server might not be able to communicate completely because developers on both sides only implemented a subset of Syndicated Media (though they may have marketed it as if they had full compliance). If it's absolutely critical for us to be able to say that any combination of SM-compliant user agent and SM-compliant server can communicate, then we have to police apps that claim compliance and have some mechanism for certification... and I don't think we should do that. We would eventually run into a large institution doing the wrong thing (i.e., Apple, Microsoft, Google) and it would be politically disadvantageous to tell them to fix their app or we'll yank certification.
That said, I do think that SM should be modular, and the modules supported should be declared, so that partial support (which I think is inevitable) is possible. For RSS-level features, this could be through making each module an XML namespace. For protocol-level features, this could use the /.well-known/ URI registry.
I would rather Syndicated Media be a buffet of features that providers and user agents can grab what they need from. For instance, I don't see why we couldn't have a chapters module where chapters are declared in the XML file. This doesn't work for those of us who have one XML file but N audio files of varying length, but we can choose not to use chapters in the XML file and instead embed chapters in the audio files. User agents might support both, neither, or one way of doing chapters, but this kind of support can be declared by saying something like "Chapter support: Syndicated Media and Embedded" on the app's description page.
But we're building a spec that encompasses the entirety of the podcasting distribution system.
As a spec consumer, I'd like to see the RSS extensions as their own atomic unit. A separate spec would be best, but I don't really mind as long as it has it's own name and URL.
@ziggythehamster @CharlesWiltgen Please forgive brevity, I'm looking to use as little of your time as possible and it may come across as curt. No offense is intended.
I'm not sure that this spec should get into the semantics of what is and isn't a podcast [...] there are edge/corner cases that should be called podcasts but don't strictly meet that definition.
You are absolutely getting into this by attempting to cover cases that are explicitly closed systems.
I'm also not sure this spec should be a kitchen sink that everyone is required to implement equally unless you're willing to police misuse. [...] I would rather Syndicated Media be a buffet of features that providers and user agents can grab what they need from.
It sounds like you and @CharlesWiltgen are in agreement on this, and I don't think I disagree. Given that, what's the harm in making a spec under the syndicated media umbrella requiring HTTPS? In case you were not aware, there is a fast-approaching forcing function in the form of iOS, and there are a few other cases (https://dev.twitter.com/cards/troubleshooting#mixed-content) where SSL is required for media.
I think you and I have different views - and that's totally fine.
I actually don't think that we disagree on the points that you think we disagree on. I believe that people will selectively implement the spec, and that clients will pay the brunt of that cost, because they'll ultimately need to support both feeds which claim support and those that do not. What I don't agree with is that we need to make concessions for those situations. Given that, I don't see the harm in making a lack of HTTPS a hard fail for compliance on e.g. https://podba.se/validate/
I think from a philosophical point of view I understand where both of you are coming from, but from a practical point of view, given the state of podcasts today, and what HTTPS support actually means, and what it means to plant our flag in the ground as an organization, I don't thing I understand the harm in making this one of the recommendations we come out of the gate with. Apple has already done it.
More to the point, it seems like there is real confusion here (I count myself among the confused) as to the intended output of the organization. I got the impression from @farski that there would be a rolling set of recommendations at the early stage, and that we would not be formalizing the recommendations in the short term, but may roll them in to e.g. the podba.se validator. If the intention is to write an omnibus spec draft, my position on this issue might change.
Does anybody know the details of browsers doing this? I think they are slowly being more hostile to HTTP, in favor of HTTPS. It started off with green for HTTPS, but soon it will be red for HTTP and at another date it will be a full page warning before HTTP traffic will be used.
Maybe "Syndicated Media Compliant" clients could do something similar, with marking feeds insecure.
It seems pretty obvious that clients should try to upgrade http feeds when added, and maybe even periodically as well in case a site is secured but not redirected.
@Cj-Malone The biggest thing that browsers are doing is making many features available only over HTTPS.
Re: upgrading, there is a cool draft spec posted here by @ziggythehamster that seems to be a good fit for the HTTP-to-HTTPS upgrade path from the client side, essentially you add a header to your request which indicates that you would prefer HTTPS which the server can redirect.
I found the Chrome proposal and discussion . The end result will be HTTP still working but marked insecure,
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ this seems to be in play as well, not sure if you were saying that this isn't as significant as marking pages as insecure (I disagree, but that's OK) or if you couldn't find these.
So to argue for burdening the Publisher here for a second...
If a spec is overly permissive to the point that the Client has to deal with "unknowns" (unexpected protocols, in this case), the best case is that the Client will just ignore whatever it doesn't understand. Which makes that unknown-protocol data essentially "private" to Clients in cahoots with the Publisher... and we're trying to create a public spec here, not a private/internal one.
This isn't to say that we can predict what the "common" protocols might be in 10 years. But I'd rather have a living spec than an intentionally vague one that requires some guesswork on the client's part.
I'd like to offer my two cents on this and offer a suggestion.
First, I'd like to express support for requiring feeds and audio files to be served over HTTPS. Podcasting is, at its core, about the distribution of information. HTTPS allows a web user to privately consume content without needing to worry about censorship or third party-injected advertising (e.g., over a malicious wifi connection). By making HTTPS a requirement in the spec, compliant user agents and podcasts can provide listeners the assurance that they will not be monitored, advertised to inappropriately, or blocked.
To address concerns of enforcement earlier in the thread, I'd recommend a similar approach to what Chrome has taken:
- If the feed URL is HTTPS, exit and continue as normal. If the feed URL is HTTP, perform a HEAD request.
- If the URL redirects, follow the redirect and go to step 1 using the new feed URL (following normal 301 redirect rules for podcasts).
- If the response contains HSTS headers, behave as if the the URL redirected to the equivalent URL over HTTPS and repeat step 1.
- Prompt the user with a warning that the feed is not secure, perhaps with a link to more information. Require the user to acknowledge that they are subscribing to an insecure podcast feed.
It may be even better to add an additional step to try to access HTTP URLs as if they were HTTPS when making the HEAD request. If the server responds with a success, short circuit the process. Some network libraries go out of their way to do this already.
I'd also like to caution against explicitly requiring HTTPS as the de-facto scheme for URLs. Rather, it would be better to explicitly disallow insecure schemes. This is functionally the same for almost all users, but would enable projects like IPFS and Dat to also participate with their respective protocols.
It may also be worthwhile to consider allowing an exception to HTTP-scheme URLs using a .onion (Tor) TLD. A .onion host is a host on the Tor network, where the request does not exit Tor onto the public internet (generally). Since Tor is encrypted anyway, HTTPS is unnecessary in this case.
An obvious blacklist of "insecure" schemes:
file://http://ftp://
I wholeheartedly agree with @mattbasta on this. He satisfies all of my concerns and gives solutions to everyone else's concerns. I would love for SM to strongly prefer TLS, but forbidding non-TLS connections is a touch too far. I think the spec should defer to whatever browsers do to negotiate HTTPS when given a HTTP URL. I'm not sure if there's a working document to incorporate by reference, but I would definitely let them take the lead with that since it is a far larger problem with them.