While it’s true that they will open a physical safe themselves if you refuse, you can indeed be held in contempt if you have the ability to open a safe and refuse to do so when presented with a valid warrant. The “physical safe” analogy is one of the things that’s (unfortunately) applied as an existing-law analogy to crypto.

The distinction is that in order to get a warrant on the safe, they need probable cause that what they’re looking for (with a degree of specificity) is actually in the safe. That’s less clear with an entire hard drive (though if they’re looking for emails, the supposition that they’re on a hard drive isn’t much of a stretch). In this case, the guy admitted what they were looking for was in the “safe” and he know how to “open” it.

Seems pretty much like he screwed himself.

Just use TrueCrypt on Windows XP. You should be fine.

I confess. My backups are untested. You got me. Put the cuffs on!

Government spooks knocking at your door (virtual or physical) does tend to result in symptoms similar to having a nervous breakdown.

It’s technologically possible to fork the code base, but if the license as provided with the last (useable) version is an impediment to that (and my reading of said license (IANAL) suggests it would indeed be problem), then you can’t fork the code legally. A fork that nobody can legally use isn’t of much value outside certain small circles.

TrueCrypt was source-available, but it wasn’t Free Software in the RMS sense by any means.

Who gets to decide? Appointed bureaucrats at the US Patent & Trademark Office. That’s who.

Where on earth did you get the idea that the 1% actually pays for government operations?

http://www.cnsnews.com/news/ar...

Won’t comment on unsubstantiated “senior developer” claims, but as for the encrypting malware issue, recovery of older versions of Cryptodefense was possible because the malware itself had a bug which leaked the necessary decryption keys somewhere on the target system. After the bug was made public, future versions of the malware fixed it and are no longer recoverable using that technique. It wasn’t a Bitlocker backdoor or similar. Not that I have evidence to contradict the existence of such backdoors, but the particular malware case didn’t rely on one.

http://www.symantec.com/connec...

Nerds, (perhaps I overgeneralize, but programmers certainly) make a career of looking at things that might technically be “working,” and trying to make them better. We optimize code to make it run faster, use less resources. When someone points out a problem (“Hey, you should do that outside the loop, and it’ll run O(N) faster”) most of us can accept it as the beneficial feedback it is, fix the problem, and carry on. We’re used to accepting our own human failings and doing the best that we know how within our limitations, ever improving.

We do the same to ourselves. When someone points out a problem in our world view (in the present example, our attitudes towards women), where many would reject such criticism as a personal attack and vehemently deny it, nerds (at least the good ones) make a daily habit out of acknowledging, “I screwed up, how can I make it better?” This is just another example of that.

I think when an issue like this is directed at us, many of us will take an honest look at our past and daily interactions, see situations that we could have behaved better, and accept the assertion that we are (or have been) complacent in rape culture, misogyny, etc., and we want to be better. Compare that to the population at large that would be much more likely to dismiss it and continue set in their ways.

That’s not to say as a sub-culture we’re inherently better or worse than any other group (my own observations agree that on the whole we’re better than many, worse than some), but we’re much more willing to self-label and own our behavior.

I’ll be you my iCloud password, it’s a re-wrap of this:

http://soylentnews.org/article...

If you can MitM a “consenting” user to unbrick a stolen phone, I can’t see any reason it doesn’t work the other way around.

Honest question: Do NSAIDs reduce actual, long term growth in muscle, production of new muscle tissue, etc., or do they just reduce the swelling that gives you that “pumped” look after a hard workout without actually affecting growth and development? (Or as follow-on, is the “pumped” thing more than just appearance & the swelling is what actually stimulates muscle growth?)

Looking pumped is nice, but if it’s just aesthetic, not hurting is nice too. If it’s a hinderance to actual muscle development, then it makes more sense to push through it and get more benefit for the time & work spent.

Seconded! Filemaker is distinctly inferior to MS Access, and still proprietary/non-free. (And not especially inexpensive either.)

I wish I had a better approach to offer. Of the two, Access is a MUCH better option. Excel is also better.

I was actually in this same boat about a year ago. US-based (so somewhat less complicated) non-profit needed a system for tracking paid memberships. I looked at various off-shelf CRM-type packages, church congregation management software, and a few related fields. The complexity level of all of them was orders of magnitude beyond what they needed or what they’d be capable of learning; and yet they still managed to fall short of a few of their more unique needs. Implementing any of them would have required some degree of customization (IE bespoke coding) which would have complicated upgrades, reduced others’ ability to maintain them, etc., all while leaving them with a complicated beast they’d never really understand.

I ended up writing something in ${PROGRAMMING_LANGUAGE_OF_CHOICE} (doesn't make any difference what language you choose - nobody on staff for the org is a coder) and hosting it on OpenShift. It’s still in use, and it’s needed relatively little maintenance, but it’s definitely the kind of creation you’re going to be paying child support on for a long time. I’m always on the look out for something simple off-shelf that will do what they need for membership tracking and not be “mine,” but the available software isn’t materially easier to maintain than what I built and being orders of magnitude more complicated to use is a deal breaker.

As far as lessons learned... I'm a Java coder by day (go ahead, get your free shots in... I can take it...), and decided to do it in that as a convenience to me. We use Wicket framework at work, and I used that with Tomcat and MySQuirreL as DB. The experience of writing it was pretty good all things considered. It's well-architected (IMHO...), clearly written, little to no design debt. I took the time to clean up after myself since there wasn't really a deadline, so it's really just what they need but reasonably easy to extend if need be.

The problem with it is free or even reasonably priced Java hosting is a bit hard to come by. They have a (small) tech budget, so free wasn't an absolute requirement, but cheaper was definitely better. I tried AWS initially, but the tiny instance was too short on RAM to run the thing effectively, and it was way too slow and not especially cheap. The bigger instance sizes blew the budget completely. I ended up on OpenShift (which ironically is itself on AWS, but they pay the bills, not us...), and that's a little bit better performance-wise. It's still not super fast, but it's a back-end only system. It runs well enough. I'm still concerned about relying on a free/beta service that could go away; but I'll burn that bridge when I come to it.

In hindsight, I should have done it in PHP so they could run it on their Dreamhost site (also by no means fast, but at least paid for). It was one of those decisions where the value of the free time I was donating gave me a certain amount of leeway to take the path of least resistance (for me the programmer) at the expense of more difficulty hosting it. I don't think that was the right decision, and I'll probably end up redoing it in PHP at some point.

To summarize:

I'd say if you can possibly distill their needs to something simple that will fit in a spreadsheet, S/O/L Office (I like that...) is likely to provide the longest useful life for them and the least amount of support for you. If their needs really and truly can't fit into a spreadsheet, honestly they're getting to the point where they need to scratch up an IT budget or simplify their needs to meet the reality of what they can afford.

If you MUST develop something bespoke, the worst thing you could do is choose ${FRAMEWORK_OF_THE_WEEK} or any environment that needs more than a minimal bog standard LAMP shared hosting solution. Anything that requires you to install a machine-level framework, alter the system-wide Apache configuration, etc. is going to greatly increase cost and decrease flexibility. It's against your organization's best interests to do that. The lowest common denominator for cheap hosting is LAMP, so stick with that.

If you do write something by hand, consider you're adopting a puppy. You're going to be caring for this thing for years. If you're not prepared to do that, it's irresponsible and unprofessional for you to push them in that direction.

In my case, the org is a local group with a mission I care strongly about, so short of significant unforeseen life events, I'm in it for the long haul.

It doesn’t (necessarily) need to be, though it would be nice. If the Android-level interface to the baseband is sufficiently limited, and if all “secure mode” operations (encryption) are handled purely in Android and passed off as a ciphertext stream through the baseband, a subverted baseband would have limited ability to cause issues.

Problems for an untrusted baseband are:
1) If the OS will (or can be forced to) accept any type of control from the baseband (rather than exclusively the other way around), the baseband can take over the “secure” OS.
2) The baseband can leak private information passed through it to a third party.

Note that as a special case of #1, audio stream communication between baseband and OS is often implemented as some variety DMA or shared memory. Care would be required to ensure the baseband was incapable of reading or writing any portion of system memory other than what was explicitly setup by the OS for DMA. A hardware MMU or even physically separate DRAM circuitry could ensure this.

So long as the baseband has no avenue for exerting control over the OS, the OS can’t be tainted by a subverted baseband. If all information passed through the baseband in indistinguishable from entropy, the baseband funneling it off somewhere else has limited value absent some other attack on the crypto (including $5 wrench).

The last remaining attacks would be location leaks (which can be carried out against even an untainted baseband with CellCo assistance anyway) and the possibility of injecting forged traffic that might trick the user into doing something insecure. Well-designed UI should ensure that cryptographically authenticated communications are always distinguishable from untrusted.

Not saying having a fully open baseband wouldn’t be a really nice thing, but there are well established and sufficiently secure ways for sandboxing an untrusted baseband within an otherwise secure design.

acceleration up an inclined highway on-ramp [ ...] as it will not yet be up to speed when it comes time to merge

Dear Finagle, I wish drivers around here knew that’s what the on-ramp is FOR. Daily occurrence that someone tries to creep into 65MPH* traffic going maybe 30-something after putting their way downhill on a 1/4 mile long on-ramp.

Use that long skinny pedal on the right, KTHX?

* And of course everyone is going precisely 65, no more...

A car built from this would run from two different power sources: electricity direct from grid to battery and gasoline (or possibly other liquid/gas combustable fuel) used to produce electricity, possibly to battery, possibly direct to electric motor with no intervening storage at times of high power requirements.

It’s perhaps less “hybrid” than running with gasoline direct to drive plus electric motors, but it still seems fair to apply the word. Contrast to something like Leaf or Tesla which are solely fueled by electricity from grid to battery to motor.

I’m also mostly guessing that a much simpler cylinder system might be able to adapt to running from multiple fuels in a single engine with minor fuel injection / ECM accommodations. That could further hybridize it if you could put gasoline, diesel, or even a gas cylinder of propane on the car and run from whatever’s cheapest.

And best yet, ISP’s will have an excuse to charge you extra for not-upgrading their infrastructure so you can continue to do what you already do for additional cost and no material improvements to your service. Brilliant!