Security for the people
google-opensource.blogspot.com
google-opensource.blogspot.com
I point all this out because it perfectly illustrates their point. Here are a group of smart people launching a great initiative with a beautiful and modern website, and they made some mistakes just like the rest of us do.
I've offered to help and recommended they switch to Piwik (and fix the http link). I hope others here on HN who care about security and privacy will also offer to help out. Some of this stuff is easy to fix and I think it's a great initiative.
I've offered to help and recommended they switch to Piwik (and fix the http link).
It's that or be dismissed as just another iteration of Microsoft's 'embrace, extend, extinguish' plays.
You don't. They're wildly different disciplines. Security auditing is fundamentally a systems programming problem. The least effective security "auditors" approach security as something different than software engineering. The most significant security issues arise from correctness issues; finding and fleshing them out involves discovering the degrees of freedom offered to an attacker by faulty assumptions made by blocks of code scattered throughout an entire system.
That's not to take anything away from the practice this team is trying to start! Someone should be doing security usability work, because I don't know anyone who does it well now.
Providing real software security for open source projects is a tricky problem. Talented software security people are in enormous demand. Bill rates are going up. One thing a project like this might want to tackle is onboarding more technical people into the discipline, to address the supply problem.
I am not suggesting that security usability (or, to keep it technical, security UX) is easy, or that software security practices are necessarily good at it.
A single assessment is not necessarily a single metric, and an assessment comprised of audits in each domain seems like a good first step toward building understanding of a common goal and measuring progress toward it. Putting these audits together will hopefully start to expose not only the tradeoffs, but also the synergies at play in designing secure systems.
It seems to me that at the root of the security usability problem is a failure in collaboration between developers with solid software engineering practices and designers with solid UX design practices. Talent on both sides is in high demand, but there are few organizations that are able to get both working together effectively on these hard problems.
Somehow Duo Security[1] has managed to do this phenomenally well. Their product is both a UX wonder and a security marvel. My first thought was "This doesn't feel like a security product. This feels like a solid UX design demo." But looking at their open source code, it's some of the more beautifully designed security software I've seen. I wonder what their secret is-- and if they'd be willing to share.
> However, if people are indeed working to protect themselves, why are we still seeing incidents, breaches, and confusion?
That references a completely different security area, and as much as it's a juicy source of scare stories for mass media, it's unrelated to end user security with respect to government and corporate mass surveillance.
The former is basically insecure by design (based on the assumption that transactions are always reversible), with the duct tape occasionally failing. The latter will never manifest itself as a discrete problem for the sheer majority of people, but just an ever-growing set of annoyances and chilling effect on one's thoughts and actions.
They require completely different approaches. For the former simply having backup credit cards, being prepared to sue your banks for negligently giving away your money, and flagging the pop culture scare articles off Hacker News - that's about all you can do, because the deficient technology is not yours.
The latter requires proactively analyzing the implications of one's technology choices and avoiding the attractive nuisances. Fixing these problems is not at all straightforward and is one of the great struggles of our time, which is why it is such a disservice to conflate the two.
These things can happen because the public is uninformed, disinterested, and subjected to carefully coordinated messaging by security companies selling solutions, "credit monitoring" companies that package insurance, and the mass media that doesn't have a deep commitment to getting the facys right when it comes to this topic.
The significance of these types of project extend beyond browser privacy. As crypto-currency become more prominent, we NEED better, carefully auditted javascript crypto-libraries.
Right now, all the crypto-code are home baked. e.g.: https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/e...
While, I think they are all doing a fine job. It is not settling to think that these mission critical, crypto-code is not vetted by cryptographers.
In fact, a few months ago, there was a bug where the nonce for each signature was not set properly that basically meant you were able to work out the private key for 2 different signatures. Some users lost funds due to the bug.
These open initiatives will lay an important foundation.
His disclaimer mentions three game-over problems.
Bitcoin is fascinating just because it makes these sorts of things worth untraceable money, sometimes a lot of money, and puts it in the hands of people who have never had that sort of responsibility. Whatever else cryptocurrency does, maybe it will teach laypeople about these things, devise new ways to teach them and new technological measures to increase their safety.
The problem isn't with javascript, it is with delivering javascript in a web-based application (amongst other concerns).
Most of the other concerns about web delivered javascript also don't apply to extension security. Example: a web application can't interfere with the execution of extension code since extensions reside within their own context and cross-origin rules apply (there are special API's accessibly only from the extension to call into the web javascript).
End-to-end from Google is a browser extension, and it is signed by the developers and then verified on install. It is more secure than a traditional desktop software installation.
While this particular announcement seems fluffy, I do somewhat applaud the intent. The question of how we expect to run the internet economy and preserve user privacy is becoming more pressing for everyone though.
It should be run like the economy should be run, with consumers paying for the things they consume directly, rather than via an advertiser proxy at significant additional costs to us all[1]. Then there would be zero need to violate user privacy except where it strictly required for end-user desired functionality, and users can vote with their wallets.
The invisible hand only works correctly with such a direct buyer-producer relationship.
This notion of "free" websites and web services is a lie and needs to be exposed[1].
I'm optimistic because these are open standards backed by many big organizations, and web browsers will be shipping with support built right in, no drivers, no plugins.
Tokens like that Yubikey work over USB HID (they look like keyboards to the OS, so they don't need dedicated drivers). They also work over NFC on mobile devices (ok, on Android devices. Still waiting on iOS.)
[0] https://fidoalliance.org/specifications [1] http://www.yubico.com/2014/09/yubikey-neo-u2f/
But something about this makes me uncomfortable. The fact that when this appeared on the front page of HN it was with posts from Google and Dropbox about how they support this.
Google that Assange is releasing a book about, and Dropbox that went a day where it didn't matter what password you entered and has former Secretary Rice on their board.
I have a feeling this organization might help keep things like the recent celebrity iCloud break happening, but as someone else said, real security is not easy. And false security is worse than no security.
Funny how Google doesn't offer a messaging service that's secured to a physical device the way Apple does, and these projects when combined would result in something like that.
Encrypting your e-mail does not help you if your machine is compromised.
Your super-secure 24 character password is useless if you use it on every single website.
Encrypting and salting your users credentials is useless if your SSH password is 6-digits.
What i'm saying is: REALLY staying secure is not easy and it never will be.
That future is now according to Apple.
In any case the real issue is protecting people from Google itself.
If you had read either the privacy policy or security architecture, you would know that you have made a false statement here.
I think it's you who is trying to distract us from the fact that Google itself uses your private data for its own business purposes, and has a vested interest in not protecting you from itself.
Meanwhile, I show nor imply any support for Google on the subject. They are no better, perhaps worse.
Not much point in discussing anything with you, I guess.
They should use a SHA256 certificate :-)
And DANE and TLSA