Browser-compat-data: Represent "only available in secure contexts" in the schema

[wbamberg]

As discussed here: https://groups.google.com/forum/#!topic/mozilla.dev.mdc/d86_ocGyYNc it might be good for the compat data to be able to represent whether a feature is only made available in secure contexts.

I assume this would need to be represented at the level of individual browsers, since different browsers might have different rules about it.

[Elchi3]

I think this would be an optional property in simple_support_statement:

"simple_support_statement": {
  "type": "object",
  "properties": {
    "prefix": { "type": "string" },
    "alternative_name": { "type": "string" },
    "flag": ...,
    "partial_implementation": { "type": "boolean" },
    "secure_context_required: { "type": "boolean" },
    ...
  }
},

Does secure_context_required sound good to you? Is this a boolean type or something else?

[stephaniehobson]

secure_context_required 👍
Boolean 👍

We can add more information by linking to Chris' article in the UI and if that's not specific enough details can be added in notes.

[stephaniehobson]

I also agree with Will, it needs to be browser and version specific.

[wbamberg]

I also agree with Will, it needs to be browser and version specific.

Related to this, but more general than just this issue: it would be good to be clear on the scope of what is "browser compat data" and what is just "data".

At a first approximation: if it's not in the standard, but is just a thing different browsers do differently, then it's browser compat data. If the behavior is standardised then it isn't. Maybe?

[stephaniehobson]

Big question is big.

[Elchi3]

This will come up soon, this repository has compat data about WebVR, and Firefox is planning to have WebVR HTTPS only starting with 59: https://groups.google.com/forum/#!topic/mozilla.dev.platform/bU2gil1SHkY

[teoli2003]

Shouldn't this be at the feature level? If a secure context is required is part of the spec (or as part of the Web platform).

[Elchi3]

Seems like so far we could image a new property in the support statement:

{
  "api": {
    "VRDisplay": {
      "__compat": {
        "mdn_url": "https://developer.mozilla.org/docs/Web/API/VRDisplay",
        "support": {
          "firefox": [
            {
               "version_added": "59",
               "secure_context_required": true
            },
            {
              "version_added": "55",
              "notes": "Windows support was enabled in Firefox 55."
            },
            {
              "version_added": "58",
              "notes": "macOS support was enabled in Firefox 58."
            }
          ]
        }
      }
    }
  }
}

Or adding it as a sub feature, if I understand correctly what teoli proposes above https://github.com/mdn/browser-compat-data/issues/190#issuecomment-346650011

{
  "api": {
    "VRDisplay": {
      "__compat": {
        "mdn_url": "https://developer.mozilla.org/docs/Web/API/VRDisplay",
        "support": {
          "firefox": [
            {
              "version_added": "55",
              "notes": "Windows support was enabled in Firefox 55."
            },
            {
              "version_added": "58",
              "notes": "macOS support was enabled in Firefox 58."
            }
          ]
        }
      },
      "secure_context_required": {
        "description": "Secure context required (HTTPS)",
        "support": {
          "firefox": {
              "version_added": "59"
            }
        }
      }
    }
  }
}

[teoli2003]

Hi all!

The restriction of a feature to be available only in secure contexts or not is fundamentally taken at the web platform level: like the syntax of a CSS property, this is defined in the spec. If we need it to display automatically some information in the pages we should add it to the data/ repository (how is open to discussion). We do similarly for the inheritance/implementation chain of APIs.

In this normal case, browsers implement a new feature with the right restriction from the start. No information is needed

There are a few (old) interfaces that saw their availability change: usually they were allowed in any context and this was later restricted (usually for solving security problems). In these cases, I think the subfeature example by @Elchi3 is the right way to mark this.

TL;DR;

• Add secure context info inside the data/ repo, not here
• For APIs that saw this support change (and only these), use a subfeature here.

[Elchi3]

What Jean-Yves says makes total sense to me. Let's treat this as an aspect / sub feature of a given feature like we would treat anything else as well. We could standardize the sub feature name and description, though, as there are a few APIs that got this restriction later on.

"secure_context_required": {
        "description": "Secure context required (HTTPS)",

[Elchi3]

This was discussed again in this weeks BCD meeting and we have consensus on using sub features and not introducing a new property. The same will be used for things like requires_user_permission etc.

Generally, having data available about which APIs require a permission or a secure context, could be put in the mdn/data repository in the future. For now, on MDN, we're still manually adding banners and manual textual information about these things.

[jonathanKingston]

For now, on MDN, we're still manually adding banners and manual textual information about these things.

Does this decision get impacted by the decision to restrict all new APIs or our decision to change registerProtocolHandler/AppCache to HTTPS only?

In WebIDL there are discussions to flip the status quo and mark APIs as available on insecure too which might be a plan for the future.

There is also the support table here: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts which is being manually maintained etc.

Happy to discuss :)

[jpmedley]

I didn't even know that existed. Chrome has been implementing things for secure contexts right and left, and I haven't been updating that.

[Elchi3]

Seems like there is a renewed demand about this data and that it maybe belongs into this repo.
Like Chris says on discourse, I could imagine to add it like this.

{
  "api": {
    "BasicCardRequest": {
      "__compat": {
        "mdn_url": "https://developer.mozilla.org/docs/Web/API/BasicCardRequest",
        "support": {
          "firefox": {
              "version_added": "55",
            },
           "chrome": {
              "version_added": "45",
            }
        },
        "status": {
          "experimental": false,
          "standard_track": true,
          "deprecated": false,
          "secure_context": true
        }
      },
      "secure_context_required": {
        "description": "Secure context required (HTTPS)",
        "support": {
          "firefox": {
              "version_added": "59"
            },
            "chrome": {
              "version_added": "60"
            }
        }
      }
    }
  }
}

This would record two things:

1) status.secure_context:
Tells whether or not this feature requires a secure context per its spec.
2) "secure_context_required" sub feature
Creates a new row in the compat table and indicates in which versions the browsers implemented the secure context requirement.

If a new API is invented and it is only available from secure contexts from the start, the sub feature is not needed, but we still indicate this with status.secure_context: true.

The redesigned compat tables make use of the information in the status object. So there is the "experimental" icon on BasicCardRequest, for example. If we add "secure_context" to the status object, I could imagine to implement a lock icon to appear at the same spot.

Thoughts?

[jpmedley]

I'm not sure it deserves to be in compat data. This is a temporary problem. At some point it will become a practical impossibility to build a web page without https. At that point, having secure context will be noise.

What about a cross-reference file? When the big compat list gets built, it can simply be mixed in based on API name as key. A few years down the road the code and the file can simply be removed. The cross-reference might look like this:

"BasicCardRequest": {
  "secure_context": true
}

[bunnybooboo]

Another example page which has a specific row on secure_context_only https://developer.mozilla.org/en-US/docs/Web/API/Coordinates

[Elchi3]

I'm not sure it deserves to be in compat data. This is a temporary problem. At some point it will become a practical impossibility to build a web page without https. At that point, having secure context will be noise.
What about a cross-reference file? When the big compat list gets built, it can simply be mixed in based on API name as key. A few years down the road the code and the file can simply be removed.

This might be true, although it seems like for now and for the foreseeable future (next 2 years maybe?) people are interested in what requires HTTPS. It also indeed impacts compatibility of (legacy) code or sites.

I think, if this info becomes irrelevant at some point, it could be removed from this repo easily, too.
For adding the data point somewhere and having it then displayed on MDN, it seems like doing that here might just be the quickest solution for the moment.

Open to other suggestions, though.

[DeeprajPandey]

So, how do we add the secure_context info then?
Do we add it to status and as a sub-feature?

[ExE-Boss]

Based on existing PRs (eg. https://github.com/mdn/browser-compat-data/pull/1008#discussion_r168187628, #1787 and #2304) and the search for "secure_context_required", this has been resolved as a sub-feature.

[vinyldarkscratch]

I think that we can close this issue now that we have a system in place, sound good?

[jpmedley]

I don't see a PR where this was implemented in the schema or its documentation. Was that done?

[vinyldarkscratch]

@jpmedley It was resolved as a sub-feature in the data, thus is not explicitly included in the schema (plus sub-features allow for us to differentiate between browsers). The documentation, however, has now been proposed in #3871. ;)