Firefox, Chrome, Edge and Opera support it (including mobile).
Internet Explorer is dead (ok, is a Zombie. But was supper-seeded by Edge for most users).
Safari is sadly not yet supported.
The nice thing is that you can employ security enhancements based on this technique even
if it's not supported by all your clients.
I.e. you can automatically reject requests if the headers are given and have a bad value, which would add additional protection against certain attacks for all users except the ones stuck on IE or Safari.
This is a story that you can often hear on HN but I don't think it's correct.
There were three correlated reasons for the bad reputation of IE some years ago:
1. it was largely dominant, so people thought they could develop just taking that browser in consideration
2. for the previous point, MS started to develop proprietary features (like ActiveX)
3. at a certain point its development was stopped for a long time
Safari certainly cannot match the first two reasons. But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
Developers hated having to work around missing features for IE even when FF and Chrome took over the market, Safari is the exact same, except you can't even update the rendering engine on iOS, Apple doesn't want webapps to eat away at app store profit (notice how shitty and slow moving the webgl/webgpu thing has been mostly due to iOS Safari)
> Safari certainly cannot match the first two reasons.
1. Most users view websites on their phones. Safari is the only browser on iPhone (there are other browser skins, but they're all forced to run on top of Safari). The market share of iOS devices is usually about at least 50% in developed nations.
2. iOS has proprietary features, it is known as the App Store. If you want to develop certain things, you must use the app store, the browser is locked out of those features (even if all other browser vendors have them).
> But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
3. I probably don't need to go into this point since it's common knowledge that Safari has always been the least compliant browser in terms of web standards. Their history of holding back features or implementing features with critical flaws that make them useless has been a recurring trend for the last decade. Just because they have checked a box on a table, doesn't mean the feature is anything close to useable.
Right now but you can reasonably develop a website which will work in Chrome and Firefox even without testing (not talking about any supper modern features), but Safari is riddled with bugs you wouldn't expect. Recently I have encountered multiple bugs regarding svg clipping in safari. Safari 14 also broke localstorage and indexeddb it's almost funny how bad safari is at actually just working.
Well I found some chrome bugs, but here is the thing after I reported them, they have been immediately responded to and fixed and released in nearest version. Safari though you have to wait a year for bug fixes to be released, if they even acknowledge you at all inside their bug tracker the only way to get Webkit people attention is tag them on twitter.
I don’t quite understand this argument. Can you give me a couple examples of Safari holding back major parts of web design? Or is it more obscure stuff like some webGL engine?
Because I use Safari specifically for privacy reasons and it also used to never trigger my fans to full speed just to play videos, like Chrome. I also have read that while Safari does tend to take longer, their implementations tend to be more polished. But this was more like a tweet so take that anecdata with a grain of salt.
I often try to use a feature and it doesn't work properly on one browser. It's nearly always mobile safari. This week, I've dealt with scroll-snap (which makes URL anchors work correctly with a sticky header) being supported but only for some layouts (every other browser works).
Today I spent hours debugging why pages with a particular iframe embed would log you out of the parent site on Safari / iOS. Possibly because the same first-party resource was requested from both outside and inside the frame? Not sure yet.
If you attempt to use localStorage from a private tab on safari, it reports that it's present and working, but raises an exception on any access (every other platform either does not expose localStorage in private tabs, or clears it after).
Absence of push notifications makes it impossible to develop a lots of web apps.
Also more user-friendly way to install desktop shortcut would help tremendously to make web apps more popular. Of course Apple is not interested with that, but it's still sad.
I have done web-development both in the bad IE days but also recently and IMO it wasn't as bad to develop for IE as it is for Safari today. Safari is broken in strange and random ways and missing odd features and is a moving target (and seem to break more with time). Developing for IE was extremely well documented (especially in later versions) and avoiding pitfalls was very easy, even for people new to creating webpages using a few Google searches. Not so for Safari - unless you cut it completely off from all modern advances on the web. It just felt worse back then because IE was much more widespread.
Let's completely sidestep the whole debate that we always have. This is a safety feature, Safari will implement it, you can bet on it. It's merely going to be the last to do it.
Yep, I don't know why my first thought was that malicious actors could just bypass this by using external HTTP clients (like curl) when in fact this spec is meant to augment CORS: browsers _will_ send these headers to the server and the server can choose to honour them or not (well, in the CORS case the browser will block the request if the response headers are incorrect).
Internet Explorer is dead (ok, is a Zombie. But was supper-seeded by Edge for most users).
Safari is sadly not yet supported.
The nice thing is that you can employ security enhancements based on this technique even if it's not supported by all your clients.
I.e. you can automatically reject requests if the headers are given and have a bad value, which would add additional protection against certain attacks for all users except the ones stuck on IE or Safari.