Disagree. As a user, I want file-level or directory-level analytics. I want to know how much time I'm coding in the backend services vs the front-end react client.

If you have concerns about this, do you also have problems with Github literally having access to all of your code? Or Google having access to your search history?

I'd be more concerned if it wasn't using SSL. That would make sense, but it seems secure on that front.

> I'd be more concerned if it wasn't using SSL. That would make sense, but it seems secure on that front.

Yes, I agree with you, using SSL is definitely better than without.

Github and Google have security teams and aren't side projects.

So did Equifax. All this outrage is completely unfounded.

> outrage

Someone kindly shared an opinion and gave their reason for having that opinion. Outrage is a different thing.

This was requested a lot before, so you can now hide file names. This means only project names and timestamps are sent to our servers:

https://wakatime.com/faq#exclude-paths

Perhaps you could encrypt the filenames with a user-supplied password hash. Upload and store just the encrypted filenames, and when the user is viewing the data on the web can decrypt the filenames by asking them for the filename password. You could run analytics on the encrypted data still, and not expose filenames to even wakatime.

Or you could divide the files in classes like that

<pattern> -> "backend code"

<pattern> -> "frontend code"

and upload only the class a file belongs to.

What if you opened John_Doe_health_information.txt - would something like this be a HIPPA violation?

Healthcare startup here: Yes, because first/last name are PHI identifiers, and it's possible that even using the product itself could be considered a breach because you don't have control over the data. If the filenames some non-phi unique identifier, you're fine.

What's the difference between sending data within in a file, and having the file named something that is an important data point? None. So naming the file with a PHI field (even MRN!) is a bad idea to begin with.

A good answer would be to not let true patient data leave the hardened production server and be opened in any kind of development environment, ever.

Having somewhat recently started a job developing frontends in health informatics, I'm noticing that programmers need to consider HIPAA far more than I think many realize. Even when working outside the healthcare industry, as may be the case here.

With that filename in majority of cases you're violating HIPAA even within your internal network. The thought processes usually goes, does every person that potentially sees that file name require to know the patients first and last name? Also, even those that do require it should only be accessing it on an as-needed basis (eg. at the time of claim submission, etc) which means it shouldn't be floating around on your filesystem.

Why do you think the second part specifically is "a recipe for a disaster waiting to happen"?

Well, because it's a mechanism the user is not controlling and is potentially problematic if someone makes the plugin download an update package from another source. I'm a bit paranoid, but I would prefer all functionality to be within the plugin itself. There's a plugin manager for Notepad++ which notifies the user of plugin updates.

I suggest you suggest this to the author.