The Register article, which includes *a portion of* the results table: http://www.theregister.co.uk/2016/05/24/pointless_features_add_to_browser_bloat_and_insecurity/ The paper: Browser Feature Usage on the Modern Web https://arxiv.org/abs/1605.06467 Current PDF: https://arxiv.org/pdf/1605.06467v1
It would be great if most unused features could be disabled using browser's built-in settings and then enabled on per-site basis. Or maybe building a click to play option for most unused features...
I hope JavaScript will be stripped of some of its features, that's the only way to stop idiotic web-developers from ruining the web.
Thanks for providing a link to the PDF document, TWB I've emailed one of the authors to inquire: During testing, which "user-agent" (desktop? mobile?) was presented in request headers? Are they able to share the code for their custom browser extension? Although they acknowledge, in Section 2.1, that "browsers typically (have) a unified code base across different types of computers including mobile devices..." I did not find within the PDF a statement describing WHICH "user-agent" (desktop? mobile?) was used throughout their testing. Seems to me that detail could significantly affect which external scripts a given site would conditionally load into the requested pages, as well as which "features" are (or are not) invoked by a given page. I'm left wondering: Do sites typically, blindly, attempt to utilize e.g. dom.vibrate() ...even when the page has been requested by a non-mobile user agent ? Without attention to spoofing this detail (user agent) and A/B testing, some of the conclusions of this research are likely skewed, or outright meaningless ~~ e.g. (Section 5.4) "Ambient Light Events standard, which defines events and methods allowing a website to react to changes to the level of light the computer, laptop or mobile phone is exposed to. The standard is rarely used on the web (14 out of 10k sites)," In order to be (more, or fully) effective, I suspect a detection extension should hook an earlier event, prior to DOM creation (as explained by the author of the "mason" firefox extension). Really though, "content script" (vs "chrome script", or Observer) seems like courting futility, amid abortable Promises and revokable Proxies and js Reflect() Cannot be bypassed? Hmm, I'd need to review the code. These researchers are unaware that ff46 supports ES6 Proxy() ? Using "closures" serves as comparatively superior, bulletproof, approach ? Toward a goal of achieving "informed consent", I hope to write a browser extension which detects, and notifies via doorhanger, when a page attempts to invoke certain "features". I had envisioned utilizing ES6 Proxy ojbects to wrap the various targeted features; I was surprised to note the PDF doesn't mention use of such Proxy wrappers.
Developers are encouraged to use feature detection over user-agent sniffing, but I imagine there is plenty of feature manipulation behind user-agent checks. Arguably, the world could use a good "WhatNot" framework that supports not only detection/alerting but blocking. Please let us know if you develop, or discover, something useful. A few related links: https://github.com/citp/OpenWPM https://github.com/EFForg/privacybadgerfirefox https://github.com/ghostwords/chameleon https://github.com/kkapsner/CanvasBlocker
i'd like to see your (surprised) face when you finally turn off javascript in your browser forever. it would also resolve some of your questions here immediately. features come and go. features are for the masses - not for individualists. as an individualist some has be encouraged himself to opt'out or opt'in - or change software. dont like javascript? get lynx or similar: http://listoffreeware.com/best-free-text-only-browser-for-windows/ simple as that.
Who is talking about disabling JS? I just think that web-design is becoming more silly by the day, too many times I encounter dumb designed and bloated websites, so perhaps it's time to scrap some features.
here's a summary of the email reply I received from one of the authors: Their script/bot supplied this user agent string. They did not (re)test using others: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Their extension did not (did not need to) utilize ecmascript Proxy object, and: "the paper is currently under review at a conference, but once we hear back from the reviewers, we plan on releasing the extension" They intend to followup by creating an extension which will enforce "a default allow / block policy for browser features depending on how often they're blocked by tracking blockers and how many security vulnerabilities have been associated with the feature in the past" and they do expect it will heavilty rely on use of Proxy wrappers. - - - - - Echoing what Minimalist posted, I'm itching for an extension which provides "informed consent" ~~ displaying a doorhanger, or notification bar (similar to: "continue blocking?" prompt when a site attempts to load flash, and "always ask" pref is set) when sites attempt to invoke selected (from a picklist) features.