You do need HTTPS to protect mundane content: Saying otherwise is very short sighted...

You might not care about the content, but the way someone, somewhere, is accessing it, does offer a lot of "value".
It can allow a watchful eye to either accuse the reader of being outside the norm, criminal, not respectful and whatnot (reason why librarians fought hard for the right to lend books without giving the list to the state!) or allow them to caracterise, profile, target a person over time for many different reasons.

Thus everyone should have the to right to read anonymously and willingly.
Witholding this right from others is being complicit with opressors.

https://www.httpvshttps.com/

They should only go with custom code up to a certain extent. The organization should have the freedom to choose its own service provider (including volunteers). I'm probably stating the obvious, but if there is too much custom code they will be forced to spend a lot to rewrite code when volunteers rotate (and most likely will want to roll their own fancier solution), spend a lot of energy/time/money to maintain the code, or have difficulties finding volunteers who want to get involved in such a mess.

I don't know the specifics of your use-case, but CiviCRM is a Free Software contact relationship management software aimed specifically at non-profits. It has a large community of users and developers. While the community mostly operates on non-profit budgets, it includes users such as the FSF, EFF, Wikimedia, sub-orgs of UNESCO, Amnesty International, NY State Senate, etc. I use it for my small local clients, but I'm happy to be able to pool ressources with such organisations.

While turn-key tools can only do so much, you would probably have better chances of customizing that to fit your needs, and in the long term, the organization can turn to specialized service providers if necessary, without restarting from scratch.

Heck, worst case, if your volunteers are PHP-averse and don't feel like spending too much time customizing the application, you can write just a front-end application to it, and use the CiviCRM REST API to store the data. Writing a whole new application just for that seems like a huge waste of ressources, and does not seem sustainable. An event management tool has a ton of small but critical features to think about.

If they think it will be hard to learn an existing generic tool, imagine how hard it will be for new staff/volunteers to use a completely custom tool. Not to mention that if your organisation has an aim of promoting common good, community building, etc, they should also participate in existing Free Software projects :)

By FOSS do they mean dump the source after release... like Android?
I don't think that's the spirit, even though the licence says so.

Meta godwin aside, I wish a major (market wise) fork would exist with grsecurity merged in by default, for example...

Would be nice to have more details about that, and the proportion with IPv4 scans/crap.

Personally, I've been pleasantly surprised when going to the US, that random places (small motels, AirBNB places) had native IPv6. In some cases, they even had weird broken NAT, but working IPv6.

This migration to IPv6 has to happen one day or another. May as well be in front of the curve, with regards to privacy, security, topology and performance.

I don't even understand why china, of all places, is not 100% Linux wall to wall already...

Didn't know that. Thanks for the tip!

You can also use custom keywords with Bookmarks:
http://kb.mozillazine.org/Usin...

I alias google to "g", so when I want to search, i just type in the location bar: "g these are my search terms".

It's also practical to do Google searches in specific languages. For example, I use "ge" for google-english, "gf" for google-french, etc.

Just a random though: has anyone checked how long, and over what distance, the plane could fly from its cruise altitude once its engines stop ? If, in such a situation, the pilots tried something similar to what has been done with flight 1549 (https://en.wikipedia.org/wiki/US_Airways_Flight_1549), it might be an interesting approach to try to approximate a circular search zone (rather than an area).

OnlyCoin - was a weird idea anyway, throw away batteries piss me off!
Also, Canada has been using chips for a few years, with both debit and credit being seperate (to answer some comments about the "rest of the world").

nonsense.. that's a blanket statement that doesn't mean anything, implying that we should only consider absolutely secure solutions that will protect against all attacks. There is no one size fits all. Adding a layer of security that "will thwart MOST prying eyes" is well worth it, just don't expect it to be bullet proof and understand how it works, what it protects from.

If I recall correctly one of the initial aims of "https everywhere" was to protect people using public wifi. Hijacking FB accounts on public wifi became a common attack (and many others). It's a low-hanging fruit that encouraged a lot of websites to enable and fix their SSL for everyone.

Not to mention.. even if the NSA had keys from the major SSL cert vendors: you probably meant: they have the private key of Google/Facebook/etc, since the cert vendor key itself only signs the cert, it does not provide the private key that encrypts the communication.

Even then, don't use Google/FB. A lot of Snowden docs talked about tracking using the IDs from those services, although nothing has indicated that they have private keys of google/fb, it assumed that google/fb traffic was non-SSL. It's also a big leap to assume that they can generate/obtain private keys for other non-cloud services.

Will it be closed like Bittorrent-sync?

oblig xkcd: http://xkcd.org/1172/ ;)

Someone can't set their date properly? :P