Secure context inline macro


(Jmedley) #1

I’ve noticed that a {{securecontext_inline}} macro has started to pop up on many pages, as well as a Secure context tag. Long-term would it make more sense to mark the things that do NOT require a secure context? However long it takes for HTTPS to spread, one thing we know for certain is that the number of secure context APIs will increase while the number of non-secure context APIs will decrease.


(Eric Shepherd) #2

Maybe. But will the overall number of things that require a secure context exceed the total number of things that don’t require one anytime soon?


(Chris Mills) #3

Have a read of this:

https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

I think this is something we probably need to do something about.

If all new features in the future are going to require secure contexts, then should we flip what we currently do, and mark older features that don’t require secure contexts?

And to make this less of a pain, should we make a change to our browser compat data so that secure context status is recorded on there, and then use the compat macro to signify that on pages? @fscholz I’d especially be interested in your thoughts :wink:


(Florian Scholz) #4

We’ve discussed this in https://github.com/mdn/browser-compat-data/issues/190 (feel free to continue the discussion there even if we closed the issue).

Basically, we said that this would be just another characteristic of a web feature, which upon changing it, requires a compat data entry as different user agents implement the changed characteristic at different times. So, for new APIs with secure contexts by default, there is no compat data entry necessary. We probably want collect this characteristic as general data in mdn/data, though.
I know the mdn/data repository isn’t in the best shape right now, but it might be worth strictly separating compat data from other data, because otherwise the compat-data repository might lose its focus.

So, yes, good idea to have this info available as structured data, but we’re still unsure about the scope of the compat repo, which we would rather like to be very concise.


(Jmedley) #5

Chris, I made this same argument several months ago based on the fact that Chrome has had a similar policy for several years already.


(Eric Shepherd) #6

OK, yes, if secure contexts are going to be the norm going forward, then it likely makes more sense to call out cases where it is not. Whether or not a secure context is required should also be noted in a standardized way in our structured data.

That way, we could use the data to automatically add appropriate markup to articles that cover pages that don’t require a secure context (such as a little warning badge in the corner of the page indicating that the context may not be secure).

I’m on a bit of a “if we don’t have to write it by hand, why not let the structured data and some script do the heavy lifting?” kick lately… :slight_smile:

Sheppy


(Chris Mills) #7

So we agree it is probably a good idea to put this in structured data somewhere, but we are not sure of the best place to put it.

To my mind, it would work very well in BCD, in the status sections, for example:

“status”: {
“experimental”: false,
“standard_track”: true,
“deprecated”: false,
“secure_context”: true
}

But I can understand Florian being wary about keeping it strict and focused, and not wanting everything to just be dumped in there. I guess the distinction here is that the BCD is stuff is all about specific standards features, whereas secure context status is a more general thing. We don’t need to mark every BCD data point - marking each API would be enough, as you’re not going to get part of an API in a secure context, and part not. (Well, I hope not anyhow!)

So it makes me wonder what would be the best way to record it. Is there an existing data structure we could add this to, or would we have to create a new data file somewhere inside https://github.com/mdn/data/tree/master/api?


(Jmedley) #8

I thought I had a good idea but now I don’t. I’m going to share it anyway because it might get people thinking outside the box, if you’ll pardon the cliche. (The reason I now think it’s bad is that I don’t like the idea of a macro that has no visible effect on the page. Webplatform.org had this problem and it was terrible.)

Anyway.

What if we had a macro like this and required it on every page.

{{secureContext(_boolean_)}}

The first version of the macro would render on every page where it was required, but do nothing on pages that don’t. The when the web develops to the point that we think it’s the non-secure APIs that need to be called out we flip it.


(Jmedley) #9

By the way, Chrome has and does deprecate non-secure contexts on existing APIs, EME, for example. This requires a note in BCD. If BCD doesn’t note APIs that are secure from day 1 then how do you present secure context in a consistent manner across APIs?


(Chris Mills) #10

We basically do already have this. See here for an example:

I include the {{securecontext_header}} macro in all page templates (documented at https://developer.mozilla.org/en-US/docs/MDN/Contribute/Structures/Page_types)

I am really wondering if we could include this information in the page in a more intelligent way, as part of the BCD, without needing a separate macro for it.


(Florian Scholz) #11

I’ve reopened this question for the BCD data, see https://github.com/mdn/browser-compat-data/issues/190#issuecomment-365602166

I think, generally, banners at the top of the pages will work very different in the future. We’re still researching about what we should show at the top of the pages, but there will be very likely a generic banner that contains a mix of information about a given feature (is it experimental, non-standard, deprecated, secure only, supported broadly?).

Whether or not the banner is shown and which content is in there is then likely driven by the info from the browser-compat-data repo.