Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Feds (Score 1) 184

Not exactly what I meant. Yes, records need to have an secure audit trail as part of HIPAA. I am talking about watching transactions being made against someone's health/medical record and determining if it is likely fraud. Right now, that doesn't happen due to each institution having their own copy.

For example, if someone enters a hospital claiming to be me (but, in a different state), why can't they request verification (maybe, through a mobile app) that it is me?

If they can't obtain verification from me (such as it is me but I am unable to respond) in a reasonable time period, then there needs to be a fallback procedure such as verifying with a relative that I might be in that particular hospital. And, any transactions against MY health record need to be kept separate until verified. That would keep someone from having surgery, billing it to MY insurance, and having it recorded that I had a kidney removed or hysterectomy (I am a male).

These sort of protections and verifications ARE NOT rocket science.
 

Comment: Re:Feds (Score 2) 184

We saw a standardization of data formats in the public safety industry through NIEM. This facilitated interoperability between public safety systems. There is no excuse NOT to have something similar for EHR.

Now, I have worked in the industry for just about two years. Pharmaceutical companies are willing to accept digital signatures on internal documents. Most, however, are less willing to accept a digital signature on a document submitted by a patient. They still require ink signatures on consent forms in most cases. It's human nature to try to deny responsibility and to place the blame on a technical solution such as digital signatures. Healthcare professionals and organizations can fix a lot of the problems by demanding that the legal gray area surrounding digital signatures be resolved and mandatory interoperability between EHR/EMR systems be established.

Healthcare professionals or their employees entering information an EMR or EHR system should be required to digital sign every patient note or access to a patient record as being correct as, at a minimum, on a corporate policy level. Legislation must be enacted to make the penalty for false entry include serious legal and financial repercussions for the individual(s) responsible. Punitive damages should be automatic for anyone harmed because of the falsified records.

EHR and EMR records should be monitored for illegal or unauthorized activity just as your credit card company can monitor your in-store and online purchases. It makes no sense why multiple versions of your records exist in different platforms. Why aren't people informed, via their smart phone, whenever their records are accessed by an organization or individual and those changes kept separate and not merged into your record until verified?

Comment: Re:Saudi Arabia, etc. (Score 0) 653

Let me ask you this...If you are actively employed and enjoy the job, pay and other benefits, are YOU willing to up and quit because you don't like their choice in bottle water. Are you a hypocrite if you say 'no'?

This is a very lose analogy to what foreign corporations face when dealing with other governments as they are there at the whims of that government. You don't muck with internal politics of another country directly unless you are willing to lose it all.

Comment: Re:Saudi Arabia, etc. (Score 2) 653

Spot on. And, taking actions which negatively affect the holdings of a stock owner in a publicly traded company will not go over well. Since foreign corporations operate at the discretion of the local government, attempting to meddle in their internal affairs will likely result in loss of that market. That is certainly not popular with investors.

Comment: Re:Clueless Article (Score 1) 54

by Ronin Developer (#49399579) Attached to: 5 Alternatives For Developing Native iOS Apps

Glad to help. I would suggest you visit fmxexpress.com as well. Lots of articles and links to code for developing FMX apps for iOS and Android.

Developing components for FMX is a different process than for VCL components. Personally, I haven't had the time to delve into this area and, right now, more inclined to buy COTS until I have more time to really delve into styles.

Good luck.

Comment: Clueless Article (Score 2) 54

by Ronin Developer (#49395879) Attached to: 5 Alternatives For Developing Native iOS Apps

I read the this article with distain. It is clear that the author hasn't tried any of these tools. Yes, Embarcadero's RADStudio and Delphi products are expensive. Yes, I have shelled out the yearly maintenance fee when my current employer wasn't a Delphi shop. Other than being a relic from the 90's, why?

The answer is simple - it works. Originally developed as a Windows development tool, it can now target iOS, Android and even OSX. Author doesn't address the latter. It has excellent database connectivity for both desktop and mobile. On the mobile platform, you can use SQLite or Interbase to Go.

Apps can be written which can incorporate wifi and/or Bluetooth to create tethered apps allowing seemless integration between desktop and mobile. It is easy to write apps that can use Parse or Kinvey to leverage cloud computing. And, if you know what you ate doing, you can leverage frameworks not already supported.

FireUI is not a framework, it's a tool built into the IDE so that you can design views and see how they adapt and look on other platforms. This is done using a crossplatform framework, under the hood called FireMonkey. I won't lie, it does add to the size of the app. You use styles (canned and custom) to change the appearance of the components. They have native looking control styles as well.

There are also 3rd party vendors, such as TMS Software or the open source D.P.F. components which ARE native code controls. They provide Delphi wrappers around the the frameworks. This eliminates the speed barrier imposed by the FM3 layer if it bothers you.

The beauty of this tool is the ease in which apps and full applications can be written. But, yeah, it's pricey.

AppMethod is a monthly plan for their tools.

Delphi used to have an amazing 3rd party ecosystem. Stupidity by management at Borland/inPrize clusterfuck killed Delphi in favor of their Java products. What java products? Exactly. Thankfully, there are still 3rd party vendors who provide amazing addons - just many have left and may never return in favor of C#.

REMObjects used to be a component vendor for Borland and provided a product called Prism which implemented their own dialect for .Net until they felt they got stiffed by Borland. They released Oxygene to replace Prism. They make great stuff.

No, I don't work for Embarcadero. I am a fan. And, if you want to develop vertical apps for, say, the enterprise, it's worth looking in to, But, the adoption rate is low in the US. Wish that wasn't the case.

Comment: Re:It depends (Score 1) 486

by Ronin Developer (#49337293) Attached to: No, It's Not Always Quicker To Do Things In Memory

All else being equal, I am betting that they coded in a language that:

1) Uses the heap to allocate/reallocate memory (ie. 1 million times).
2) Uses non-mutable strings.

This will be significantly less efficient (i.e painfully slow) than writing each byte to a buffer in the HD and then committing the buffer to disk.

Snap...just read the article. They used Java and Python...need I say more.

Comment: Re:The App Store stuff is more interesting (Score 1) 269

by Ronin Developer (#49335457) Attached to: Developers and the Fear of Apple

The "race to the bottom" is a reality when developers flood the market with cheap knock-off versions of other apps and there is no enforcement to check that behavior (i.e copyright law). This results in a large number of non-original, low quality apps. being created by a developer sitting in a hovel and with no original ideas of their own prospering from a lack of integrity. There are ways large corporations, such as Google or Apple, could address this problem just as they go after clones of their products.

Unless you create the next "Angry Birds" or equivalent, the age of $0.99 apps making a developer rich (or even possessing a living wage) are long over without enforcement against clones.

As for a company strong-arming journalists with negative reviews - while we appreciate their candice as consumers, they are not in the best interest of the corporation. While a single bad review might be frowned upon, I would suspect multiple product or company bashing articles would result in a ban. They are corporations, not gov't. and transparency is not required.

Lastly, when you agree to be a developer for a platform, you do agree to their terms. If you don't like the term, develop for another platform. Apple, if memory serves me correctly, has over 47% of the market (vs 46% for Android). Apparently, people still prefer Apple's products (despite it being a single vendor vs the many of Android). You can say it's not as good. Millions will say otherwise. And, that is where they are willing to spend their money 47% of the time. The demographic of those willing to spend money on apps and having larger affluence still leans in Apples favor. As a result, this is where larger corporations will spend their money and Apple knows they can call the shots for now. So, they do. If and when Android devices become the products of choice by not only consumers but large enterprises, (things big pharma, EHR, eDetailing, etc) the tables will turn and there will be changes in how the new underdog approaches the world.

Comment: Re:Can't have it both ways (Score 2) 337

by Ronin Developer (#49301557) Attached to: German Vice Chancellor: the US Threatened Us Over Snowden

No, they would just go into a prestigious hotel room, get caught, and resign.

What planet are you on? Espionage and counter-espionage have been going on since the dawn of time. It knows no party limits. Without it, we'd be a pile of nuclear rubble by now or launching attacks into countries on a belief. Oh...wait.

Comment: Re:Know what's worse? Cleartext. (Score 1) 132

by Ronin Developer (#49282533) Attached to: Researchers Find Same RSA Encryption Key Used 28,000 Times

Of course systems continued to support the older mode at first.

That being said, the regulations regarding key length were relaxed starting in 1998. By 1999, all restrictions on key length were removed for import and export to all countries not on the terrorist state list. Risk analyses had already been done by any company that had requested a license to export cryptographic products. So, when the restrictions were lifted, the dangers of the export key length restrictions were well known.

In particular, use of longer key lengths were approved for use in key industries such as banking and medical and online commerce. That was 15 years ago.

Interoperability isn't the issue here - it's all about cost and profit. Privacy and protection of data (especially, personally) were not a priority provided the costs of compromise didn't break the bank (pun intended).

Found an interesting link that explains the timeline and legislation regarding crypto laws for many different countries. The listing is alphabetical.

http://www.cryptolaw.org/cls2....

Comment: Re:Know what's worse? Cleartext. (Score 1) 132

by Ronin Developer (#49277117) Attached to: Researchers Find Same RSA Encryption Key Used 28,000 Times

Weak encryption is infinitely WORSE than none.

The illusion of security is more likely to cause people to divulge information that they wouldn't do in plain text.

I remember when the export key laws were in place. Once the regulations were changed doing away with them, software and equipment should have been required to remove the obsolete code or be taken off the market.

My question is how could OpenSSL still have had this potential backdoor? Why was this not removed at first opportunity?

Comment: Re:Aren't these already compromised cards? (Score 1) 269

by Ronin Developer (#49276535) Attached to: Fraud Rampant In Apple Pay

I disagree. The banks and card issuers should have performed a risk analysis and identified the yellow path authorization as a problem. It has become Apple's problem because of bad press caused by the institutions not doing their job adequately. Thankfully, in most cases, the card holder is not responsible for unauthorized CC use without a valid signature or PIN involved with the purchase.

What I am unclear is what happens to the original card after it is imported into Apple Pay. Perhaps, when a card is imported into Apple Pay, use of that card outside Apple Pay should not be possible until unlinked by an action taken by the Apple Pay user (or, issuer if phone was lost). This could be a temporary measure for one-off uses with automatic or manual Apple Pay reactivation if a separate card (and number) is not issued by the institution.

Something a simple as having an SMS sent to the card-holder's phone alerting them to use of their card outside of Apple Pay could be the solution.

While some of these issues could be resolved by Apple, it is the banking and card issuing institutions that need to step up and improve their process. What happened here is their desire to get in on the deal and not be left behind as an excuse for inadequate processes.

Comment: Re:Aren't these already compromised cards? (Score 5, Informative) 269

by Ronin Developer (#49274911) Attached to: Fraud Rampant In Apple Pay

I read another article on this. As the article tries to expose, the fault lies not in Apple Pay, but rather in (as the article suggests), the process by which cards are authorized for use with Apple Pay during the onboarding process. There are two paths, the Green Path and the Yellow Path when authorizing a card. The difference is the types of information collected and passed. Most cards go down the Green path. But, when a card has incomplete information, it goes down the Yellow path and is subject to less stringent and, sometimes, manual intervention. It is down this pathway where the fraud occurs.

While a card is being approved during the Yellow pathway, the card can be used using the card number, expiration date and, not always, the security check value.

It is up to the banks and card issuers to secure their onboarding process. Apple (via Apple Pay) is not responsible for ensuring this takes place. Thankfully, the fraud is easy to detect and remedy. Next year, when our cards all have chips in them, the exposure via the Yellow Path will all be eliminated.

Apple supporters were right to call out Mr. Abraham - he is biased and attempting to create FUD against Apple and Apple Pay. The real fault and finger pointing needs to be directed to the banks and they need to get their houses in order.

Comment: Going to be a noob (Score 1) 213

Please...serious answers only...I don't care if you hate/love Apple or Android.

But, what is the likelyhood of the following:

1) Malware running on your non-jailbroken iPhone?
2) Malicious scripts running in the browser talking to other apps on the device?
3) Potential for your SMS traffic to be intercepted on a non-jailbroken iPhone?
4) Ability of an app to access SMS traffic on an iPhone?

Now, apply the same questions as they apply to latest incarnation Android?

My understanding is that sandboxed nature of iOS would/should prevent malicious apps from being run (assuming, you don't download one from the store or have allowed someone to physically compromise your device). iOS does not allow one access to received SMS traffic (unlike, Android). This means a user would have to manually enter the received token. To gain access to pushed traffic, something like APNS (on iOS) or GNS (Android) might be a better solution. Dumb phones can use SMS.

I would not suggest accessing your email from the same device as your token receiver, but can iOS' sandbox architecture provide enough of a firewall?

Are there exploits in the wild for iOS and/or Android making this a serious threat?

If it's not in the computer, it doesn't exist.

Working...