Comments (22)
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?
from browser-compat-data.
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.
from browser-compat-data.
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
}
from browser-compat-data.
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:
status.secure_context
:
Tells whether or not this feature requires a secure context per its spec."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?
from browser-compat-data.
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.
from browser-compat-data.
Based on existing PRs (eg. #1008 (comment), #1787 and #2304) and the search for "secure_context_required"
, this has been resolved as a sub-feature.
from browser-compat-data.
I think that we can close this issue now that we have a system in place, sound good?
from browser-compat-data.
@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. ;)
from browser-compat-data.
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.
from browser-compat-data.
I also agree with Will, it needs to be browser and version specific.
from browser-compat-data.
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?
from browser-compat-data.
Big question is big.
from browser-compat-data.
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
from browser-compat-data.
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).
from browser-compat-data.
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 #190 (comment)
{
"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"
}
}
}
}
}
}
from browser-compat-data.
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)",
from browser-compat-data.
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.
from browser-compat-data.
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 :)
from browser-compat-data.
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.
from browser-compat-data.
Another example page which has a specific row on secure_context_only https://developer.mozilla.org/en-US/docs/Web/API/Coordinates
from browser-compat-data.
So, how do we add the secure_context info then?
Do we add it to status and as a sub-feature?
from browser-compat-data.
I don't see a PR where this was implemented in the schema or its documentation. Was that done?
from browser-compat-data.
Related Issues (20)
- html.global_attributes.autocomplete - Webauthn Safari/Firefox support
- css.selectors.any-link - Related bug in Webkit mentioned has been marked as resolved. HOT 1
- api.CredentialsContainer.create.publicKey_option.extensions - Release notes for IOS 17 shows support for largeblob
- css.properties.clip-path - "is animatable" is supported in Safari but is listed as not supported HOT 4
- css.properties.clip-path - "clip-path: url(#id)" not tested (e.g. currently does not work in Chrome or MS Edge) HOT 1
- onCommand: Add tab - add support version
- ImageData constructor() - settings parameter
- css.properties.resize - mdn disagrees with caniuse regarding iOS Safari support HOT 2
- css.types.global_keywords.revert-layer - Revert layer supported in webkit browsers
- CSS <color> data type, color functions - "none" keyword not properly supported by any browser at this time
- Response.Body - body is a readable byte stream `supported` in the Safari and Deno HOT 2
- webextensions.api.scripting - wrong supported chrome version
- webextensions.api.action.setBadgeText - wrong chrome support status
- http.status.412 - <SUMMARIZE THE PROBLEM> HOT 1
- engine_version should be a required field in browser releases HOT 1
- api.Window.navigator - <Is it compatible with detecting the WeChat browser in China?> HOT 1
- css.types.image.gradient.linear-gradient - interpolation is supported by firefox but flagged
- Intersection Observer v2 (visibility tracking)
- html.elements.iframe - allow-storage-access-by-user-activation is shipped in Firefox HOT 2
- api.Permissions.query - <SUMMARIZE THE PROBLEM> HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from browser-compat-data.