Yeah, since it's sending the URLs, Microsoft couldn't get to the actual images in question because they'd in a private network, behind a login, etc. If the images are hosting on a public domain or IP, that is not on Microsoft.

Under HIPAA, any scrap of "individually identifiable health information" that can be used to connect online data with a patient cannot be sent to a third party without consent.

Just curious, how are images protected by login:password? The only way I know is htacess, which isn't really an easily scalable/usable feature... Many years ago, maybe 10 when I used Facebook I recall you could share a picture location with anybody regardless of login (i.e. Right click, copy image location, send over whatever), so the URL wouldn't be guessable or possible to predict, and the protection would be that you would get access to such url only when logged. I think in this context, the private network idea would only work if you are on vpn and you share urls that are only accesible vía vpn, is this a common setup for medical images? Is this expected? I wouldn't mind having a key or an image descrambler/decrypting/token but can't say the same about my grandma, my mother, my brother, my nephews...

Images are like any other web asset and can be protected either by the web server (htpasswd) or the application's logic.

I think you've been brainwashed by modern storage services (S3) where the URL is essentially always public and out of your control. It's trivial to password protect an image when it's on your server. I would assume any medical provider would protect their images by checking the session and not serve them via AWS.

You're right, although I would not assume anything when it comes to privacy, there are so many examples where companies did not follow best practice.

We need to move away from this model where others are in control of our private data to one where it's owned and controlled by us, giving access to service providers as needed.

Generally, no-one hosts public content on the S3. It is simply really expensive when it comes to outbound traffic. The content is usually cached and served by CDN, where you have full control over authentication and cross-origin rules.

I don't know HIPAA specifics off-hand, but I would not be the least bit surprised if ephemeral pre-signed urls get generated for sharing HIPAA protected assets based on cookies/auth. If the URL is live for a time window and doesn't insta-expire on refresh, then it's conceivable that data gets leaked here.

HIPAA requires "reasonable" measures. Hilariously, you can't chuck a drive full of plain text PII into a dumpster in the back of your building...

...unless there's a fence around it.

A lot of the nonsense around shredding hard drives is just the drive industry convincing people that they need to destroy perfectly good devices.

Unless you're facing state-level actors a simple zero-out or pipe from /dev/random will suffice. Or with a lot of modern drives where the data on the platter is encrypted by default, just send the "secure erase" command, causing the drive to roll over the controller's private key.

>A lot of the nonsense around shredding hard drives is just the drive industry convincing people that they need to destroy perfectly good devices.

Unless you're willing to prove beyond a shadow of a doubt that each and every such hard drive does not in any shape or form contain sensitive information and pay hefty fines and jail time when you inevitably fail, the only nonsense here is you. It has been proven time and time again that data once written can be and will be recovered.

Any storage media that contains or contained sensitive information must be physically destroyed. That is the only surefire, foolproof way that we currently know of to securely and permanently delete sensitive information.

> Unless you're willing to prove beyond a shadow of a doubt that each and every such hard drive does not in any shape or form contain sensitive information

I'm not sure which part of "HIPAA says you can take an UNENCRYPTED hard drive and toss it in a dumpster provided it has a fence around it" you didn't understand.

> Any storage media that contains or contained sensitive information must be physically destroyed.

Not for federal data:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.s...

Not for classified defense department data:

https://www.dami.army.pentagon.mil/site/IndustSec/docs/DoD%2...

...and as previously mentioned: not for PII healthcare data.

The bit about "you can only be SURE if you destroy it" is pure hard drive manufacturer nonsense.

Find me a single case where someone has recovered data from a non-solid state (hybrid or otherwise) drive or tape that has undergone a SMART secure erase or NIST / DoD compliant wipe.

In decades, I have never heard of such an incident.

Simple, I read a paper that vaccines cause autism... Now prove to me that you are not an elephant.

Now lets get purely logical. There is a non-zero chance of risk, and the best risk avoidance strategy is to not take the risk in the first place, so shred the drive.

So lets make a software, that would secure erase the drive and try to recover the data, and prove that you are not actually an elephant. But why?

Make a lot of money instead? Make a hard drive with a secure erase feature, and yes I know, but like put a spin on it, maybe a button, or better yet, you secure erase the drive backed by an industry grade non-recoverability warranty for a cheap $10/yr./drive subscription access to our secure erase service. We come to you next day, give a certificate and everything, you can put it in your HIPAA folder and show it to your risk committee.

Your market? Health care, gov, and problems that solely exist in between the keyboard and the screen.

Trivia: At the old AT&T (not at&t, the (mostly) mobile/cell company), it was standard to degausse the drive then drill through the middle of the radius and park a bolt there.

Bonus points if You had a spot welder to secure a nut to the bolt.

Fun times.

But given that our hardware is largely cheap and disposable, it's almost always cheaper to throw another device or 1000 on top of the shredder pile than it is to pay a tech to make sure every one of them has been zeroed.

Hopefully no identifying info in the URL!

If you put an image in a Google doc it will be accessible by the URL regardless of if you are logged in or not. Perhaps not in every case, but in the basic case I have tested this has been true.

Sharing the URL is equivalent to sharing the image in these cases.

Discord is the same

Even if the payload is inaccessible, consider the implications of leaking an URL like:

medical-intranet.example.com/uploads/secure_link/adc83b19e793491b1c6ea0fd8b46cd9f32e592fc/john_doe_1987-04-23_chlamydia_1.jpg

And what prevents a distributed denial of service attack or fuzzing using Microsoft's infrastructure? If you were to trick many users into visiting a site with 1000 variants of:

  <img src="https://siteunderattack.com/api/computationally-expensive-function/?image=cute_bunnies_####.jpg"/>

or

  <img src="https://siteunderattack.com/api/function123/?name=Robert'); DROP TABLE students;--&image=cute_bunnies_####.jpg"/>

This is really no different than having the client do the request without the Microsoft proxy.