Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Gotta have standards? Security boffins not API about bloated browsers

W3C, are you listening?

+Comment The W3C introduces API standards that end up mostly unused, doing nothing more than loading up the code base with vulnerabilities.

That's the conclusion of a paper by University of Illinois, Chicago researchers to be presented next week at the ACM's Conference on Computer and Communications Security in Dallas.

Chrome 56 quietly added Bluetooth snitch API

READ MORE

While the research – "Most Websites Don't Need to Vibrate: A Cost-Benefit Approach to Improving Browser Security" – which you can find here at arXiv, focuses on Firefox, its findings are relevant across the board.

Graduate computer science student Peter Snyder and colleagues Cynthia Taylor and Chris Kanich structure the paper as a cost-benefit analysis of having 74 APIs with which browser authors need contend. On the benefit side, they measured the proportion of websites that use a feature (thereby making browser support important); on the cost side, they tried to measure the security exposure a feature created.

The “cost” side takes a couple of characteristics into account, including the number of historical CVEs associated with a feature (since that hints that it's hard to code to the API securely); and the number of API entry points and lines of code that are associated with a feature, since that indicates more complex code.

Their headline finding should chill browser authors:

“Blocking 15 of the 74 standards avoids 52.0 per cent of code paths related to previous CVEs, and 50.0 per cent of implementation code identified by our metric, without affecting the functionality of 94.7 per cent of measured websites.”

A search of the Mitre CVE (Common Vulnerabilities and Exposures) database yielded 1,554 CVEs for Firefox since 2010, a decent enough sample (Chrome has had 1,523 in the same period), and 175 of those related to implementations of 39 Web APIs, with 13 related to multiple standards.

The researchers crafted a browser extension to block APIs based on the risk measurement, and this is how things turned out:

Blocking vulnerable APIs

Blocking risky APIs breaks hardly any websites,
but makes the user more secure.

+Comment

The results come as little surprise to Vulture South, since over the last couple of years, we've taken a growing interest in the privacy implications of APIs that serve little purpose but to profile users for advertisers.

shutterstock_215940778

Apple, Mozilla kill API to deplete W3C battery-snitching standard

READ MORE

Examples include the Web Battery API, dropped by Apple and Mozilla over privacy fears; the Bluetooth API; a motion sensor API that a smart cookie used to snoop on phones' unlock codes; a risky ambient light sensing API, and so on (for most of these, we're indebted to security researcher Lukasz Olejnik).

It's yet another reason the W3C needs to take a leaf out of the Internet Architecture Board's book, and make user protection part of its mission, instead of an afterthought. ®

Similar topics

Similar topics

Similar topics

TIP US OFF

Send us news


Other stories you might like