4 ms·

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

by chubot 9y ago

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!

derefr 9y ago
> 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.
- chubot 9y ago
  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.
0x0 9y ago
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)
- vosper 9y ago
  That's not really feature detection, though.
- chubot 9y ago
  Ok thanks for the info, that makes sense!
- zaphirplane 9y ago
  Isn't there a technique involving custom fonts, to detect history, that's server side detection thou
- anon1385 9y ago
  >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 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 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 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-perfect-timing-attacks-with-html5 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 http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf ASLR on the Line: Practical Cache Attacks on the MMU

by chubot 9y ago

derefr 9y ago

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

chubot 9y ago
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.

0x0 9y ago

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)

vosper 9y ago
That's not really feature detection, though.
chubot 9y ago
Ok thanks for the info, that makes sense!
zaphirplane 9y ago
Isn't there a technique involving custom fonts, to detect history, that's server side detection thou
anon1385 9y ago
>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 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 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 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-perfect-timing-attacks-with-html5 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 http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf ASLR on the Line: Practical Cache Attacks on the MMU