It helps when you have a platform that supports feature detection reliably. Most platforms don't have that lucky accident.
Shell scripts are turing complete and can do arbitrary I/O. In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless.
Likewise, JavaScript and DOM features should always be detectable by eval(). I guess one instance where it's impossible is if the API changes the pixels on the screen and does nothing else.
Although you can actually detect this in some cases with JavaScript! JavaScript can leak information through the colors of attributes on the screen, e.g. you can tell if a user visited a site by looking if the link is purple!
It's hard to do feature-detection against cross-compilation toolchains, since "toolchain" doesn't imply a standardized emulator/debugger component for the resulting executables. Under cross-compilation, you can detect that your test programs compile and link, but you can't run them!
This, if you're wondering, is why SDKs for embedded architectures always seem stuck in the time before autoconf/cmake were invented: without feature-detection support, such toolchains (and the projects developed for them) have to get by with manually-written Makefiles.
This is also why the more modern game console SDKs (such as the Wii U SDK, my own most recent experience) are delivered as components that slide into an IDE like Visual Studio, rather than as standalone CLI toolchains for an IDE to drive. This way, they do have a (proprietary) standard way to add an emulator/debugger component, which can then serve as a core for the IDE's build system.
I think embedded toolchains use plain makefiles because they tend to fork code rather than upstream changes. And that is due to the ship-it-and-forget-it mindset of embedded companies that is well known among open source maintainers.
There are loads of ways to extract that information, and the number increases all the time as browsers get more complex. It's not something browser vendors actually consider to be a bug. They have historically only 'fixed' the trivial methods of getting the visited status because it became an issue that was widely publicised. If they cared at all they would never have implemented features like Shared Array Buffers.
This stuff is all sitting in years old open bug reports. Nobody cares.
https://bugzilla.mozilla.org/show_bug.cgi?id=884270 Link Visitedness can be detected by redraw timing
https://bugs.chromium.org/p/chromium/issues/detail?id=508166 Security: Chrome provides high-res timers which allow cache side channel attacks
Further reading on some of the exciting new timing attacks added to web standards in recent years:
https://arxiv.org/pdf/1502.07373v2.pdf The Spy in the Sandbox – Practical Cache Attacks in Javascript
https://www.contextis.com/resources/white-papers/pixel-perfe... Pixel Perfect Timing Attacks with HTML5 (now fixed because you could use it to steal the contents of any page)
http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf ASLR on the Line: Practical Cache Attacks on the MMU