Amazing "hack" about Yahoo Pipes... they block usage based on an IP accessing a pipe. Yet, you can make that pipe access the "singleton" version of itself many times. So let's say you want to pull up Delicious tags of 10,000 URLs (something I did to generate very nice marketing data), you could access Delicious yourself 10,000 times (and get blocked very soon) or you can access a pipe (which accesses Delicious) 10,000 times... or you can access a pipe 100 times, each time sending it 100 URLs, and that pipe will just loop through and do it (Yahoo will count 1 access against you rather than 100). Since there are loads of pipes servers, and it's a semi-trusted source (in this case very trusted, since Yahoo owns Delicious), not all the Yahoo pipes servers will get blocked by Delicious. Actually, at the rate I was pinging them, some of them did actually get blocked :)
Another interesting experiment: Make a Dapper App which contacts Yahoo Pipes for an RSS. Make that Yahoo Pipe access the same Dapper App. Fun!
While it's actually my job to promote stuff for Y! YQL is one of my all time favourite things we have done and it really very much worth taking a look at. Especially given we just released "open tables" so now you can map any service to it, not just RSS, XML, CSV, etc feeds
Disclaimer: I work for the Yahoo! Developer Network
And now, I test querying the page for itself. If your servers crash, it was all me.
(That said, when it comes to gyms it's pretty easy to figure out anyway. People don't tend to generally go during or immediately after mealtimes, there are fewer women during school-run times, etc.)
Great question, by the way :)
I work in a facility that provides mental health care to clients. I am in charge of the computers and all the technology. Unfortunately, our primary customer is the county government and they simply will not budge on anything.
I’ll give you an example of what I mean. I recently made a very simple proposal which was that we assign clients a confidential number (given to them in person) and have them generate their own password. They could then view their records online using that number and password. But...and this was the important part... no identifying information (such as name, SSN, etc...) would ever be transmitted over the web. None.
The number would be transmitted to us, matched up internally, and then treatment data would be sent back without any identifying pieces of info. No name, SSN, etc... would ever leave our firewall. In addition we’d still use secure connections through SSL, valid certificates, etc...
As you can probably guess I was shot down cold by the county. Transmitting data over the internet to private clients is not secure under any circumstances according to HIPAA (so they said, I don’t agree).
These kinds of policies are why every medical professional fears transmitting data in any way. I mean, if the government says it’s insecure than you’re just opening yourself up for a lawsuit if you ever try to give access.
Privacy is important and I’m not against err-ing on the side of caution to a certain extent. But when fear of lawyers and fear of the Government over power common sense it’s a tragedy and that is exactly where we are now.
I can't imagine a patient would benefit from the world finding out they had syphilis.
Millions of newbie programmers have this exact thought. This is why you see countless forum posts with chunks of code and a note like "Something's wrong, can you guys fix it?"
No programmer with experience is going to waste their time. Similarly, no doctor is going to waste time doing pro bono work to fix your medical problems.
First, assigning a confidential number is a step in the right direction, but it isn't secure; simple traffic analysis (for instance, via a database flaw) will correlate IDs to recent activity, or to a specific visit (say by a tailed car).
Second, any number of other vulnerabilities anywhere on the Internet could coerce a browser to give up the unique IDs assigned to your site, as would any physical compromise of a user's computer, however brief (like, 5 seconds with a malicious USB stick).
Third, your employer would face almost unlimited liability in the event of a mass compromise; they've probably insured themselves against HIPAA violations, but compromise of stigmatizing mental health information is easy to tie to material harm --- far more so than a credit card number, which can at least be revoked.
Using SSL and firewalls doesn't mitigate the core problem, which is that any false step with the application that serves this information cost cost them tens of millions of dollars.
This is a rare instance where I see a draconian regulation actually working to the benefit of consumers.
So the end result of your concerns is that there’s just no way to share medical information.
First, yes, there's no secure way to share medical information. We should recognize that, and by doing so, I think you'll see my argument about your employer being right is pretty strong.
Second, my argument isn't the slippery slope you're making it out to be. In fact, there are likely scenarios in which an application flaw exposes your database, and likely scenarios in which XSRF/XSS flaws will coerce users into exposing medical information. My argument does not depend on some hypothetical killer zero-day bug.
Finally, I'm not advocating a world in which we don't provide access to medical information. I'm just saying, there's no way to do it casually. Any project that does it is going to need a steering committee, and special insurance.
Or I guess more to the point: what would you do? You’re an intelligent person who knows the issues so give me a solution. Because saying "lets form a committee" isn’t an answer it’s an evasion. It’s what people say when they don’t want to be bothered with coming up with a solution.
You're arguing that it should be possible to make medical information (including mental health information) available to patients over the Internet. I agree.
I'm arguing that, confronted with your specific proposal to put that information onto the Internet, your employer made the right call. The considerations you came up with to defend patient privacy aren't convincing; your suggestion, which I concede is probably abbreviated, is insufficient for an application which handles credit card information, let alone irrevocable patient mental health information.
Kaiser Permanente must not be worried about it, since I can see all my blood test results, appointments, correspondence with my doctor, prescriptions, etc when I log into members.kp.org.
http://analytics.blogspot.com/2008/10/more-enterprise-class-...
My wireless telephone service provider. I would especially like to be able to query and download my voicemails.
Better ODB (On-Board Diagnostics) API. Every new car should include a webserver and either an ethernet or wireless NIC (and an easy way for the owner to explicitly enable/disable it).
Actually, every high end household item should have an API (which I suppose is what Java was initially going to do).
A more general answer is.. ALL e-commerce sites. Preferably with a standardish API so that you can do stuff like put together comparison engines easily without scraping HTML.
BTW, would love to get in touch to ask some hackerish questions about your paper. Do you do technology stuff there? If you don't mind, drop me one line and i'll respond (didn't see your address in your profile). My e-mail is shafqat at newscred dot com.
Can I include all the bodies funded by the government, like the Royal Mail (for their postcode db), Ordnance Survey (for their map data) to name a couple. They're funded by our taxes, so why not allow free access to it?
I wonder if we could create a developer community oriented around defining interface standards we'd like to consume.