Hacker News Reader

Comment by chubot | Hacker News Reader

Yup, this is why feature detection is better than version detection.

jQuery changed their strategy in 2009: http://blog.jquery.com/2009/01/14/jquery-1-3-released/

"No More Browser Sniffing"

Also, autoconf has a lot of faults, but as far as I recall it's firmly based on the philosophy of feature detectino vs. version detection.

Maintainers of packages can write bad custom checks that test for features, but if you use the built-in autoconf checks, they're all about features.

CMake on the other hand seems to use version detection more, which I don't like.

View on HN

Good comment, triggers a bunch of associations:

1. the rule of thumb to prefer feature detection to user-agent sniffing is generally a reasonable one, BUT if you have something like WURFL to map UA to device (and device to capabilities) then the one-time, up-front lookup can be a better choice.

2. that said I remember using yepnope.js, and sharing this hilarious (because accurate) post on the history of the user-agent: http://webaim.org/blog/user-agent-string-history/

hard to believe it's been almost 20 years since I started messing with HTML...

It helps when you have a platform that supports feature detection reliably. Most platforms don't have that lucky accident.

What's an example where of a feature of cc or ld that you can't detect with feature detection?

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!

> 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.

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.

Yes good point. Though I think most features can be tested without running a program -- e.g. testing if a library function exists or has a certain signature.

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.

No modern browser lets you know the state of a:visited and will lie to you if you query for colors etc. In fact if you can find a way for js to determine if a link has been visited you are likely qualified for $$$ bug rewards (which has happened)

That's not really feature detection, though.

Ok thanks for the info, that makes sense!

Isn't there a technique involving custom fonts, to detect history, that's server side detection thou

>No modern browser lets you know the state of a:visited

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

Which is why jQuery throws (and handles) exceptions every single time I run it under a debugger. Ugh.

Reply on news.ycombinator.com