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 ;)
[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."
> 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.
I disagree with bandrami in this case, but I don't think this is quite right either because you focused on an instance-specific goal rather then universal principle:
>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.
There is plenty of software where secure usage is not a concern and that's fine. Rather, it would be better to say that as programmers we have the job to ensure that our software is as fit for primary expected purpose as possible, and in particularly lacks any surprising gotchas. Sometimes within a given program's core purpose there are decisions that can only be properly made as part of deployment/usage and those are appropriately left to the sysadmin/user, but if something is directly contrary to core purpose then it's always worth questioning whether it needs to change.
In the case of OpenSSH in particular the core purpose is in fact secure links. We've all long had an insecure very fast virtual terminal system if we wanted it and it's called Telnet. There is no reason that any available built-in mode of OpenSSH crypto should ever be insecure. Asking to have obsolete methods generally considered to no longer be reliable to be "left up to the sysadmin" would be like asking it to have rot13 as a sysadmin option: completely contrary to the purpose and expected function of the program. Not just in security but in software in general any extra switches carry both developmental load (more code to go wrong), deployment load (more possibilities to make mistakes) and cognitive load, so they should always be considered to have inherent negative value and then asked to justify themselves, not considered to stick around forever by default.
Deprecating ciphers I'm fine with. Telling me a minimum required key size isn't, because they have no idea what the window of security I'm looking for is. If I need to keep a text secure for 2.5 seconds, a short key is fine, and for that matter a longer key gets logistically problematic.
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.
> 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.
> nice. election day isn't even a holiday in america.
First of all, there are fifty elections in the US (not counting territories like Puerto Rico and Guam). Each state runs its own elections separately and can decide on their procedures.
Secondly, some jurisidctions already experimented with making election days a holiday. Aside from the fact that this only affects government employees (private businesses set their work schedules at their discretion, just as they do for other holidays), this ended up decreasing turnout, because people ended up taking the previous day off, treating it as an extra-long weekend for travel or vacation.
Third, this is a moot point when most states (34/50) offer early voting, and three more vote by mail, making "election day" rather arbitrary. It's really the last date on which someone can cast their vote. Those states also include three of the four largest states, meaning that the vast majority of people in the US have the option to vote well ahead of election day.
(For the record, the states which have neither early voting nor no-excuse absentee voting are Alabama, Connecticut, Mississippi, Kentucky, Virginia, Missouri, Michigan, Pennsylvania, South Carolina, Rhode Island, New Hampshire, and New York)
Usually because there's a fine line between "poll watching" and "poll intimidation" and people generally aren't quite civilized, thoughtful, or well-mannered enough to stay on the good side.
That includes "shouting racial slurs" in your first link.
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?
This paper shows you know to achieve exactly that. You can vote anonymously and receive a proof that your vote was counted correctly, without ever telling anyone what that vote was. To prove that your vote was miscounted, I believe you do need to reveal who you voted for, but you can prove to the world that there was fraud.
This paper solves one of the major problems with blockchain based voting, but there are many more. I don't endorse blockchain voting.
Perhaps all voting should be public. All voting 100% public. 0% funding from any source other than individual citizens. And even that should be heavily capped. So each individual citizen over 18 can give say $100 dollars and that's it.
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.
So I guess ballots should be anonymous. So how to do that with a blockchain. Well simply by assigning some random number or hash to the voters that no one else knows.
Selling votes is not a problem. Secretly selling votes is the problem.
Perhaps it would be better to turn the vote-selling market into a publicly verifiable open market?
If I say that it would cost a buyer $10k more for me to vote yes than the highest open bid for me to vote no, that is a strong quantifiable indication of the magnitude of my opposition. I'm sure the vote-pricing data would be a gold mine for statisticians.
Of course, this would make the plutocratic oligarchy operate out in the open, officially, rather than behind the scenes with lobbying, campaign contributions, and speaking fees. Some people might find that objectionable: both those who do not want a plutocracy and those who do not want their money influence on politics to be openly known.
No, even public vote-selling is a problem, because it muddles incentives. No one should have to vote against their best interests in the long term for short-term financial gain. This leads to exploitative behavior of vulnerable population groups.
If you can not possibly reveal your vote (like with the ballot box) you can not sell your vote.
If I say you can forget the $10k for your vote and accept that you either vote for my preferred candidate or you're fired/beaten, suddenly the secret ballot starts looking like a good idea again.
And that's even before we conclude the preferred candidate of the plutocratic oligraphy would actually be massively aided by being able efficiently purchase the votes of the indifferent rather than having to inefficiently purchase airtime to convince people their candidate actually has merit.
(And of course they'll still be able to continue to organise their vote-buying operations through shadowy umbrella organizations to the extent they can be bothered to disguise who they want to win)
Selling votes is obviously a problem, but more practically, is it even possible to make something possible to sell publicly, but impossible to sell secretly?
Upvoted, not because I agree, but because if we adopt electronic (mediate) systems, full transparency is the only way to at least mitigate the disaster.
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.
I find the implementation very compelling too - it uses kernel support. That really simplifies an otherwise very complicated and security-sensitive code path.
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.
If you use DMARC with a reject or quarantine policy, SPF hardfail ("-all") can prevent recipients from successfully forwarding mail you've sent them.
Some best practices for DKIM, SPF, and DMARC (as of mid-2015) in [1], including this:
> ...when an organization publishes p=reject [in DMARC], they should simultaneously change their SPF hard fail to SPF soft fail. ... A message that passes SPF and is forwarded will fail SPF. If a message hard fails SPF it will probably be marked as spam but if it soft fails, it will most likely still be accepted by the recipient. This forwarding failure possibility is why most organizations publish a soft fail record.
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 believe that DMARC requires SPF. Since I want DMARC, I need to provide a compatible SPF, which means ~all.
(And I do want to implement DMARC. Not so much to improve deliverability of my own email, but rather to prevent delivery of malicious email pretending to be from my domain.)
Create a TXT record containing this text: v=spf1 include:_spf.google.com ~all
Publishing an SPF record that uses -all instead of ~all may result in delivery problems. See Google IP address ranges for details about the addresses for the Google Apps mail servers.
That's a totally fair point. I'm not entirely sure why most third parties are still using ~ in their documentation but it still seems to be the norm. I do like the definitive nature of -all.
IIRC ~all is the recommendation because hotmail/live told people to use ~all to prevent hardfails when hotmail's lookups timed out or if a particular mailserver IP was inaccessible during spam checks.
~all will result in your email being bounced around until accepted even if the IP doesn't match DNS records (more or less).
-all will result in hardfail if rejected by any TO mailserver.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028418