slasaus

No buffer overflows, no user-after-free and no double free issues. There is a garbage collector which stops the world here and there to cleanup, but for anything that is not constantly busy, like a small mail server, this is not noticeable.

Author here, I'm currently trying to get mongovi into Debian, if anyone can help that would be highly appreciated. :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028418

I think this is huge. It reminds me of the early days of Firefox (back then still known as Phoenix) in a world where IE6 and pop-up ads dominated. At launch IE6 was really the best and most innovative browser of it's time (IMHO). But after IE6 had beaten Netscape, Microsoft stopped putting money in IE development and the situation got worse over time. It was Phoenix with, among other things, a pop-up blocker that was on by default that brought down Internet Explorers hegemony.

Today, with Chrome being dominant the situation is different because Google is still innovating Chrome at light speed. The one and only Achilles heel to beat this giant is by attacking their business model, which is to enable ad blocking by default. I expect this is something people want, just like pop-up blockers back in the days. Google will never be able to lead, or even follow in this direction without changing their business model.

Unfortunately, Mozilla’s own business model also heavily relies on selling ads, albeit indirectly. According to this statement from an independent audit report[1]:

"Note 10 - Concentrations of Risk:

Mozilla has entered into contracts with search engine providers for royalties which expire through November 2020. Approximately 93% and 94% of Mozilla’s royalty revenues were derived from these contracts for 2017 and 2016, respectively, with receivables from these contracts representing approximately 75% and 79% of the December 31, 2017 and 2016 outstanding receivables."

In other words, $539 Million, which is 93% of their total revenue, comes from companies that have selling ads as their business model (Baidu, Google, Yahoo and Yandex [2]).

I really hope Mozilla will be able to change this revenue stream to better align with their mission[3]. They have been trying to diversify their revenue since 2014 [4] and although they might not be as dependent on Google as they once were, they're still almost fully dependent on ads.

Oh, and yeah, of course simply making a better browser than Chrome would also help ;)

Background:

* https://www.mozilla.org/en-US/foundation/annualreport/2017/

* https://assets.mozilla.net/annualreport/2017/mozilla-2017-fo...

[1] https://assets.mozilla.net/annualreport/2017/mozilla-fdn-201...

[2] https://wiki.mozilla.org/Global_Search_Strategy_Status

[3] https://www.mozilla.org/en-US/mission/ "An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent."

[4] https://blog.mozilla.org/advancingcontent/2014/02/11/publish...

> That's not really the sort of decision application programmers should be making for sysadmins.

As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. It should live up to the standards of the time of release, not the time of the release of the first version (in case of OpenSSH that would be more than seventeen years ago).

As a sysadmin you can always decide to stick with an old version if that is what the environment you operate in demands.

I think this proactive mentality of OpenSSH is an important part of their success and why it has such a good track record from a security point of view.

> If you take the time to enter the voting booth when it opens and verify that the ballot boxes are empty at the start, and stay in the voting booth until it closes

Too late to edit my own post but please s/voting booth/polling station/ in the parent. Of course every voter should have absolute privacy in the voting booth in order to rule out coercion, but the ballot storage in the polling station should be publicly verifiable.

Knowing what one voted opens the door for coercion. Think of family members wanting you to vote a certain way. If you vote anonymously you can never prove to them what you voted, which protects the voter from any social, religious or other external pressure one might feel.

If you take the time to enter the voting booth when it opens and verify that the ballot boxes are empty at the start, and stay in the voting booth until it closes, you can verify yourself if everyone put at most one ballot in the ballot box. Later on you can double check if indeed every ballot is counted correctly and can thus conclude that at least your own ballot is counted correctly and exactly once without having to let anyone know what you voted.

How anonymous is your vote in the blockchain(s)? And how can you still verify the vote is counted correctly and exactly once while lacking hard proof to others about what you voted?

After trying json, yaml, json5, java properties, ini and toml, I finally choose hjson* as the configuration file format for the software I'm building. It's the easiest format to read and write IMHO, a bit like nginx config files.

* http://hjson.org

Really love the new persist option. It makes `doas su -` less compelling when you have to run multiple commands and use a complicated password.

Ok, just wondering, would "v=spf1 ?all" be the same in that case? I.e. a neutral spf policy?

Interesting note about DMARC, but still, if you're concerned about breaking forwarding for your domain, then why bother using spf at all? I still don't see the benefit of setting up ~all rules.

I think it's pretty weak they're advertising the use of "~all" in their spf records. Either use "-all" or just don't use SPF I would say. If you can't make a decisive statement about your own domain then it won't be actionable for receivers that evaluate your records.

FWIW, there is a petition for Intel to release an ME-less CPU design: https://puri.sm/posts/petition-for-intel-to-release-an-me-le...

(as mentioned in a comparable thread five days ago: "Intel and ME, and why we should get rid of ME" (fsf.org) https://news.ycombinator.com/item?id=11880935)

FWIW, there is a petition for Intel to Release an ME-less CPU design: https://puri.sm/posts/petition-for-intel-to-release-an-me-le...

    OpenSSL announced several issues today that also affect LibreSSL.

    - Memory corruption in the ASN.1 encoder (CVE-2016-2108)
    - Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
    - EVP_EncodeUpdate overflow (CVE-2016-2105)
    - EVP_EncryptUpdate overflow (CVE-2016-2106)
    - ASN.1 BIO excessive memory allocation (CVE-2016-2109)

    Thanks to OpenSSL for providing information and patches.

http://marc.info/?l=openbsd-announce&m=146228598930416&w=2

https://twitter.com/bob_beck/status/727478594591543296

(I've updated the parent about bypassing bgp/dns etc. before I saw your reply)

The nice thing about using the onion address (transport layer) is that you have mandatory e2e authentication with only one id that solves multiple real world problems with bgp/dns/tls.

How would you propose to go further from current state-of-the-art WhatsApp to stop leaking meta-data? I know Ricochet is open to use a stronger encryption layer on top of Tor †.

† https://github.com/ricochet-im/ricochet/issues/72

I can see that but I think the self authenticating nature of Tor Onion Services and therefore bypassing bgp, dns and CA weaknesses is worth something†.

Maybe in the future when prop224†† is implemented the encryption will be more solid.

† https://media.ccc.de/v/32c3-7322-tor_onion_services_more_use...

†† https://gitweb.torproject.org/user/asn/torspec.git/tree/prop...

Don't forget Ricochet†, it only does synchronous communication but it does solve the problem of leaking meta-data. All the other clients except Pond leak meta-data.

† https://ricochet.im/

My hardened ~/.ssh/config on OS X 10.11:

  Host *
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    HostKeyAlgorithms ssh-ed25519,ssh-rsa
    ChallengeResponseAuthentication no
    UseRoaming no

If you only connect to newer servers you can further restrict ciphers to only use AEADs (only list the chacha20-poly1305 and aes-gcm ciphers). I assume using AEADs-only makes the MACs keyword obsolete, is this correct?

Config is based on tips from https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

The client that wants to login always needs to execute a browser (or at least a render and JavaScript engine). See this (stalled) proposal to make it more compatible with non-browser/simpler agents: https://groups.google.com/d/msg/mozilla.dev.identity/L2ETKkd...

some signal cli clients were discussed on the mailing list yesterday: https://lists.riseup.net/www/arc/whispersystems/2015-12/msg0...

A downside with Ricochet is that it reveals when you are online to anyone who knows your id.

> Anyone with the onion address can still estimate availability by watching descriptors

https://github.com/ricochet-im/ricochet/issues/155

I'm currently using Proxy to transparently version data that is saved in an IndexedDB.

But isn't it that in practice most of the time this "last leg" is the only leg that crosses the internet? Most of the servers I see in the mail headers I receive are servers in the internal network of the sender. So IMHO transport encryption still is of real significance against passive attacks.

Only the OS can guarantee that some entropy is not handed out twice. If you can't trust your OS with that, you might have bigger problems.

> This is quite expensive compared to systems such as Civitas, but it is arguably, cheaper than the current system where governments often count vote ballots by hand.

Maybe cheaper, but I'm not sure if having to trust my computer with an important vote like that is better than having to trust a voting booth, ballot box and my eyes when the votes are being tallied. I think the slowness of manual tallying is a security property since anyone can inspect the computation while it's being run. All other technologies like Civitas, Scantegrity etc. are not cheaper but more expensive than this manual process and open up great possibilities for state level adversaries.

I think your system (using peoples computers) might be trusted when the stakes are lower though. Interesting project :)

Scantegrity, like other secure electronic systems, scores low on usability[1].

Recently the CEO of Fox-IT reported a delay to our minister in the Netherlands[2] with researching the specs for a usable and secure vote printer and vote counter[3]. It's not as easy as people think, especially the elder seem to have trouble with it.

[1] https://www.usenix.org/conference/evtwote14/workshop-program...

[2] https://zoek.officielebekendmakingen.nl/blg-604665 (Dutch)

[3] Unofficial translated summary of the report on large scale voting; proposes using a vote printer and vote counter with human readable ballots in between: https://www.kiesraad.nl/sites/default/files/every-vote-count... (English)

You mean something as trustworthy and tamper proof on a large scale as paper ballots and manual tallying? I still haven't seen any electronics that can be practically verified by the public comparable with the centuries old manual solutions that anyone can follow. Using electronics means getting a massive TCB with many orders of magnitude less the number of eyes that can actually inspect the computations being run (both because of organizational reasons and lack of knowledge).

According to Halderman* it might take us 10 years, if ever, to get machines the public can trust and verify on the scale that is needed for nation-wide elections.

Given the sorry state of current phone and laptop security, the problem of having a massive TCB is not solved, not with building on Ethereum either.

* https://www.youtube.com/watch?v=JY_pHvhE4os#t=58m55s

The article fails to argue that mass-surveillance is a required and proportional way to counter the threats mentioned. I think instead we should debate what level of suspicion should be required to form a basis to conduct a surveillance on someone instead of the "we have to monitor everyone including the innocent continuously" dogma.