I’m well aware of the difference between SMTP+TLS and PGP. I’m not missing the point at all. TLS & PGP have nothing to do with each other. They’re encryption at two different levels of the stack. You need to use both to get proper end-to-end encryption of message contents and to protect message contents not only from observers on the wire but also observers at the mail host.
TLS (done right) prevents MitM between Yahoo’s SMTP and (let’s say) Google’s. If Google’s server advertises that their stack deals with PGP correctly, Yahoo can use that as a cue to encrypt the message content and pass it over the already-encrypted TLS connection. The SMTP conversation would always be TLS encrypted, but a part of that conversation can signal to the sender that encryption at the message data level would also be handled properly by the rest of the software stack behind the receiving SMTP connection. That’s blurring the layers, but it’s not unreasonable for a primarily webmail host to signal their user agent’s capabilities as part of the lower SMTP conversation.
Granted, that’s piling on a lot more processing than would typically be done during the SMTP conversation, but it’s doable. You don’t even need the anyone’s private key at that point. The sender’s private was used to clear-sign every message sent (presumably in Javascript on the client side). If the sending SMTP server determines the remote can deal with it, then it needs to obtain the recipient’s public key and encrypt the clear-signed message to it before sending the PGP encrypted message over the TLS encrypted connection. The benefit there is that Google’s stack never gets to read the plaintext of the message.
Yahoo has led the charge before in enhancing email standards where bare SMTP wasn’t adequate. They were fairly early adopters of things like DKIM and helped push the industry to support it. If you want to do something that really does have a fallback route, it wouldn’t even take a standards change to have receiving SMTP servers advertise crypto as part of the SMTP capabilities response.
Granted, it’s a big hit to security if your message is encrypted or not based on the remote mail server, and there are ample opportunities for MitM attacks to cause crypto to be dropped where it might otherwise be supported (so we’re back to trusting TLS keys). That coupled with public PGP key registries offers some options for intelligent fallback behavior while still providing encryption for messages where both sides are capable of dealing with it.
Key management’s the thing here of course. If it’s on their server, NSA has it, etc. There are ways the key could be encrypted on server, decrypted only locally etc. Most of those have myriad ways the key could be mis-handled, leaked, etc.
That said, I’m kind of leaning towards this being a good thing, even if its implementation isn’t 100% paranoid geek approved secure. Ultimately if the NSA wants to read YOUR stuff, they’re going to (see: $5 wrench). If we assume Yahoo manages to implement this such that key retrieval is at least inconvenient (for $ufficiently large value$ of inconvenient) to anyone other than the account owner, then it should at least complicate NSA’s blanket “read all the things” approach. If it tips the balance back to the point that they actually have to expend more resources than your grandmother’s chocolate chip cookie recipe is really worth, then *maybe* they go back to only reading very interesting people’s emails without a warrant rather than reading everybody’s. I guess that’s worth half a point?
More importantly, if it manages to turn the seething mob of luddite Yahell users onto the fact that encryption is a thing, and explains to them why they want this thing, maybe the “winning hearts and minds” gambit is worth something to the world as a whole, even if the individuals’ email isn’t NSA-proof. Right now most mothers & grandmothers either have no clue what encryption is, or think it’s something only used by hackers, ter’ists, pr0n, criminals, etc. “Them” in other words. If Yahoo manages to convince a sizable portion of the voting public that privacy has worth, and encryption is a way to ensure that privacy, I think that’s a worthy outcome even if the encryption has flaws. Maybe that opens the door to conversations about the difference between effective and ineffective encryption. Maybe it even brings it closer to socially “normal” for someone who knows what effective encryption is to encourage others to use it without being assumed to be a nutcase or worse.
I hate to advocate selling snake oil, but there *are* an awful lot of squeaky snakes around. Maybe the right salesman can convince enough of the populace they need encryption, then we can worry about offering really good encryption for those adequately equipped to work with it.
I went through the same when I changed from glasses to contacts. I’d been wearing glasses for probably 5-6 years at that point. It did take getting used to, but the improvement in vision was more than worth it for me. It was probably the better part of a year before I dropped the nervous habit of pushing my (nonexistent) glasses back up my nose when I was thinking.
As for not going the laser route? Cost, possibility of severe complications resulting in blindness are higher than those of contacts, and the idea of sharks (assuming that’s where they got the lasers?) holding me down and cutting on my eyeball when I’m merely doped up a little as opposed to completely zonked? I’ll pass..
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.
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.
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.
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.
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 tha
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!
I tend to think that a candidate’s belief in an imaginary sky fairy who sends psychic messages to a man (never a woman!) in Rome that all his followers must comply with or else spend an eternity in burning agony is somewhat more material of a limitation to said candidate’s ability to lead than is the color of their skin.
You can say what you like about Obama’s religious beliefs or lack thereof; but all else being equal, a Catholic president of any race would cause me more concern (a goodly bit) than a non-Catholic president of any particular race (no concern whatsoever, at least for race, though other religious belief systems are equally or more troubling).
Personally, I’d substitute “Catholic” with “devoutly religious, any denomination,” but since we started talking about JFK...
Sotomayer thinks that the states’ voters should not be able to make that determination but that instead it should be incontrovertible policy pushed down by the Federal government leaving the states powerless to modify it.
The decision wasn’t made on the basis of whether racial qualifications should be allowed or disallowed. It was made based on whether that determination is allowable to make at a state level.
Now, I tend to agree that furthering the cause of Federalism run WAY over its intended bounds in favor of the Feds against the states is despicable, so our overall views of Sotomayer are in line, but at least cast aspersions for the correct reasons.
What exactly do you think paying non-citizens less to do the same work Americans could do accomplishes in terms of net positive?
I don’t dispute your assertion that allowing more H1B’s would drive down tech salaries, but as a tech worker NOT among the six-digit salary range myself, I can’t conceive of a possible way that’s a good thing.
That said, having interviewed a number of H1B candidates, I’m of the impression that adding more marginally skilled labor to the labor pool doesn’t help anything at all. Highly skilled people demand high salaries. At least for the H1B candidates who have come my way, they’re no better in aggregate than the “average” non-H1B candidate. Quite a few of them are significantly less skilled in the areas we’re looking for.
Opening the floodgates to throw more “resources” at the problem doesn’t help the fact that exceptionally skilled programmers are (well...) exceptional and generally difficult to find. Compensating them commensurate with their skill is good business sense since if you lose them, your odds of finding more are slim.
Slashdot Mirror
I’m well aware of the difference between SMTP+TLS and PGP. I’m not missing the point at all. TLS & PGP have nothing to do with each other. They’re encryption at two different levels of the stack. You need to use both to get proper end-to-end encryption of message contents and to protect message contents not only from observers on the wire but also observers at the mail host.
TLS (done right) prevents MitM between Yahoo’s SMTP and (let’s say) Google’s. If Google’s server advertises that their stack deals with PGP correctly, Yahoo can use that as a cue to encrypt the message content and pass it over the already-encrypted TLS connection. The SMTP conversation would always be TLS encrypted, but a part of that conversation can signal to the sender that encryption at the message data level would also be handled properly by the rest of the software stack behind the receiving SMTP connection. That’s blurring the layers, but it’s not unreasonable for a primarily webmail host to signal their user agent’s capabilities as part of the lower SMTP conversation.
Granted, that’s piling on a lot more processing than would typically be done during the SMTP conversation, but it’s doable. You don’t even need the anyone’s private key at that point. The sender’s private was used to clear-sign every message sent (presumably in Javascript on the client side). If the sending SMTP server determines the remote can deal with it, then it needs to obtain the recipient’s public key and encrypt the clear-signed message to it before sending the PGP encrypted message over the TLS encrypted connection. The benefit there is that Google’s stack never gets to read the plaintext of the message.
Yahoo has led the charge before in enhancing email standards where bare SMTP wasn’t adequate. They were fairly early adopters of things like DKIM and helped push the industry to support it. If you want to do something that really does have a fallback route, it wouldn’t even take a standards change to have receiving SMTP servers advertise crypto as part of the SMTP capabilities response.
Granted, it’s a big hit to security if your message is encrypted or not based on the remote mail server, and there are ample opportunities for MitM attacks to cause crypto to be dropped where it might otherwise be supported (so we’re back to trusting TLS keys). That coupled with public PGP key registries offers some options for intelligent fallback behavior while still providing encryption for messages where both sides are capable of dealing with it.
It doesn’t necessarily need to do en-/decryption on the server side. Javascript is more than adequate to perform the necessary math.
Key management’s the thing here of course. If it’s on their server, NSA has it, etc. There are ways the key could be encrypted on server, decrypted only locally etc. Most of those have myriad ways the key could be mis-handled, leaked, etc.
That said, I’m kind of leaning towards this being a good thing, even if its implementation isn’t 100% paranoid geek approved secure. Ultimately if the NSA wants to read YOUR stuff, they’re going to (see: $5 wrench). If we assume Yahoo manages to implement this such that key retrieval is at least inconvenient (for $ufficiently large value$ of inconvenient) to anyone other than the account owner, then it should at least complicate NSA’s blanket “read all the things” approach. If it tips the balance back to the point that they actually have to expend more resources than your grandmother’s chocolate chip cookie recipe is really worth, then *maybe* they go back to only reading very interesting people’s emails without a warrant rather than reading everybody’s. I guess that’s worth half a point?
More importantly, if it manages to turn the seething mob of luddite Yahell users onto the fact that encryption is a thing, and explains to them why they want this thing, maybe the “winning hearts and minds” gambit is worth something to the world as a whole, even if the individuals’ email isn’t NSA-proof. Right now most mothers & grandmothers either have no clue what encryption is, or think it’s something only used by hackers, ter’ists, pr0n, criminals, etc. “Them” in other words. If Yahoo manages to convince a sizable portion of the voting public that privacy has worth, and encryption is a way to ensure that privacy, I think that’s a worthy outcome even if the encryption has flaws. Maybe that opens the door to conversations about the difference between effective and ineffective encryption. Maybe it even brings it closer to socially “normal” for someone who knows what effective encryption is to encourage others to use it without being assumed to be a nutcase or worse.
I hate to advocate selling snake oil, but there *are* an awful lot of squeaky snakes around. Maybe the right salesman can convince enough of the populace they need encryption, then we can worry about offering really good encryption for those adequately equipped to work with it.
I went through the same when I changed from glasses to contacts. I’d been wearing glasses for probably 5-6 years at that point. It did take getting used to, but the improvement in vision was more than worth it for me. It was probably the better part of a year before I dropped the nervous habit of pushing my (nonexistent) glasses back up my nose when I was thinking.
As for not going the laser route? Cost, possibility of severe complications resulting in blindness are higher than those of contacts, and the idea of sharks (assuming that’s where they got the lasers?) holding me down and cutting on my eyeball when I’m merely doped up a little as opposed to completely zonked? I’ll pass..
We already have a EULA for video. It’s called “Fair Use.”
If the broadcaster does not agree with that, they are instructed to stop using public airwaves to disseminate their content and go out of business.
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 tha
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.
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!
Here goes my karma out the window...
I tend to think that a candidate’s belief in an imaginary sky fairy who sends psychic messages to a man (never a woman!) in Rome that all his followers must comply with or else spend an eternity in burning agony is somewhat more material of a limitation to said candidate’s ability to lead than is the color of their skin.
You can say what you like about Obama’s religious beliefs or lack thereof; but all else being equal, a Catholic president of any race would cause me more concern (a goodly bit) than a non-Catholic president of any particular race (no concern whatsoever, at least for race, though other religious belief systems are equally or more troubling).
Personally, I’d substitute “Catholic” with “devoutly religious, any denomination,” but since we started talking about JFK...
False.
Sotomayer thinks that the states’ voters should not be able to make that determination but that instead it should be incontrovertible policy pushed down by the Federal government leaving the states powerless to modify it.
The decision wasn’t made on the basis of whether racial qualifications should be allowed or disallowed. It was made based on whether that determination is allowable to make at a state level.
Now, I tend to agree that furthering the cause of Federalism run WAY over its intended bounds in favor of the Feds against the states is despicable, so our overall views of Sotomayer are in line, but at least cast aspersions for the correct reasons.
What exactly do you think paying non-citizens less to do the same work Americans could do accomplishes in terms of net positive?
I don’t dispute your assertion that allowing more H1B’s would drive down tech salaries, but as a tech worker NOT among the six-digit salary range myself, I can’t conceive of a possible way that’s a good thing.
That said, having interviewed a number of H1B candidates, I’m of the impression that adding more marginally skilled labor to the labor pool doesn’t help anything at all. Highly skilled people demand high salaries. At least for the H1B candidates who have come my way, they’re no better in aggregate than the “average” non-H1B candidate. Quite a few of them are significantly less skilled in the areas we’re looking for.
Opening the floodgates to throw more “resources” at the problem doesn’t help the fact that exceptionally skilled programmers are (well...) exceptional and generally difficult to find. Compensating them commensurate with their skill is good business sense since if you lose them, your odds of finding more are slim.
Well... Except for those making seven or eight digit salaries, but they pretty much get what they want anyways.