The TDS is the T
erver and is a web application that allows for the distribution and management of transforms, seeds and settings. Essentially the TDS means that your transforms are written as a web services (or application/pages), and the TDS will call these scripts.
The easiest way to think of it is as a proxy for transforms. The clients sends a request to the TDS that then calls the script remotely and returns the response, this can be seen in the picture on the left.
- Once setup transforms are easily distributed to multiple Maltego clients.
- No configuration needed client side, scripts all live in one place.
- Updating instantly impacts all clients.
- Deeper into the protocol (Slider value + Transform settings/Popups).
Building your own TDS Transform »
- Cannot integrate with applications local to the Maltego client.
- All requests come from a single point (may impact things like rate limiting APIs etc).
- Server infrastructure setup is reqired.
Local transforms are pieces of code that run on the same machine which the client application is. These are very useful for integrating in machine specific tasks (such as running an application thats locally on the machine- like nmap OR a task that is dependent on a setup on the machine such as accessing data over a VPN). These transforms can be written in any language (yes, *any* language) and merely rely on output to be sent via STDOUT (think a command line application).
- Machine Specific.
- Nothing ever goes 'over the wire' - unless you want it to.
- Simple to write in any language.
Building your own local transforms »
- Requires setup on each machine you wish to install them, eg. Python + Mechanize + BeautifulSoup.
- Does not go as deep into the Transform Specification - no slider or settings.
- Updating a transform means it needs to be updated on every machine.
- Sensitive data such as usernames and passwords could reside on the computer of the analysts.