I recently got back into the dating pool myself (Austin, early 30s), and can't say that my experiences are similar.
The women who initiated contact without solicitation have often done just as you described (and not really been a sort I was very interested in) -- but those who have gone to the effort to respond to my (longer, well-written) messages have universally responded in kind.
Then again, I don't know what target age and audience you're dealing with; if it's the early-20s crowd, I'd be very unsurprised.
You can not expect everything to be secure. You have to pick and choose your battles. Workers must have some freedoms. Most of the stuff they do should be easy. Difficulty should be reserved for where it is really needed.
I'm talking about end-to-end encryption -- your jump into password policies is just bringing up the Mordok the Preventer strawman.
Using TLS for your internal services doesn't make users' lives worse; for that matter, a number of technologies offering end-to-end encryption and authentication make users' lives better by offering single-sign-on capabilities (see: Kerberos) while doing host- and service-level authentication and encryption in the background. Having your hard core kerberized means no additional hoops to jump through on login, but ensures that your backend services are able to determine that their access is eventually tied back to an active and valid session.
Fighting any and all attempts at defense-in-depth because some people do it horribly wrong is simply misguided.
If the attackers place a network sniffer on a customer's internal network...
You've got a hell of a lot bigger problems than pcAnywhere.
Au contraire -- if your infrastructure isn't robust against this class of attack (all internal traffic authenticated and encrypted, particularly during password exchange), you're Doing It Wrong.
Moreover, the concept of "defense in depth" applies -- a hard outer shell with a soft inner core means that when the eventual successful attack does happen (and it will!), the damage is that much worse. You can't have decent security if you design all the internal components assuming that the outer layer will protect them.
Assuming electricity for your segway is free (HA!)
Not that far from it. I don't have numbers on the Segway, but for the e-bike I used to own (45 mile range on 1.2kWh of electricity including charger and battery losses), that's much, much less than $35/year for a full charge every day at the highest residential rate (middle of the summer, above the first 500 kWH).
If you were to pick the very end of the pregnancy as the most obvious place, then you have chosen the line that has the highest risk of killing a human, if it turns out that babies become humans at some stage in the pregnancy. I personally think the stakes are too high - there's a reasonable chance that late term abortion is killing a human, and given the reasonableness of that chance we should be erring on the side of caution. Your suggestion is throwing caution to the wind.
This argument assumes that the definition of when a set of cells which may eventually become a child is or isn't human is something which objectively exists regardless of the decision we're seeking to make here.
Simply put, I can't accept that assumption. We're making that decision, ourselves, right now; that's what this debate is about. Deciding what is or isn't morally wrong is what we're trying to decide -- but how can the result of this moral decision be objectively incorrect?
You don't own your copy of Ubuntu. You don't own the copyright.
You have that backwards. You do own your copy, even though you don't own the copyright. Not the case for software that's "licensed, not sold" (if your jurisdiction recognizes EULAs), but Free Software licenses don't tend to pull that kind of BS, only regulating actions (such as making copies or preparing derivitive works) that copyright would prevent even if you fully and properly owned your copy, thus avoiding any incentive for the "licensed, not sold" silliness.
Think of it as if you were buying a book. You don't own the copyright just because you own your copy of the book, but you certainly do still own that copy.
How about the 'right to work law' in Indiana (which is designed to eliminated 'closed shops'--where every eligible employee is required to be a union member if there is a union)
Living in a right-to-work state... well, let's say there's a reason those laws are colloquially known as "right to fire".
I'm not saying that the all-employment-is-at-will approach is wrong, necessarily, but it certainly has side effects that your blurb above skips over.
Trying to attribute this potential attack vector exclusively to PhoneGap
And, speaking of intellectual dishonesty, where did I do that?
I didn't say it wasn't an issue for native apps, I said "not as much as [the parent] indicate[s]", ie. less of an issue for native apps than for PhoneGap apps. Certainly, a native application developer can jump through hoops to use a web view and provide JavaScript access to (address book data and other) content which would otherwise be both privileged and only available through the native API... but I don't think it's a stretch to say that a problem which exists out-of-the-box is a larger issue than one that exists only when hoops are explicitly jumped through to make it so.
Android: This is a potential problem with pretty much any Android application, regardless of how it's built.
Not as much as you indicate. Updates distributed through the Android Market still have to be signed by the appropriate developer key. It's easier to hijack a website than it is to hijack a code-signing key. (Also, updates which change permissions are presented to the user, and I've seen more than once that an app's marketplace rating has taken a nosedive when users objected to a new permission being requested).
Redirect users of Internet Explorer on Windows XP to the download pages for Firefox and Chrome.
Good luck selling that to management [and the client-relations team] when web traffic is the direct source of all revenue you split with your clients. (Also, Android 2.x still retains a very wide installed base).
A simple iRule in an F5 LTM will allow you to manage a metric shitload of unique domains and services, on multiple servers, behind a single IPv4 address and TCP port.
Good luck doing that for SSL when each customer wants a unique certificate and client browsers don't support SNI.
Not fingerprints on the phone, fingerprints recorded in the machine -- it has a scanner and requires a fingerprint from the seller (among other measures, such as scanning an ID card / driver's license). Read their FAQ.
The existing tools barely work in 2008. The company producing the card will most likely do no such thing. And that company is Intel.
Then buy a competitor's hardware.
That said, I find it... improbable... that they would choose to hamstring themselves that way... particularly if Microsoft does the sane thing and decides that Windows Server 8 hardware certification requires GUI-less configuration.
Unless you're trying to use old hardware with a new OS, in which case that's always been a hard row to hoe. (At least in the Windows world; in Linux, hardware has tended to be supported further past its obsolescence date... is Hercules graphics support finally gone from the kernel?)
I'm thinking of things more like hardware. In order to configure a Dialogic card on a server you need to use the GUI. You cannot configure the card, run the testing utilities, etc without the GUI
...then the company producing that card is just going to need to write scriptable tools for Windows Server 8, aren't they?
So in reality, it isn't Windows problem, it's user problem. Unless you run walled garden like iOS on your PC, there will always be malware that will try to trick user, regardless of OS. It works in Windows, it works in OSX and it works in Linux.
Infecting the whole system (not just that one account) with a single click (no UAC, no gksudo/sudo, etc)? Not so much.
Privilege escalation bugs are certainly easier to come by than remote exploits, for any OS, but that's not to say that everyone has known ones running wild at all times by any means.
Include people who have to work on one of the 59 days of the year when buses don't run. I'm fortunate to not be one of them, at least yet.
Oooh. Don't have that problem here (the busses run on reduced schedules on holidays and weekends, but -- unlike the train -- they always run).
Personally, I tend to the multi-modal thing -- transit+bike, which helps a great deal with the last-mile problem
How can this be made bearable in sub-freezing temperatures with snow on the ground?
Heh -- I'm in Austin, TX, so the question I get more often is how I bear it in >100F temperatures in the middle of summer (to which the answer is (1) working up to it, and (2) preferring employers with shower facilities, and having a membership at the nearest gym otherwise).
That said, studded bicycle snow tires are available, as are gloves which are both insulating and reflective -- and some of the manufacturers of higher-end rain jackets and such are in the Pacific Northwest, meaning that their local climates are wet and cold enough to ensure nontrivial testing....and again, if you're just biking the last mile or two from the transit station, it's a lot easier to deal with some weather than if you were biking a full 10-mile commute.
Re: "get taken by an industry set up to rob you blind" -- a line of credit with a credit union is the better / more responsible choice in that case. Granted, it's very few credit unions that have actually put effort into marketing to the same segment that payday lenders target, but it has been done.
Speaking to your specific example -- the city I'm in has crappy mass transit, yet I have a friend who fills shifts for a local chain of stores with no car and she gets around by bus just fine. A car can be awfully convenient, sure, but the number of people who genuinely need one to keep their jobs vs the number of people who think they need one to keep their jobs... well, the former is a smaller set than the latter. (Personally, I tend to the multi-modal thing -- transit+bike, which helps a great deal with the last-mile problem).
The NDAA, remember, was at its core a military spending bill. Vetoing military spending bills tends to be... unpopular. Signing a spending bill with an utterly unconstitutional provision attached, of course, is also unpopular... but generally speaking, ITSATRAP!
By the way, you're wondering who was responsible for adding these provisions to a spending bill in the first place? That would be McKeon and McCain, both with (R)s next to their names. The buck may stop with POTUS, but the other side has dirty, dirty hands on this one too.
Think about the profits possible to the first company that builds an interstellar ship...
I'm having trouble thinking of any such profits. I mean, seriously, what's the business model? Put a few trillion dollars into space and wave goodbye, hoping that it'll by some miracle come back with discoveries that'll make your great-great-great-great grandchildren rich?
There are much safer investments to make if you're only caring about getting a return generations after you're dead. Compound interest, after all, is a beautiful thing.
Even notwithstanding that point, if interstellar travel will ever be possible, it will likely be the culmination of thousands of other advancements along the way, the kind that the private sector is very good at making.
The private sector is very good at incremental enhancements, but not big, high-risk research. Once upon a time corporations were willing to fund long-term research, but over the course of the last several decades American corporations have deprioritized their long-term, blue-sky research spending.
In any case, I'm guessing you didn't get the job, but got called back for a series of follow-up "interviews". Why buy the cow when they can get the milk for free?
"For free"? This was part of an 8-hour interview cycle that had some of their very senior (and thus very expensive, both directly and in terms of opportunity cost) people involved. I may not have gotten any direct compensation out of the interview itself, but it cost them plenty to run.
And in terms of indirect compensation for that interview... well, I'm thinking hard about accepting their offer. Suffice to say it's a healthy one.
I despise companies that want me to solve their problems for them before they hire me.
Clearly wasn't the case here -- the problem happened to map closely to an internal tool which had already been written.
Makes better sense this way, too -- if they didn't have enough domain expertise to write the tool internally themselves (avoiding caveats &c), how would they be able to evaluate the quality of an applicant's solution?
Slashdot Mirror
I recently got back into the dating pool myself (Austin, early 30s), and can't say that my experiences are similar.
The women who initiated contact without solicitation have often done just as you described (and not really been a sort I was very interested in) -- but those who have gone to the effort to respond to my (longer, well-written) messages have universally responded in kind.
Then again, I don't know what target age and audience you're dealing with; if it's the early-20s crowd, I'd be very unsurprised.
And you're right, of course, but that's not an excuse for being sloppy.
I'm talking about end-to-end encryption -- your jump into password policies is just bringing up the Mordok the Preventer strawman.
Using TLS for your internal services doesn't make users' lives worse; for that matter, a number of technologies offering end-to-end encryption and authentication make users' lives better by offering single-sign-on capabilities (see: Kerberos) while doing host- and service-level authentication and encryption in the background. Having your hard core kerberized means no additional hoops to jump through on login, but ensures that your backend services are able to determine that their access is eventually tied back to an active and valid session.
Fighting any and all attempts at defense-in-depth because some people do it horribly wrong is simply misguided.
Au contraire -- if your infrastructure isn't robust against this class of attack (all internal traffic authenticated and encrypted, particularly during password exchange), you're Doing It Wrong.
Moreover, the concept of "defense in depth" applies -- a hard outer shell with a soft inner core means that when the eventual successful attack does happen (and it will!), the damage is that much worse. You can't have decent security if you design all the internal components assuming that the outer layer will protect them.
Not that far from it. I don't have numbers on the Segway, but for the e-bike I used to own (45 mile range on 1.2kWh of electricity including charger and battery losses), that's much, much less than $35/year for a full charge every day at the highest residential rate (middle of the summer, above the first 500 kWH).
This argument assumes that the definition of when a set of cells which may eventually become a child is or isn't human is something which objectively exists regardless of the decision we're seeking to make here.
Simply put, I can't accept that assumption. We're making that decision, ourselves, right now; that's what this debate is about. Deciding what is or isn't morally wrong is what we're trying to decide -- but how can the result of this moral decision be objectively incorrect?
You have that backwards. You do own your copy, even though you don't own the copyright. Not the case for software that's "licensed, not sold" (if your jurisdiction recognizes EULAs), but Free Software licenses don't tend to pull that kind of BS, only regulating actions (such as making copies or preparing derivitive works) that copyright would prevent even if you fully and properly owned your copy, thus avoiding any incentive for the "licensed, not sold" silliness.
Think of it as if you were buying a book. You don't own the copyright just because you own your copy of the book, but you certainly do still own that copy.
Living in a right-to-work state... well, let's say there's a reason those laws are colloquially known as "right to fire".
I'm not saying that the all-employment-is-at-will approach is wrong, necessarily, but it certainly has side effects that your blurb above skips over.
And, speaking of intellectual dishonesty, where did I do that?
I didn't say it wasn't an issue for native apps, I said "not as much as [the parent] indicate[s]", ie. less of an issue for native apps than for PhoneGap apps. Certainly, a native application developer can jump through hoops to use a web view and provide JavaScript access to (address book data and other) content which would otherwise be both privileged and only available through the native API... but I don't think it's a stretch to say that a problem which exists out-of-the-box is a larger issue than one that exists only when hoops are explicitly jumped through to make it so.
Not as much as you indicate. Updates distributed through the Android Market still have to be signed by the appropriate developer key. It's easier to hijack a website than it is to hijack a code-signing key. (Also, updates which change permissions are presented to the user, and I've seen more than once that an app's marketplace rating has taken a nosedive when users objected to a new permission being requested).
Good luck selling that to management [and the client-relations team] when web traffic is the direct source of all revenue you split with your clients. (Also, Android 2.x still retains a very wide installed base).
In a few years, maybe. Right now, no.
Good luck doing that for SSL when each customer wants a unique certificate and client browsers don't support SNI.
Not fingerprints on the phone, fingerprints recorded in the machine -- it has a scanner and requires a fingerprint from the seller (among other measures, such as scanning an ID card / driver's license). Read their FAQ.
*sigh*. Think about it for a moment. For which values of x is it true that 2x == 10x?
Then buy a competitor's hardware.
That said, I find it... improbable... that they would choose to hamstring themselves that way... particularly if Microsoft does the sane thing and decides that Windows Server 8 hardware certification requires GUI-less configuration.
Unless you're trying to use old hardware with a new OS, in which case that's always been a hard row to hoe. (At least in the Windows world; in Linux, hardware has tended to be supported further past its obsolescence date... is Hercules graphics support finally gone from the kernel?)
Infecting the whole system (not just that one account) with a single click (no UAC, no gksudo/sudo, etc)? Not so much.
Privilege escalation bugs are certainly easier to come by than remote exploits, for any OS, but that's not to say that everyone has known ones running wild at all times by any means.
Oooh. Don't have that problem here (the busses run on reduced schedules on holidays and weekends, but -- unlike the train -- they always run).
Heh -- I'm in Austin, TX, so the question I get more often is how I bear it in >100F temperatures in the middle of summer (to which the answer is (1) working up to it, and (2) preferring employers with shower facilities, and having a membership at the nearest gym otherwise).
That said, studded bicycle snow tires are available, as are gloves which are both insulating and reflective -- and some of the manufacturers of higher-end rain jackets and such are in the Pacific Northwest, meaning that their local climates are wet and cold enough to ensure nontrivial testing. ...and again, if you're just biking the last mile or two from the transit station, it's a lot easier to deal with some weather than if you were biking a full 10-mile commute.
Re: "get taken by an industry set up to rob you blind" -- a line of credit with a credit union is the better / more responsible choice in that case. Granted, it's very few credit unions that have actually put effort into marketing to the same segment that payday lenders target, but it has been done.
Speaking to your specific example -- the city I'm in has crappy mass transit, yet I have a friend who fills shifts for a local chain of stores with no car and she gets around by bus just fine. A car can be awfully convenient, sure, but the number of people who genuinely need one to keep their jobs vs the number of people who think they need one to keep their jobs... well, the former is a smaller set than the latter. (Personally, I tend to the multi-modal thing -- transit+bike, which helps a great deal with the last-mile problem).
The NDAA, remember, was at its core a military spending bill. Vetoing military spending bills tends to be... unpopular. Signing a spending bill with an utterly unconstitutional provision attached, of course, is also unpopular... but generally speaking, ITSATRAP!
By the way, you're wondering who was responsible for adding these provisions to a spending bill in the first place? That would be McKeon and McCain, both with (R)s next to their names. The buck may stop with POTUS, but the other side has dirty, dirty hands on this one too.
I'm having trouble thinking of any such profits. I mean, seriously, what's the business model? Put a few trillion dollars into space and wave goodbye, hoping that it'll by some miracle come back with discoveries that'll make your great-great-great-great grandchildren rich?
There are much safer investments to make if you're only caring about getting a return generations after you're dead. Compound interest, after all, is a beautiful thing.
The private sector is very good at incremental enhancements, but not big, high-risk research. Once upon a time corporations were willing to fund long-term research, but over the course of the last several decades American corporations have deprioritized their long-term, blue-sky research spending.
"For free"? This was part of an 8-hour interview cycle that had some of their very senior (and thus very expensive, both directly and in terms of opportunity cost) people involved. I may not have gotten any direct compensation out of the interview itself, but it cost them plenty to run.
And in terms of indirect compensation for that interview... well, I'm thinking hard about accepting their offer. Suffice to say it's a healthy one.
Clearly wasn't the case here -- the problem happened to map closely to an internal tool which had already been written.
Makes better sense this way, too -- if they didn't have enough domain expertise to write the tool internally themselves (avoiding caveats &c), how would they be able to evaluate the quality of an applicant's solution?