search

DakotaNelson / sneaky-creeper

Get your APT on using social media as a tool for data exfiltration.
https://strikersecurity.com/projects/sneaky-creeper-covert-data-exfiltration/
MIT License
144 stars 28 forks source link

Delete posted data #62

Open DakotaNelson opened 9 years ago

DakotaNelson commented 9 years ago

Many (but potentially not all?) of the APIs we currently use allow for deletion of {tweets|posts|uploads|etc.}.

It would be interesting to be able to add a TTL value to posts so that they're deleted after a certain amount of time - i.e. if you upload some sensitive data that you want to disappear after a time, flag it to be deleted after it's received, or be deleted after N hours.

My idea for implementation would be that channels can implement an optional "delete" function - if it's present, when the 'receive' function is run, every post's TTL value will be checked and if the post is

then it will be deleted. Modules that do not implement a delete function will simply ignore the "deleted" posts in the receive function, but be unable to actually delete them.

Thoughts?

davinerd commented 9 years ago

I think it would be a good idea to add the "delete" function, but leave the usage to the coder. I mean, it's not a thing the library should decide, but someone who wrote a program that uses the library (in our case, screeper).

DakotaNelson commented 9 years ago

I agree. Expose it as a function call, and let whoever's using it decide how they want it to work.

As nice as a TTL value would be, I think it's too complex and too unreliable (doesn't actually get checked/enforced except when data is sent/received) to be justified in the "core" library.

DakotaNelson commented 9 years ago

It's also worth noting that some modules (Soundcloud, right now - presumably others, eventually) have caps on the amount of uploaded data, and old stuff must be deleted before new transmissions can be made.