slasaus

> The article makes not justification for its title "the false trade-off betweent security and liberty."

I think they make their point in the end:

> In the immediate circumstances, liberty and security can require trade-offs. But from any longer perspective, security is the basis and foundation of liberty—a truth eloquently stated by another American president, Franklin Roosevelt, when he inscribed freedom from fear alongside freedom of speech, freedom of worship, and freedom from want in his great “Four Freedoms” speech of January 1941.

I think some sense of security is needed in order to fully exploit the creative and innovative properties of liberty. In other words, just as much as the Panopticon effect hurts freedom, experimenting and developing new ideas— insecurity can hurt these properties as well so I do think it's a trade-off.

> Shouldn't there be a "Chromium-Privacy" project that branches Chromium and reviews code changes, to keep it aligned with such goals?

Maybe Iridium is what you're looking for. From their fp:

> Iridium is a free, open, and libre browser modification of the Chromium code base, with privacy being enhanced in several key areas. Automatic transmission of partial queries, keywords, metrics to central services inhibited and only occurs with consent. In addition, all our builds are reproducible, and modifications are auditable, setting the project ahead of other secure browser providers.

https://iridiumbrowser.de/

> The short-cut around it is the concept of burden of proof in INFOSEC: one is expected to back up their big, security claims with evidence rather than everyone else expected to disprove them.

Totally agree with that.

> do they even analyze every bug for exploitability?

I guess in a real world production used operating system there are practical limits. From http://www.openbsd.org/security.html

"Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996. The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. Flaws have been found in just about every area of the system. Entire new classes of security problems have been found during our audit, and often source code which had been audited earlier needs re-auditing with these new flaws in mind. Code often gets audited multiple times, and by multiple people with different auditing skills."

and

"Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a `newly discovered problem', and then it would be discovered that OpenBSD had been fixed in a previous release). In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the intermediate steps."

> This isn't theoretical: it's a direct implication of the claim they're making, an extraordinary implication, and one which deserves concrete evidence to back it.

Fair enough. Maybe they should change the claim to something like "Only two remote holes (known at the time of the fix) in the default install, in a heck of a long time!" Then again, isn't this what most readers would expect?

And on the Gemalto sim-card hack by the NSA and GCHQ: https://theintercept.com/2015/02/25/gemalto-doesnt-know-does...

"In the secret documents, provided by NSA whistleblower Edward Snowden, the intelligence agencies described a successful effort to obtain secret encryption keys used to protect hundreds of millions of mobile devices across the globe."

I think most of your posts are very informative. But your lack of knowledge about OpenBSD surprises me. Perhaps it would save you and the reader some time if you spent a bit more reading about OpenBSD instead of reasoning about all theoretical directions OpenBSD could have taken.

> I honestly don't see the evidence of widespread fear about discussing Edward Snowden.

It's not about Edward Snowden, it's about being more careful about discussing or retrieving information about any controversial topic because people now know, thanks to Snowden, that at least the NSA and GCHQ are watching you.

Curiosity and learning about things can be greatly hindered by prying eyes.

Yes, but especially controllability by the public at large and not only some designated institute.

Last Friday it became public knowledge that every visitor of any domain will be tracked by GCHQ for at least 30 days and up to 6 months depending on the website/person. Indexed by "which websites a person visits" and "which people visit a certain website".

https://theintercept.com/2015/09/25/gchq-radio-porn-spies-tr...

and the related discussion on HN https://news.ycombinator.com/item?id=10279853

This is what they call the global chilling effect. In this particular case this harms the knowledge people have about the Snowden case and why he currently is not returning to the USA.

> Voting machines could appear to work perfectly -- except during the first Tuesday of November, when it undetectably switches a few percent of votes from one party's candidates to another's.

Apart from difficulties having manufacturers publish their code I think another problem will be proving that some (open source) software is actually loaded in some piece of hardware and nothing else or extra. Most products on the market can be taken, teared down and tested for as long as needed. With voting machines the time to proof some software was active during elections and nothing else is the time you have before you officially publish the results. This is an extremely short window and impossible for a large part of the public to verify.

ps. just reading this in a post from Bruce Schneier[1] that is currently on the frontpage as well[2] which is about cheating software as used by car manufacturers and the IoT that is coming up:

    Voting machines could appear to work perfectly -- 
    except during the first Tuesday of November, when it 
    undetectably switches a few percent of votes from one 
    party's candidates to another's.

[1] https://www.schneier.com/blog/archives/2015/09/volkswagen_an...

[2] https://news.ycombinator.com/item?id=10304428

I was thinking of voting machines as well and think publicly verifiable code and hardware would be a good thing for cars (I don't think it's good enough for large scale elections, but that's another topic).

See this story about the need for open source for large publicly used systems: http://www.nytimes.com/2015/09/23/nyregion/volkswagens-diese...

use `cat -v installer.sh`

     -v      Displays non-printing characters so they are visible.  Control
             characters print as `^X' for control-X, with the exception of the
             tab and EOL characters, which are displayed normally.  The tab
             character, control-I, can be made visible via the -t option.  The
             DEL character (octal 0177) prints as `^?'.  Non-ASCII characters
             (with the high bit set) are printed as `M-' (for meta) followed
             by the character for the low 7 bits.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...

It's even a bit worse when looking at it from a fail-safe point of view. To turn the bluetooth and wifi off, 3.3 Volt has to be put on the pins. Giving no power on the pins turns both devices on.

I especially like to see this laptop because it's the first that I know of that can effectively turn off the microphone (for the webcam we already have stickers so this is less of an advantage, of course still laudable).

Though I think these hardware kill switches should not be optional. A product that praises itself for privacy and security should have this as a base feature instead of asking $89,- separately for it.

> i would be in favour of a separate Bluetooth and Wifi kill switch.

that's what I thought as well.

About the microcode, this won't be fixed. But see the weekly updates on their blog[1] that states progress they make with the coreboot developers. Hopefully they can free the number one problem with intel chips[2] which is the Management Engine firmware.

[1] https://puri.sm/posts/weekly-update-on-librem-production-201...

[2] http://www.coreboot.org/Binary_situation

> Emissions measured in road tests of 15 new diesel cars were an average of about seven times higher than European limits, according to a study ICCT published last October.

Curious what will happen in Europe the next coming years with respect to emission control and verification.

You're right and I believe WhisperSystems is doing something similar (or was at least working on it last year when I spoke with one of the developers). I vaguely remember them claiming that group chat is about the same as multi-device, cryptography-wise.

I specifically meant Telegrams E2E implementation. Apart from other problems with it [1] the fact that it's not on by default, as others have stated, makes that most people (especially non-technical users) don't use it.

[1] https://github.com/zhukov/webogram/issues/126#issuecomment-1...

> “If you have WhatsApp on your phone and your battery’s low and your phone goes dead, suddenly you can’t get access to your messages. It’s over. It’s not cross device. It doesn’t have cross-device sync. You can’t send documents or big media. There are lots of limitations in the group chats, in your communication. It’s not private. So I’m not sure I was a big fan of WhatsApp about three years ago, and I’m not sure I am now,” he said.

Unfortunately, E2E encrypted chat doesn't work when using these multi-device features, and so most contacts of mine don't use the privacy or security features of Telegram.

I know Postfix supports lmdb instead, format from OpenLDAP http://symas.com/mdb/

previous discussion https://news.ycombinator.com/item?id=10121464

/updated

> If I had to name the parts of Servo I'd love to drop, it wouldn't be what you think ...

Interesting.

> I think you're under the impression that new Web sites tend to avoid all the "goop".

Well as a web developer myself I do realize I'm adding a lot of workarounds, that's part of my frustration. It seems counterproductive for you guys as engine developers, and us web developers to use such an ever increasing amount of code just to work around stuff we throw at each other.

> Presumably for OpenSSH, if you control the server and it's properly configured you can drop the ugly, old code. Not so on the Web. Old and new Web sites alike rely on all sorts of corner cases.

Maybe for OpenSSH, but I think OpenSSL suffers from the same legacy compatibility issues as a browser. Still LibreSSL took an OpenSSH like approach by separating out all system specific exceptions from the base and put them in a different portability package.

> ... (ELinks, for example). You aren't using them because they don't support enough of the "ugly" features.

I'm not using elinks or other text based browsers not because they miss a lot of features, but because they're not as secure as I did expect from a text based browser[0]. They are still full of all sorts of features[1] that add to it's complexity without having enough value, imho. I think it's a feature to be not full featured.

[0] http://marc.info/?l=openbsd-tech&m=140516601718662&w=2 about gopher support in lynx

[1] Elinks: Full-Featured Text WWW Browser - Lots of protocols (local files, finger, http, https, ftp, smb, ipv4, ipv6) http://elinks.or.cz/about.html

> here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody.

OP here.

Totally right, because I didn't know how Servo is implemented, I've asked. Sorry for mixing in some emotion and hope about which answer I would get. I respect any developer doing any work and do realize it's all too easy to spread opinion without hacking on some solution.

Maybe as a non-contributor I should not have ventilated my opinion.

> If you want this to be viable, you need to convince Web authors to stop using the features you don't like.

Interesting point :) I guess what I'm talking about would be a niche browser. The one that currently comes closest to this is Xombrero[1], still delivering a lot of highly complex code because that's all we got nowadays.

[1] https://opensource.conformal.com/wiki/xombrero

The benefit would be that compatibility code (which can obfuscate the base a lot and take a large proportion of the code base) would be in a different branch or automatically added. Web developers could use tools like cssnext to automatically add all the goop without ever being distracted by it themselves. Less code needs to be reviewed, tested and maintained.

As for the engine side, the benefits would be the same like with OpenSSH etc. as mentioned in the GH issue. Unfortunately (or fortunately if he is right) a Servo developer thinks "this separation (if it’s even possible) sounds like a bunch of additional work with no benefit". I'm afraid this nice and shiny new engine will end up being complex and unmaintainable like all the others. Again this is speculation not based on facts, but experience with software development in general.

I guess mostly sandboxing? e10s is coming to Firefox, but per tab isolation might take a while (first step will be 1 process for the UI, 1 process for all tabs).

Another issue I have with browsing in general is that it's such a complex eco-system, there is simply no real secure webbrowser around that meets standards comparable with other secure software like RedPhone [1], Dovecot, Postfix, OpenBSD etc. All JavaScript engines are huge complex beasts (yes, V8 too), the new EcmaScript spec is 566 pages long[2], WebRTC and all it's required dependencies, xml, WebGL, etc. etc.

Even in order to be "only" compliant with modern specs, there is no escape from creating an extremely complex piece of software. This hurts real world security for everybody to the point where it might be better not to browse at all on machines with which you can access private servers or your private mail or conversations. It would be nice if there were some smaller browsers that didn't focus so much on backwards compatibility, but on leveraging the most important features so that most of the web could be browsed, still without sacrificing end-user security by implementing each and every feature and performance tweak. In the end, the OS and the browser should be trustworthy by the user.

[1] "Overall code quality: After reading Moxie's RedPhone code the first time, I literally discovered a line of drool running down my face. It's really nice." http://blog.cryptographyengineering.com/2013/03/here-come-en...

[2] http://www.ecma-international.org/publications/files/ECMA-ST...

isn't that exactly what DKIM is?

"DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature."

https://tools.ietf.org/html/rfc6376

Although I'm not a fan of it [0], there has been a commission to research the feasibility of electronic voting in the Netherlands. Outcome was it would not be cheaper than the current paper voting system and some fundamental parts still have to be on paper [1].

Currently they are researching the costs of implementing the proposed voting and counting machines (with human readable paper separating both machines). Also there was a preference for the software to be open source.

You could get in contact with some people of the commission:

https://twitter.com/cryptoron (part of the commission, now leads the costs investigation of the new proposed machines and software)

https://twitter.com/ArjenKamphuis (part of the commission and part of the hacker movement that got eVoting machines banned in the Netherlands in 2007 [2]).

[0] I don't think electronics outweigh the security of a paper based voting system anytime soon. Because of it's simplicity and transparency it's publicly verifiable in practice. Professor Halderman, who did a lot of research in electronic voting, won't expect secure electronic voting systems that can be used at large scale within the next 10 years, if ever: https://www.youtube.com/watch?v=JY_pHvhE4os#t=58m55s

[1] Unofficial abstract of the commission: https://www.kiesraad.nl/sites/default/files/every-vote-count...

[2] http://wijvertrouwenstemcomputersniet.nl/English

"Bonus points for wanting transparency and a system that's open source."

Transparency is not a bonus, publicly verifiable elections are a requirement for a healthy democracy to ensure power is legit. Open source does not really matter. Even if it's open source, it's hard to assure the public that "that open source software you downloaded from github" was actually running in a counting machine and nothing else (i.e. a custom made virus) at the moment of counting.