so you're skeptic of the skeptics? skeptics of what?

or what the fuck? maybe light too travelled distance per year in Noahs time? that kind of thing?

the problem with saying that people who go against common logic and science are creative geniuses is that.. the more time goes on and the better the established science goes, the more of the people who are skeptical of science are just morons - not creative geniuses. and there's a lot of morons with too high self confidence and self esteem filling up the youtubes already with all kinds of crap theories - that is to say that a moron with high self confidence is a pretty common sight.

but it has more accountability than a simple stamping of a date? and what good does that date stamp do while it is in transit for years?

like, how do you know it is even stamped? if there's an unique code in your stamp and that qrcode gets scanned in, then at least it is scanned in and potentially could have information available to you about it's state. something simple stamping would not give. ...but... about this device... why the need for a laser burner when a simple printer does the job? or why no just do stamps like us ps machines have been giving away for years, with qrcodes. just scan the code in your stamp, put the letter in the mail and use the app to see the state of your delivery..

it's really simple why this wouldn't have been published.

the author thought for a moment more, deduced that in the future there would be a streaming video service full of geniuses willing to fly against reason, common sense and logic to present all kinds of sca... "inventions".

I guess he then understood that all the good inventions needed common sense and buried the paper. now more than ever because we know so much already that you can just call people trying to build another "magnetic generator" bullshit artists who they are and call homeopathy a fraud it is due to common sense, since common sense includes so much more(including nuclear physics).

if you glance the paper, it might seem that they include a root exploit that gets run with the application. however, deeper reading is that the root exploit is only mentioned on an exampe of an android malware file..

in the example of their application, they conviently skip even saying if the apk install screen is shown! however I still think it is shown because they include this disclaimer right after there..
"Note trickier implementations can conceal the installation of the payload APK", sneaky bastards, they apparently use that line in the paper to justify skipping of showing the installation screens for the second apk- the paper makes it look like it just skips from one application straight to the next but that note line there tells the truth, so technically they're not lying. and a trickier implementation wouldn't even require an apk, devoting half the paper to angecrypt commandline usage and all that shit - making the whole paper irrelevant in the context of a 'trickier implementation'. now tell the trickier implementation as that would be news, if you have it!

does a troll mod give a temporary few minute ban to slashdot? that's real classy. couldn't post clarification for hours.

The current firmware update ships as a bootable ISO. Burn it to a CD/DVD (or a flash drive if you can work it out), hold down "option" at boot, and you'll be looking at a DOS prompt in no time. I verified this two days ago when I misread the firmware version on the website and downloaded an updater for the version I already had.

Yes, it's the fear of Ebola that's the bigger practical problem. However, the remedy for that fear is precisely doing things like declaring an Ebola 'Czar' and promising to deploy the National guard 'if necessary'. Note they didn't actually call up the national guard, just promised the obvious, if the national guard is warranted (it won't be) it will be called up. The nomination of a 'Czar' is pretty much free and convening ' a two-hour emergency meeting with every top federal official involved in public health and safety.' is actually not that terrible either. These measures are not a big deal in cost, but are important in their significance to the general populace.

So someone who is well informed may rightfully see all this as silly from a practical perspective, but I don't think they would perceive a significant investment of real resources in any of it.

Meanwhile those inclined to not be so well informed are assured by some response that really doesn't cost much.

Though that pales in comparison to having the secret number to take as much of your money as someone wants printed in plain on paper checks or stamped into a little piece of plastic that you share with anyone that you give money. If a mobile banking app would help me spend money in a more secure fashion at vendors, I'd gladly take it over a credit card to swipe. It could actually be substantially be incredibly more secure than chip and pin in some ways (e.g. the account holder fully controls the input and display device and can communicate with financial institution without going through vendor provided equipment.

Admittedly, before making a formal business commitment, we wouldn't play 'guess the actual requirements from vague problem descriptions, but:
"his organization has a one large event per year with roughly 1400 volunteers total." suggests the need is highly seasonal and admittedly one month is a bit specific, but you get the idea.

Actually, that case was not site development, but I'm well versed with precisely how much work it involved and even given the benefit of their familiarity with the codebase being modified, I'd wager easily it's more work than this question is detailing. It's also work my team could have done, but we were short on time. My team reviewed the code and only accepted it after we were comfortable that we knew the code provided as well as if we had written it ourselves. This is commercial for profit, but also not in the critical path for potential fiscal catastrophy (and I work those scenarios too, and those are a nightmare and warrant high cost, but you can't be so jaded as to assume *every* trivial piece of work should be treated as such).

I get a different read: " In the past two years, they have used a site written by a volunteer that has worked fine for them, but that volunteer is unavailable to maintain or enhance his site this year. " Note that the client seems *relatively* content with what one guy bothered to do in his spare time that was almost certainly done on very short notice, just probably looking for someone to go in and add a field here, or combine two forms there, or something relatively simple like that.

Even with the obvious editorial bias trying to spin it to state that is the case, I just don't get that feeling from the description and my work with non-profits. They probably have a simplistic site that they want to evolve a little, not raze everything to the ground and start over.

I am very familiar with how enterprise projects work. However you slice it, this is *not* of that pedigree. Small non-profits generally know they get what they pay for and don't have complex needs or unrelenting demands over even trivial cosmetic stuff like is common in enterprise land. There is just a huge world of difference between a production internet presence of an international Fortune 100 company with a labyrinth of inter-departmental nightmares to navigate with a potentially huge revenue amounts, market perception, or liability on the line at any given time and a volunteer sign up site for a local non-profit that only handles about 1,400 volunteers.

Well, two factor doesn't mandate two channels (for example a door access system that requires both a badge and a keycode is also two factor), but yes, two distinct devices needing to be hijacked is better. However, in your example that's not assured either. If the mobile device is used to access the website then it's still one device. There's no guarantee that the user used a different device to access the web and process the text message. It's at the discretion of the user to take care of their circumstances appropriately.

Ultimately, the point I was trying to make is that this is an improvement over the usual state of things and should not be discouraged just because it isn't perfect. This aspect of security is trying to find the right balance between 'secure' and 'friendly'. It's easy to be secure if you don't care how hard it is to use, but making two-factor authentication as the norm for authentication has thus far eluded us due to acceptance issues, rather than technical failings. We have dozens of viable two-factor authentication approaches, just none that most people would tolerate.

The dominance of computer's as something for men in 80s pop culture was probably reflecting the trend rather than causing it. The timeline seems too short for so few pop culture things to influence.

The market for coding evolved at first primarily from 'data entry', which required nearly no training. Women of the time (disadvantaged or disinclined from training depending on your opinion) could take those jobs and men who needed to 'provide' sought higher trained jobs with higher pay. Basically straightforward data entry started to become 'advanced data entry' that started incorporating things like formulas and continued on from there. Perhaps because it started to demand more and more skills, narrowing the labor pool and driving up compensation, enticing men to start participating more heavily and an overall male-favorable social bias started to take effect. Or perhaps the nature of the work fundamentally changed enough in a way that drive a different male/female interest. Or some other factor, these are all guesses.

I just doubt that a handful of 80s movies changed the entire landscape of female participation in the market basically within a couple of years of the first movie's release, and there's a lot of alternative explanations that are quite viable.

Use FreeOTP or Google Authenticator? It's simple yet pretty well secure and allows an arbitrary mobile device to provide keycodes? Sure, you have to actually type a few numbers (the horror), but at least you don't need yet another security dongle that, despite the current hype, will probably be obsolete in a couple of years.

For what is almost certainly a few cosmetic touches to an existing app (that is likely only a couple hundred lines of code to start with) that would take probably 15 minutes to do, you'd charge $150k without any warranty of working, and then basically charge enough to nearly dedicate one reasonable (entry level) full time employee to an app that probably isn't used at all about 11 months out of the year? Well I know who is likely to lose any bids I put out for development work if that is indicative of your overreaction across the scale of things. Admittedly, I wouldn't raise this much fuss over this trivial case to even solicit bids (if it is really simple as I suspect it is, do it in the time it would take to go through the procurement dance).

I've seen quotes from a very good development company that has always delivered come in at about $10k for work significantly harder than this subject. Admittedly I think the owner undercharges for the skill of his team, but they seem happy because they knock it out in a week, deliver solid results, and move on to the next customer. So far my code review of their work has never seen a structural problem (some subjective preferences about some word choice was all) and the work hasn't actually produced defects for my test team or my clients. This is an example of *way* cheaper than it should be, but it helps provide some perspective on how unreasonable the numbers you throw out are. Of course, even with that they still get underbid, but we know better than to go to lowest bidder almost any time.

Yes, this is what I struggle with as well. It sounds like a trivial sort of application and the submitter characterizes it as needing a pool of developers and project management investment. That is a silly assumption, some things are truly trivial things. I had a very simplistic script on a backed up, shared filesystem and did 'git init' because it was essentially a free thing. Upon noticing that I bothered to git init, suddenly people were pushing 'you can't do git without something like github or gitlab, and an issue tracker, but not gitlab or github, but it needs to have integration with those'. Of course I know full well that it's a 20 line script for internal use by a team of about 5-6 people for a very trivial thing, and that those people aren't going to bother with a ticket even if a system was made available and instead just turn around in their cube and ask the entire user community about it.

As you say, this can go both ways, people stubbornly insisting on do-it-yourself and people pushing for 'someone else do it' against all reason. I have seen projects that really could use those facilities above and try to whip up their own gitlab type facility rather than just installing gitlab.

Not knowing all the details, I'm thinking I might concur here.

For one, you can either coast by on the current solution so long as it continues to accommodate the needs or completely change over now 'just in case' needs evolve in the future. The latter frequently is a bad move since you are taking a hit now either way for the sake of a nebulous future requirement that you can't even be certain will be met by your selected solution. This means that if that nebulous future comes to pass, you might have to migrate again and have saved nothing. If the current system works and the events are basically run the same year to year with only cosmetic tweaking, then it would be a waste to change.

For another, it seems like some people are afraid of having the littlest piece of software written in-house. Sometimes a solution really is simple enough that it's overkill to fret overmuch about maintenance and adaptability. Of course a key line to recognize is when you have evolved unexpectedly into the domain where worry is warranted, but a fairly simple facility to manage 1,400 records seems like it could reasonably fit into the realm of simple code that shouldn't be scary. I admittedly have more experience in corporate, but I imagine this holds true in a general sense. I've seen some companies outsource every little need to an unmanageable sea of vendors and get stuck with an overall atrocious experience and I've seen others stubbornly write everything in-house against all reason, so a balance must be struck.

Sure, that will get malware authenticated for that session. Realistically speaking, if the end device is compromised to the degree of having malicious intervening software, there's little that may practically be done. However, 'keylogging' does much less in this case. It can intercept the one time credential that was sent, but that credential is useless beyond that session.

Compare that to the common state of the art where not only can malware run amok with the authenticated session, it can also report up the login credentials for the adversary to use at will.

Now I will say I'd just as soon use TOTP with a pin appearing on my cell phone than a dongle. I suppose some people can't be bothered to type a 6 digit number in 60 seconds.