Limit Display of Folder Path to downloading users (Privacy Issue)

Submitted by Insiteful on Fri, 05/11/2012 - 18:20
Description: 
I am fairly new to SoulseekQT, running the 5/10/2012 client on a mac. I see that when uploading files to users, my mac computer's FULL path (from the root folder/computer name) is clearly displayed in the downloading users' transfer window. For privacy reasons, I feel that the folder path displayed should be limited to the uploader's SHARE folder and subfolders. For example, on my Mac my home folder (root) might be JOHNSMAC. I would like to share my iTunes folder which is located in JOHNSMAC\Macintosh HD\Users\JohnDoe\Music\iTunes\iTunes Music. If I add that "iTunes Music" folder to my shared folders list (or if I choose any other folder on my computer), then every time that a user downloads a file, SoulseekQT displays my full folder path, including my mac computer name and my user name (which is my real name). I have looked for a workaround on this by trying to use an alias or shortcut, but cannot find one. Forgive me if I am missing something. For reasons I cannot go into, I cannot rename my computer's root name or my user name. Thanks.
Status: 
Done
0
Your rating: None
1
Average: 1 (12 votes)

Comments

Submitted by Nir on Sat, 05/12/2012 - 15:38.

I do think limiting the the path to the shared folder is a good idea. I believe I looked into this, and the problem is that unless you browse the user, your client doesn't know which subfolder is the base shared folder. This isn't information that's transmitted with the search results. A possible alternative might be to only show the last two or three subfolders at most, and to never show drive letters if those aren't cut out by the preceding rule.

Submitted by J_plus on Thu, 08/23/2012 - 02:30.

Nicotine+ lets you define multiple shares root folders, which are completely independent in the shares list that is sent to other peers. They can even be renamed, so the actual name of the folder is never shown. In any case their parent folders aren't part of the download path. Perhaps you could allow something similar in SoulseekQt?

Submitted by Insiteful on Fri, 05/18/2012 - 09:12.

Why is it necessary to display any of the uploader's "path" information at all in the "downloading transfers" window? I am not sure it is useful information, anyway. Would it be more relevant and useful to show the path on the downloader's computer where the file(s) can be found?

Submitted by secretsquizza on Tue, 05/15/2012 - 10:15.

I have to agree with insiteful. The paths should be relative to the shared base folder and not displaying the full path or anything before the share base node.

For example let's say i'm sharing two distinct folders (c:\my music\slsk\shared\music and d:\pictures - for example). The path displayed should start at music and pictures as these are the share base nodes - if you need a fixed base folder higher in the tree (as a common start node) then the slsk username seems the easiest here.

If it's programmatically difficult to acheive then the client could send the full paths as necessary and simply replace anything earlier in the folder tree with the username of the client for display purposes.

vike's picture

Submitted by vike on Thu, 06/21/2012 - 05:52.

I find it hard to talk programming ideas without knowing anything much of the codebase but here is a try to solve it without any "fixed base folder" or "slsk username" :)
Publicly communicating a user-entered share path using the basename - suffixed with e.g. " (number)" if occurring multiple times (when indexing) - and privately, in a persistent db, hashing the full dirname with that basename as key (again when indexing) for local translation.

The paths in the following example are perhaps better left alone than replacing with such keys - which i'd say shows for the use of a user setting (perhaps even per shared path). (Using Mac, I prefer using POSIX paths in the following example.)

A) Indexed shared directory "/pictures/shared" with local file "/pictures/shared/image.pct" as public path "shared/image.pct" - locally storing "/pictures/shared" for key "shared".
B) Indexed shared directory "/text/shared" with local file "/text/shared/example.txt" as public path "shared (2)/example.txt" - locally storing "/text/shared" for key "shared (2)".

1) Incoming search request for "example"
2) Outgoing search result for "example" with "shared (2)/example.txt"
3) Incoming data request for "shared (2)/example.txt"
4) Outgoing data result for "shared (2)/example.txt" with "/text/shared/example.txt"

Hope it makes sense.

Submitted by Nir on Thu, 06/21/2012 - 11:30.

That's not a bad idea. You can even go as far as refer to each shared master folder numerically without checking for identical subfolder names. i.e. first shared folder is %1, second folder is %2 and so on. To adapt your example, image.pct would be referred to externally as %1/shared/image.pct and example.txt as %2/shared/example.txt (The 'shared' subfolder name after each number is redundant, but is there for the benefit of the remote user). Aside from deciding how to generate these keys, the rest would be exactly as you suggest it. I would have to look into the code to see how difficult it would be to adapt it to use such a system.

Thanks, Nir

Submitted by monsieurX on Sat, 05/19/2012 - 01:36.

Linux rules! =D

NOBODY can see my real path when I don't want to, not even in the current client. The "trick" is that for everything I share, I would make extensive use of symlinks, so for a folder like

/media/sdb5/home/myname/slsk_shared

I would do a

sudo ln -s /media/sdb5/home/myname/slsk_shared /symlinks/slsk_public

and just share my "/symlinks/slsk_public" folder, hiding my Linux username 'myname' from the curious world.
Gladly symlinks are perfectly supported in SlskQt.

Windows XP/Vista/7/8 users can do that as well, using "junctions":
Right-click "My Computer" and say "Manage". Now you can see your partitions. And instead of drive letters apart from C:, you may also set FOLDERS pointing to drives.

So instead of

C:\Users\JohnRSmith\personal\slsk_shared

you can create for yourself a

C:\Mounts\slsk_shared

junction, which would hide your real name that you used as a username.
And don't get confused by the 'C:\'! A folder on C:\Mounts can even point to a different HDD. Only you will know about it, though.

The pro's can also do this with "mklink" tool, but that's for the advanced folks.

Submitted by Insiteful on Fri, 05/18/2012 - 09:16.

Any good workaround tips for us Mac OS 10.6 (Snow Leopard) users? I have tried creating an "alias", but the full path is still displayed in SoulseekQT...

vike's picture

Submitted by vike on Wed, 06/20/2012 - 11:32.

The above tip about symbolic linking on linux also applies to Mac.

1 Open the application Terminal.
2 Type "ln -svi" and a space after that. (ln means link - 's' means symbolic or soft, 'v' means verbose and 'i' means interactive)
3 Drag the folder (or file or volume) that you want the link to point to, and drop it onto the Terminal window
4 Drag the folder (or file or volume) that you want to create the link in, and drop it onto the Terminal window
5 Hit return or enter. You can now quit Terminal.

If that fails and you have an administrator account, you can type "sudo ln -svi" and a space, in step 2.

The link will be created with the same name as in the path dropped in step 3.
You may rename or move the link however you wish. If you rename any part of the path dropped in step 3, the link is broken and you must repeat the process (unlike with the alias).

Hope it works and helps. Cheers

Submitted by Insiteful on Thu, 06/21/2012 - 14:45.

Thanks, vike for your reply. Well, your procedure does provide a workaround on my mac! Following your instructions, I created the symbolic folder that links to my "iTunes Music" folder, that contains my music library. Then, I placed the "link" into a dedicated folder (called "My Music") in my drive's root folder. When I added that "My Music" folder (containing the "link") as a share folder in slskqt's options/file sharing tab, SoulseekQT only displays the path to "My Music", then it's sub-folder "iTunes Music", avoiding the display of the confidential folder name in the full path. When I browse my own files, I again only see the limited path. I assume that other users would see only the limited path as well. Thanks again!

Submitted by Insiteful on Sun, 12/16/2012 - 20:34.

A user informed me that they could not browse my files. After checking (by browsing my own files), I see that the symbolic links that I had placed in my folder "My Music" no longer appear as a sub-folders when I browse in SoulseekQT. However, if I browse to the "My Music" folder using Mac's Finder, the symbolic links are still there, and they work just fine when I click on them (The symbolic links are there, but SoulseekQT no longer recognizes them as sub-folders.) :-\ I have recently upgraded to Mountain Lion - could that be the reason? Has this problem (privacy issue displaying full path) been addressed in SoulseekQT in any other way? I'd appreciate any help, as I cannot share until I am able to resolve this privacy issue once again. Thanks.

Submitted by vanhouten on Sun, 02/17/2013 - 06:37.

This symlink trick doesn't work on my mac either (ver 10.6)

vike's picture

Submitted by vike on Sat, 03/09/2013 - 04:28.

I do not use symlinks with SoulseekQt myself and i'm still on OS Snow Leopard (10.6.8). Actually i haven't used slsk in a while now.
The only thing i can suggest is to check that all folders from root (system startup volume aka "/") and up to the symlink itself has at least execute rights for your user account. The execute right (mode bit) allows lookup by name ("search") in a directory. The lack of execute rights is something that stops my http-server from resolving symlinks, but then again that server is run as another user than me...
The way i check rights is with "ls" in the terminal as follows,
ls -d /Volumes/volumeName/path
and then adding execute rights with "chmod" as follows,
chmod +X /Volumes/volumeName/path
Please try the following to see other ways to use chmod,
man chmod
Feel free to ask if you're unsure in any way.

I suggested the above by PM to Insiteful (who got it working on 10.6) in the end of last yesr but havent heard from him since.

Anao55's picture

Submitted by Anao55 on Sat, 06/01/2013 - 14:46.

I'm bumping this!
I just disabled all my sharing folders after realizing the path is public.
Might create a root folder with couple of albums just to bypass the "share something" restriction, but I wish I could actually contribute with my actual libraries.

Submitted by bucketcheck on Fri, 08/09/2013 - 05:46.

I would also love a resolution to this issue...I'm eager to share but not prepared to put my full name out there. Anyone have any other ideas?

Submitted by liquidfox on Fri, 08/23/2013 - 15:06.

One temp solution is to add an external HD and direct SS to that....but I really need a more convenient way to hide my private info so I can share all my music without worrying.

RPMX's picture

Submitted by RPMX on Thu, 02/06/2014 - 16:28.

we all could put our files into a folder "nir is a porn star!" to get more attention... rofl... voted :)

Submitted by gripmonkey on Mon, 10/06/2014 - 03:33.

Yes please fix this!!!

Submitted by Kaiyum on Wed, 10/08/2014 - 01:48.

External HDD doesn't show any information...With a USB3 one anyone should be fine..

Submitted by Nir on Wed, 10/08/2014 - 14:09.

Well, I'm a little less than thrilled about what ended up being kind of a hack, but this should achieve the purpose of not showing folders above the main shared folder. So paths that normally look like this:

/home/my_name/shared_files/folder_a

Will look something like this:

@@dleng/shared_files/folder_a

Essentially everything above the master shared folder will be replaced by @@[five random letters]. I haven't gotten around yet to actually hiding this @@ code in received search results, I guess that's the next step. Let me know how it works for you!

https://www.dropbox.com/s/x9wnnbkg6uyuios/SoulseekQt-2014-10-8.exe?dl=0

Submitted by Insiteful on Mon, 10/20/2014 - 09:34.

Mac version, please?
I would be happy to take it for a test-drive. Could you please post the mac version? Thanks.

Submitted by Nir on Mon, 10/20/2014 - 13:52.

Ah sorry, I forgot I promised you a build. Try this one, I believe it should have the feature implemented:

http://www.soulseekqt.net/news/comment/5236#comment-5236

Submitted by Insiteful on Mon, 10/20/2014 - 15:29.

Hi, Nir,
I downloaded

https://www.dropbox.com/s/bfx2wfmj6gb22f1/SoulseekQt-2014-10-14.dmg?dl=0,

and browsed & downloaded one of my own files, but the full path is still displayed in the transfer window...

Submitted by Nir on Tue, 10/21/2014 - 10:31.

Ah yeah, oversight on my part. The hiding of folders below the master shared folder is currently only done when returning search results. I failed to consider that the full paths for browsed files appear when you download a file as well. Let me work some more on this and I'll post another build.

Thanks, Nir

Submitted by Insiteful on Tue, 10/21/2014 - 10:45.

Also, while you are turning your attention to this issue, perhaps you could also consider the symlink issue (noted above, and also at http://www.soulseekqt.net/news/node/2441) which can also be used as a powerful tool for protecting user privacy. ;)

Submitted by Nir on Tue, 10/21/2014 - 11:53.

Absolutely, I'll look into getting symlinks to work again.

Submitted by Nir on Thu, 10/23/2014 - 16:43.

Here we go, this should hide folders when browsing shares as well as in search results:

https://www.dropbox.com/s/ygrekv5o3t1u0o7/SoulseekQt-2014-10-23.dmg?dl=0

I will look into symlinks next.

dogbite's picture

Submitted by dogbite on Wed, 10/22/2014 - 03:24.

It is an slight privacy issue but i dont see whats the big deal about this one. Why not just remove your name and put something else. If you have a privacy issues why would your pc contain your real name in the first place, you do realize anywhere you go on the internetz some serious privacy information is being collected from your machine. I believe slsk is fairly private, better than torrenting in my opinion.