It's not really a significant factor here - the Botan build system allows you to select what features you want to include. For example if you wanted a binary that just supports AES, GCM, SHA-256, and ECDSA, with nothing else, that's easily done.
It's not just only limited to commercial spyware. It's limited to restricting "commercial spyware that poses significant counterintelligence or security risks to the United States Government", ie they should only use high quality commercial spyware.
18992.1(b) excludes UBI for anyone "receiving benefits under the Medi-Cal program, the County Medical Services Program, the CalFresh program, the CalWORKs program, or Unemployment Insurance" so if you are currently receiving any form of welfare, f you, otherwise here's your free money? Seems like a really strange approach for something that is trying to improve economic security. Does anyone know what the reasoning here is?
The most resilient case for UBI (by that I mean that it blunts more criticism) is that cash transfers are cheaper to administer and arguably more effective than welfare programs. I thought it was odd that this wasn't proposed to entirely replace those programs with a simple to administer system (no verification of income, no verification that you're looking for work, etc) that still "delivers" the benefits already received by people covered by existing programs. This proposal definitely seems framed poorly...
If you look at the individual market for health insurance, premiums, deductibles and co-pays will exceed the total UBI benefit. Medicaid sets group rates that it will pay, so it is more efficient at reducing costs. I can't imagine that using UBI benefits to pay for health insurance on the individual market would be more effective than such a program.
I think the proposal is by far weakest in tying it at all to healthcare. Maybe UBI could be used to improve our health insurance headaches, but I was speaking specifically about things like unemployment benefits, CalFresh, etc. Things that are already just cash transfers but require an (arguably) bloated and too expensive bureaucracy to administer.
Isn't this a core tenet of all UBI proposals - it's an alternative to other aid programs, not a supplement to it. That's the only way it can possibly be economical.
So either they kill off medi-cal, calfresh, and calworks, or they keep them around but disallow any "double-dipping". It seems like they've chosen the politically safer option of not killing the competing aid programs completely.
Tried the test site on a Nexus 7 running Android 6.0.1, Firefox was ok (seems it ships with its own list of roots), but latest Chrome rejected it.
My wife runs a blog which generates substantial income and uses certs from Let's Encrypt. It's a non-tech blog with primarily US readership. Checking stats for this month, 7% of all visitors were using Android 4/5/6 (20% of all Android users). The percentage of users on old Android running Firefox was basically nil. Losing all these users would be very costly.
Hopefully certbot will be modified so it is possible to pick the current intermediate during automatic renewal. If I have to do a manual operation to switch intermediates each time the cert renews (currently done by cronjob) then it is probably safer (operationally speaking) to just buy a cert.
I don't really understand why Let's Encrypt is making this change now. Sure, the current root is expiring "soon", but not until September 2021. Switching roots could be safely pushed off to early 2021 at which point hopefully most of these older Androids would be cycled out.
Solar panels don't depreciate in the same way as most silicon. 20 years later, panels will still be producing power just fine, albeit with some degradation.
Source: my house has 23 year old solar panels, my garage has 10 year old panels, they all still produce plenty of electricity.
There are plenty of reasons to avoid dealing with these companies, but this isn't one of them.
I've been flown to interviews at least a half dozen times over the years, mix of startups and big companies, every time travel (flight+hotel+meals) was covered as a matter of course. I would absolutely turn down an interview where they weren't paying for travel, it suggests they are not serious about the process.
The existing Botan C API is in fact sufficient for OpenPGP already, https://github.com/riboseinc/rnp is in C++ now but was originally C and uses Botan's C API.
But Nettle is IMO quite solid and the developer is very skilled, so full steam ahead.
Is there any relation between Sequoia and the BoringPGP spec?
Yes, I'm a co-author of BoringPGP[1]. Sequoia itself will probably support it as soon as Marcus and I get around finishing the spec but it's not part of Sequoia and I only work on it in my free time.
Been working remote in Vermont for a decade now. Love it here and now that we have kids I'm not even considering moving anywhere. Nature, plenty of space, cheap (at least by major city standards), good food and beer scene, people are friendly, good schools if you pick the right town.
My only complaints would be slow Internet (though fiber is more common these days) and the ticks. And it gets cold sometimes, some people don't like that.
