Privacy implications - more configuration options needed

[shapeshifter910]

Options for saving the torrents from magnet links is needed.
The default folder on Linux .config/transmission/torrents is a hidden folder and not obvious.
This creates a privacy nightmare as a trail of torrent files is left behind.

[blacke4dawn]

Save how since magnet links are saved as .torrent-files in the torrents folder?

It follows the XDG standard and it only contains files for the torrents that are loaded into Transmission, so no different from just opening the client. If anything then the resume folder is slightly worse since it seems that it's not as thoroughly cleaned, but I can't see how this is a privacy nightmare since they need the proper permissions to access it in the first place.


However, just out of curiosity I want to know what options you see being needed to fix this perceived "privacy nightmare"?

[shapeshifter910]

Save how since magnet links are saved as .torrent-files in the torrents folder?

It follows the XDG standard and it only contains files for the torrents that are loaded into Transmission, so no different from just opening the client. If anything then the resume folder is slightly worse since it seems that it's not as thoroughly cleaned, but I can't see how this is a privacy nightmare since they need the proper permissions to access it in the first place.


However, just out of curiosity I want to know what options you see being needed to fix this perceived "privacy nightmare"?

I don't know whether XDG standard applies to data.
Torrent files are data files, not configuration files. So they don't belong to hidden directories that are meant for configuration files.

And my understanding is that resume files get deleted automatically after torrent is done downloading whereas torrent files generated from magnet links stay forever? Correct me someone if I'm wrong in this assumption.

So torrent files should go somewhere other than hidden directories, something like downloads\torrents or documents\torrents etc.

More importantly the user should be given the opportunity to chose where to save these torrent files (like Vuze does) or configure a chosen directory through the Options facility.

It's a privacy nightmare because on a multiuser computer these directories stay forever and anybody with root has access to them and can see who was downloading what.

[blacke4dawn]

I don't know whether XDG standard applies to data.

From the XDG standard:
$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Torrent files are data files, not configuration files. So they don't belong to hidden directories that are meant for configuration files.

Not sure what you are on here but in one regard they are configuration files, they configure the torrent client in regards to which torrents to "load".

And my understanding is that resume files get deleted automatically after torrent is done downloading whereas torrent files generated from magnet links stay forever? Correct me someone if I'm wrong in this assumption.

The .torrent-files under the torrents folder are meant to always be removed regardless of if they originally came from another .torrent-file or from a magnet link because that folder lists all the torrents that are loaded into Transmission. I have not had Transmission keep .torrent-files from magnet links, but I have had it "fail" to remove a few resume files.

So torrent files should go somewhere other than hidden directories, something like downloads\torrents or documents\torrents etc.

Not according to the XDG standard, see above. Now if you are talking about the downloaded data then it's another matter, and that goes into Downloads.

More importantly the user should be given the opportunity to chose where to save these torrent files (like Vuze does) or configure a chosen directory through the Options facility.

Personally I don't think so since I don't see what is so important with these files that you need such "ready" access to them, and that you can't do it with the current setup.

It's a privacy nightmare because on a multiuser computer these directories stay forever and anybody with root has access to them and can see who was downloading what.

*sigh* Then effectively every fracking program has a "privacy nightmare problem" because most of what you do in them is not automatically deleted and root has access to it. This is like saying that it's a "privacy nightmare" because other people can go into your room to look around when sharing a house/apartment with others, or even that your landlord has access to your apartment. This "problem" is not specific to Transmission but rather the account system in any OS (not unique to Linux), but it isn't a real problem. If you don't trust those with (full) root access then just don't use that computer.
Though I am very curios to know how you envision this to be solved. How do you design it so that root (or the equivalent on any other OS) can do whatever it wants to while still keeping the privacy "intact" of the other users?

[shapeshifter910]

I don't know whether XDG standard applies to data.

From the XDG standard:
$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Torrent files are data files, not configuration files. So they don't belong to hidden directories that are meant for configuration files.

Not sure what you are on here but in one regard they are configuration files, they configure the torrent client in regards to which torrents to "load".

And my understanding is that resume files get deleted automatically after torrent is done downloading whereas torrent files generated from magnet links stay forever? Correct me someone if I'm wrong in this assumption.

The .torrent-files under the torrents folder are meant to always be removed regardless of if they originally came from another .torrent-file or from a magnet link because that folder lists all the torrents that are loaded into Transmission. I have not had Transmission keep .torrent-files from magnet links, but I have had it "fail" to remove a few resume files.

So torrent files should go somewhere other than hidden directories, something like downloads\torrents or documents\torrents etc.

Not according to the XDG standard, see above. Now if you are talking about the downloaded data then it's another matter, and that goes into Downloads.

More importantly the user should be given the opportunity to chose where to save these torrent files (like Vuze does) or configure a chosen directory through the Options facility.

Personally I don't think so since I don't see what is so important with these files that you need such "ready" access to them, and that you can't do it with the current setup.

It's a privacy nightmare because on a multiuser computer these directories stay forever and anybody with root has access to them and can see who was downloading what.

*sigh* Then effectively every fracking program has a "privacy nightmare problem" because most of what you do in them is not automatically deleted and root has access to it. This is like saying that it's a "privacy nightmare" because other people can go into your room to look around when sharing a house/apartment with others, or even that your landlord has access to your apartment. This "problem" is not specific to Transmission but rather the account system in any OS (not unique to Linux), but it isn't a real problem. If you don't trust those with (full) root access then just don't use that computer.
Though I am very curios to know how you envision this to be solved. How do you design it so that root (or the equivalent on any other OS) can do whatever it wants to while still keeping the privacy "intact" of the other users?

I really don't care what XDG standard says.
And you're listing totally irrelevant specs to what we're discussing here.
I consider .torrent files to be data files.
If I have a .torrent file I can open it any time in any torrent client and continue seeding or re-download the original data if I somehow lost it.
So it's like a document that can be opened again and again.
I know most people don't use .torrent files this way but I sometime continue seeding if I'm not downloading anything and have some spare bandwidth.
I also move downloaded content sometime around and need to reopen the .torrent file on another computer to continue seeding.

I'm not discussing OTHER software, but Transmission only right now, so why are you bringing up privacy issues concerning other software.
Just because other software has problems doesn't mean Transmission has to also.
With Vuze I can save .torrent file from magnet link, and after I'm done downloading and seeding it, I go to my torrent directory and delete the .torrent file. and so remove the "history".
Basically I'm in control of my .torrent files instead of the torrent client. Although Vuze does have the options to automatically delete .torrent file if the torrent is removed from the client, which is nice.
This minimalistic approach to software that's become popular with developers in recent years is troubling and I don't like it. Taking away features and configuration options is never good and only reduces quality of software.

[Jordan]

I don't really understand what OP is requesting in this thread.

When you're done with a torrent, removing it will delete the .torrent and the .resume file.

[blacke4dawn]

The key to proper communication is to be as precise as possible, there are many different meanings to the term "data". There was nothing in your previous posts about how you view the .torrent-files and why that should matter to the rest of us.

What's stopping you from saving a copy of the .torrent-file to a place of your own choosing (outside of no built-in method for doing so)?
The automatically saved .torrent-files in .config/transmission/torrents (magnet-links are saved as .torrent-files there) are automatically removed when you delete the torrent from the client, regardless of how it was added. So there is no "history" or "trail" to speak of in that regard.

I took a very quick look at Vuze since you seem to be using that as the "golden standard". The only real difference I could see among your "concerns" was that you could export (a.k.a save) the .torrent-files to another location, if you enable intermediate or advanced view in options, and that you can choose where the folder it automatically saves .torrent-files to (which by default is under a hidden folder) and even if it saves it to that folder at all. It still has the same privacy nightmare since it does save a .torrent-file of any loaded torrent in the active-folder (not configurable as far as I could see), though it uses a hash for a file name instead of the torrents name. I seriously doubt Vuze keeps track of and then deletes any .torrent-files you have exported, if I'm wrong on that then please show me.

The reason I "bring up" other software is because this so called "privacy nightmare" as you see it is on such a level that it shouldn't be dealt with on a per program basis but rather on the "account restrictions" level. However the simple fact is that if you don't trust the admins of a certain computer then don't use it in such a way.


The minimalist approach in software (at least within the Linux/Unix world) is the legacy way of doing it from before the time of fancy GUI's, that is that programs did one specific thing and did it really good.
As for "taking away" features and configuration options they haven't done so from a technical position since they have never had those before, nor is there any form of mandate/recommendation to have those in. They are only "missing" when compared to certain other clients, and many of those clients are considered bloatware by many people since "we" will only use a fraction of the features offered. Taking away features can be good and can improve quality depending on what it is, how much it was used and how it was implemented in the first place.


You know what, if you had posted this in the request section and formulated it better rather than coming in and effectively demanding it you would have gotten a much better response.

[blacke4dawn]

I don't really understand what OP is requesting in this thread.

As far as I understand it he wants the ability to export a .torrent-file from any loaded torrent and the ability to "hide" ones activity from root.

[shapeshifter910]

I don't really understand what OP is requesting in this thread.

When you're done with a torrent, removing it will delete the .torrent and the .resume file.

Ok, Thanks for clearing that up.
I did not know that removing torrent will also delete .torrent file.
Although I suspected it.
This is not a behavior I expect and I consider it a data loss.
I like having the ability to open the torrent again in the future either for seeding or for redownloading.

[shapeshifter910]

I don't really understand what OP is requesting in this thread.

As far as I understand it he wants the ability to export a .torrent-file from any loaded torrent and the ability to "hide" ones activity from root.

Well, you could call it export but any other way of preserving the .torrent file, either by having the opportunity to save it in a location of my choosing when first activating a torrent or anytime later after that is what I'm after.

No, I did not mean hiding torrent activity from root.
I simply want to be able to easily delete previous .torrent files or move them to a chosen location.
The hypothetical scenario is that on a multiuser system like Linux, if a user abandons his account, suppose he was a guest in someone's house or at any other location when he later leaves and will not use the computer again.
The account remains until deleted by root. And I was concerned that someone with root access can see remaining .torrent files in that account.

Also I might want to take those .torrent files and partial downloads with me and continue using them later elsewhere.
That's why I was surprised that .torrent files were in a hidden directory reserved for config files. Whereas I consider .torrent files more like data files than config files. Maybe it's just me.. anyway .... now that I know what's what I know where to look for them and how to get them if I need to.
A lot of other users might not though. Especially on Windows and Macs (if you stuff them in some hidden Application Data directory.

[blacke4dawn]

Well, you could call it export but any other way of preserving the .torrent file, either by having the opportunity to save it in a location of my choosing when first activating a torrent or anytime later after that is what I'm after.

Well, Vuze calls it export when doing it manually so I used that term as well.

No, I did not mean hiding torrent activity from root.
I simply want to be able to easily delete previous .torrent files or move them to a chosen location.
The hypothetical scenario is that on a multiuser system like Linux, if a user abandons his account, suppose he was a guest in someone's house or at any other location when he later leaves and will not use the computer again.
The account remains until deleted by root. And I was concerned that someone with root access can see remaining .torrent files in that account.

Then do a proper clean up, or just don't do anything on it that you don't want the others to find out, especially considering that they can still see it while you are there and most likely even while you are using that computer. Personally I do not understand why we should protect stupidity, people have to learn.

Also I might want to take those .torrent files and partial downloads with me and continue using them later elsewhere.
That's why I was surprised that .torrent files were in a hidden directory reserved for config files. Whereas I consider .torrent files more like data files than config files. Maybe it's just me.. anyway .... now that I know what's what I know where to look for them and how to get them if I need to.
A lot of other users might not though. Especially on Windows and Macs (if you stuff them in some hidden Application Data directory.

Personally I don't feel that an "export" feature is needed but I wouldn't be against it. As for being surprised that Transmission uses a hidden directory with plain .torrent-files for "configuration", it doesn't seem to be that uncommon:
Vuze does so with .azureus/active (.azureus/torrents is a secondary and optional location)
Bittorrent does so with .bittorrent/data/metainfo
Deluge does it with .config/deluge/state

[shapeshifter910]

...Macs (if you stuff them in some hidden Application Data directory.

They're not hidden on a Mac.

/Users/<username>/Library/Application Support/Transmission/Torrents

I was concerned that someone with root access can see remaining .torrent files in that account.

They should be gone if you delete the torrents from Transmission. Still, I would say, don't use the the machine if that's a concern, as other traces of your activity can be left behind---logs, for example.

Can a user see the Library folder when they open Finder?