I've been reading various informations about Google and Firefox using an HSTS preload list.
it seems that there is a generic list here : https://hstspreload.org/
and that Chrome uses the one from Chromium here :
https://www.chromium.org/hsts/
and Firefox uses the one here :
https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc
Does Safari or Opera use a HSTS preload list ? Which one ? What is the relationship between the 3 list cited above ?
Thank you
The defacto central master list for HSTS is managed by Chromium / Google
at https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json .
A list of Browsers supporting HSTS (and presumably having preload lists) can be found at Wikipedia.
Being closed source, information on how Opera, Safari, IE, etc. handle their preloaded lists seem to be unavailable.
The Microsoft Edge Team state in their Blog, that
Like other browsers which have implemented this feature, Microsoft Edge and Internet Explorer 11 base their preload list on the Chromium HSTS preload list.
For Firefox, the list at /source/mozilla/security/manager/ssl/nsSTSPreloadList.inc is generated by the file
/source/mozilla/security/manager/tools/getHSTSPreloadList.js, where we can see from the line
const SOURCE = "https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json?format=TEXT";
that it is merely a clone of the "master list", parsed into Firefox` format.
All it does is an additional verification run for each domain in the list to be available and have the required HSTS header (by connecting to it; which it seems to do daily, from the vcs log).
Palemoon follows this procedure and it is likely that other browser vendors do the same.
So it seems the relationship between your lists is: there is only one.
From your first link:
Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge)
also have HSTS preload lists based on the Chrome list. (See the HSTS
compatibility matrix.)
Related
in this piece of HTML code
PARTECIPA
the opening of the website in the Microsoft Edge browser is indicated if installed on the device.
Can anyone help me? I would like the site to open in Google Chrome and not in Edge.
How should I edit this HTML?
To open the link using the Chrome browser instead of Microsoft Edge, you can change the value of href attribute like this: PARTECIPA. Assuming that Chrome browser is installed, that should open the Chrome browser.
Problem:
If Edge is not installed on the device (mob, desk or tab) it doesn't
work
In this case, it's best to simply use a standard URL without specifying a specific browser, like this. PARTECIPA. In addition, the "googlechrome:" protocol is not a standardized protocol and probably may not work in all devices. So, you can use a standardized URL like the code snippet I posted above and let the users device choose.
Do you know if instead of chrome I can specify "default browser"
Example PARTECIPA or
something similar?
There is no standard protocol for specifying the default browser. So, best approach is to simply use a standard URL without specifying a specific browser. But if you really want to use special web protocols inside hypertext links to force web pages or files to open with particular browsers on Windows or iOS, place browser-name before the hypertext reference link.
Check this:
Open in Google Chrome
Open in Microsoft Edge
Open in Mozilla Firefox
Open in Apple Safari
Open in Opera
This function does not work!
A similar example is for IOS, which works in the following way
Example :
PARTECIPA
Google has official documentation on the Chrome iOS app’s URI scheme on its developer website.
Simply replace http with googlechrome and https with googlechromes. This means:
http://www.google.com/ becomes googlechrome://www.google.com/
https://apple.stackexchange.com/ becomes googlechromes://apple.stackexchange.com/
Previously, it supported an x-callback-url of googlechrome-x-callback://. This allowed the calling app to indicate its name and URI scheme to Chrome, which would show a back button in the address bar that closes the tab and invokes the specified URI. This feature was removed a few years ago when iOS 9 added the “Back to …” button in the status bar (but the URI scheme still works).
CanIUse and MDN doesn;t seems to be agree on the support for service worker. In the midst of Chrome going to remove support for appcach, we are trying to ascertain the impact of moving to Service Worker. Are we reading the above two pages incorrectly?
We tried Google's own samples against device/browser combinations and results wore not encouraging. For example the 'custom offline page' demo failed in iOS Chrome (v80) where it worked in iOS Safari (12.4.5).
The 'Selective caching' and 'Read through caching' pages clearly show "service worker is not supported in the current browser" in Chrome 80. It is checking the if ('serviceWorker' in navigator) {, but other samples doesn't show such a message.
All and all it is confusing on the browser support for the Service worker. Is there there a universally tested sample which we can use as a benchmark for different device/browser combination.
I asked Jake Archibald of Google on this and he replied with the following SO post which must be still valid.
Chrome Service Worker iOS Support
Therefore apparently Safari is the only option at the moment. I am still wondering what Google is recommending developers to use once they remove support for AppCache.
Jake continued saying there is no way they can add support as Apple is not giving them full rights on iOS. But he mentioned appcache will continue to work as usual. His exact words are
"However, since Chrome on iOS is just a skin over Safari, appcache will continue to work while it works in Safari webview."
on iOS only Safari supports service workers. You can test browsers if it supports with this code
if ('serviceWorker' in navigator) { /*supported*/ }
I've read that Firefox has begun supporting a cache control extension value of immutable, which means that "the response body will not change over time." So even if a user requests a "full refresh" of a page or resource, the browser still only responds with the locally cached copy, thus avoiding unnecessary 304s or page refreshes, and making pages load faster since cached content is used, and decreasing load on servers, since a large number of requests are stopped before they even happen.
I'm trying to see how well this is supported, and am finding varying answers, as this mozilla page suggests that it's only supported in Firefox, but this resolved Chrome issue suggests it's been available since Chrome v54.
Which browsers support Cache-Control: immutable, and when did they start supporting it?
I first read about it here on this Hacker News discussion
Here's an ietf draft on it, the original mozilla post announcing this beta feature being used by Facebook and this related mozilla post, and a document discussing the different types of reloading requests from some Google chrome devs, it appears.
As of February 2017, Cache-Control: immutable is supported by
Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) since Firefox 49
Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=611416) since Chrome 54 They aren't implementing this.
Safari (https://bugs.webkit.org/show_bug.cgi?id=167497) in Safari Technology Preview 24.
It is also listed on MDN and Can I Use ... ?.
As of April 2017 it is also supported in "classic" Edge
The web browsers store sts header but I dont know exactly where. Where does chrome and firefox store sts header? And can a browser turn off the hsts protocol?
Not aware of anyway of turning off this feature in any browser.
Chrome has a nice screen to handle HSTS settings (including the ability to remove cached versions) by typing this into the address bar: "chrome://net-internals/#hsts".
For Firefox you clear the history and "forget about this site".
For more details see here: http://classically.me/blogs/how-clear-hsts-settings-major-browsers
Why did IE9 leave out support for the File API and the multiple attribute on file inputs? Chrome, Firefox and Safari support the features. But IE9 (and Opera) failed to support these for some unknown reason. For IE9 it seems we're still stuck with Flash for multiple file upload support (iframe hacks do not count).
File API is still a 'Working Draft'.
Internet Explorer 10 will support File API (prototype) More Details