No tool in existence protects your anonymity on the Web better than the software Tor, which encrypts Internet traffic and bounces it through random computers around the world. But for guarding anything other than Web browsing, Tor has required a mixture of finicky technical setup and software tweaks. Now routing all your traffic through Tor may be as simple as putting a portable hardware condom on your ethernet cable.
“If privacy is important to you, the Blackphone is almost certainly what you’re after in a mobile device. Besides, you don’t have much choice currently. One thing I’m still coming to terms with, however, is the concept of selling peace of mind.
As Edward Snowden continues to leak information about how the NSA and other national government agencies were/are hoovering up every bit of personal data available to them, digital privacy has never been a hotter topic. With people wanting more control over how their data is handled, it was inevitable that products like the Blackphone would appear.”
This column has written many times about the deep flaws of Digital Rights Management (DRM) - or "Digital Restrictions Management" as Richard Stallman rightly calls it - and the ridiculous laws that have been passed to "protect" it. What these effectively do is place copyright above basic rights - not just in the realm of copyright, but even in areas like privacy. Yesterday, another example of the folly of using DRM'd products came to light.
Red Hat Product Security track lots of data about every vulnerability affecting every Red Hat product. We make all this data available on our Measurement page and from time to time write various blog posts and reports about interesting metrics or trends.
One metric we’ve not written about since 2009 is the source of the vulnerabilities we fix. We want to answer the question of how did Red Hat Product Security first hear about each vulnerability?
Every vulnerability that affects a Red Hat product is given a master tracking bug in Red Hat bugzilla. This bug contains a whiteboard field with a comma separated list of metadata including the dates we found out about the issue, and the source. You can get a file containing all this information already gathered for every CVE. A few months ago we updated our ‘daysofrisk’ command line tool to parse the source information allowing anyone to quickly create reports like this one.
While OpenBSD generally prides itself on being a secure, open-source operating system and focusing more on code corectness and security rather than flashy features, it turns out a potential security bug has been living within OpenBSD for the past decade.
Phoronix German ready "FRIGN" wrote in to Phoronix this afternoon with a subject entitled, "10 year old critical bug in OpenBSD discovered." He pointed out a post today about a bug discovered in OpenBSD's polling subsystem that could allow DDoS-style attacks on servers, "a critical bug in the polling-subsystem in OpenBSD has been uncovered which allows DDoS-attacks on servers using a non-standard derivation from the POSIX-standard in marking file descriptors non-readable when they should return EOF."
It hasn't been a good year for open source. Not for its generally golden reputation for software quality and security, anyway. But in a rush to lay blame for the Bash Shellshock vulnerability (and previously for Heartbleed) some, like Roger Grimes, want to dismantle some of the cardinal tenets of open source, like the suggestion that "given enough eyeballs, all bugs are shallow."