Trac:
Cc: N/A to mikeperry

ioerror: Can you take a quick look at my version of this? You name is on the file that I hacked + the git blame. My main concern about my approach is the effective current working directory of the exe if it is called as a shortcut or something similar. Based on the existing code, it looks as if the CWD should be the TBB folder regardless, but just in case...

sjmurdoch: adding you, too. Erinn thinks you might have had a hand in this beast.

My version is at: https://gitweb.torproject.org/mikeperry/torbrowser.git/blob/886a26e5c850231012d537ffdec8f035b45dbe9a:/src/RelativeLink/RelativeLink.c

Trac:
Cc: mikeperry to mikeperry, ioerror, sjmurdoch

Turns out that MacOS also has the same problem: flash does NOT respect $HOME. It manages to find the home directory and write to it regardless of the value of $HOME.

So perhaps we do want the vidalia+qt solution here (if the qt stuff will actually work on both MacOS and Windows).

If flash doesn't respect $HOME or whatever env var it's supposed to use, how is qt or vidalia suppose to help here? It seems to me that the problem is flash, and we should be looking at a way of sandboxing it or something.

Or may be I'm not understanding the issue right.

Replying to chiiph:

If flash doesn't respect $HOME or whatever env var it's supposed to use, how is qt or vidalia suppose to help here? It seems to me that the problem is flash, and we should be looking at a way of sandboxing it or something.

Well yeah, the Qt route is the hail mary play of "test and/or read the Qt source code to see if they solved the problem some other way for MacOS". For example, the portable apps forums are filled with posts of people saying that on windows you can set $APPDATA (ie $HOME+"/Data", more or less) and it will work. However, it appears that some apps can query the kernel/runtime for an alternate version of appdata using SHGetFolderPath(). This appears to be fixable by calling SHSetFolderPath(), as I did in my windows launcher patch. http://msdn.microsoft.com/en-us/library/bb762247(v=VS.85).aspx

So the next step is determining if the Qt people know something we don't about MacOS. If they do, then we should clearly use them for both platforms. If they don't, then we should figure an alternate hack for MacOS and use both independently.

Replying to mikeperry:

However, it appears that some apps can query the kernel/runtime for an alternate version of appdata using SHGetFolderPath(). This appears to be fixable by calling SHSetFolderPath(), as I did in my windows launcher patch. http://msdn.microsoft.com/en-us/library/bb762247(v=VS.85).aspx

According to that page, SHSetFolderPath writes the new path into the system registry permanently for all programs to use.

Replying to rransom:

Replying to mikeperry:

However, it appears that some apps can query the kernel/runtime for an alternate version of appdata using SHGetFolderPath(). This appears to be fixable by calling SHSetFolderPath(), as I did in my windows launcher patch. http://msdn.microsoft.com/en-us/library/bb762247(v=VS.85).aspx

According to that page, SHSetFolderPath writes the new path into the system registry permanently for all programs to use.

I hate everything. Good catch.

Then it's either Qt to the rescue here, too, or we do something ugly like drop in a DLL that implements SHGetFolderPathW and ShGetFolderPath and returns our cwd + data...

I really want this fucker to not store LSOs before we allow people enable it. I mean, that's the least it could do. Fucking piece of garbage.

Setting the milestone because I really want to get flash at least safe enough for people to selectively enable on trusted sites on at least Windows and Linux in the 2.2.x release. I'm still not convinced that this is impossible. $APPDATA may work by itself, we still have not tested it on Windows. Or maybe the Qt people have insight. If all of that fails, then we try DLL injection. It's just one system call. I refuse to let it stop us.

Trac:
Milestone: N/A to TorBrowserBundle 2.2.x-stable

Trac:
appdata.patch

Add APPDATA env var

There's a patch for vidalia to make it set APPDATA to $pwd/Data, you can easily change it to set any env to any arbitrary value.

Any windows users want to test this patch? Otherwise we need to wait on TBB 2.3.x before we have any testing TBB builds that would include it.

Erinn - Can we not make this block on waiting for 2.3.x builds? There seems no reason for it to do so. We should test it in a random Windows build, see if it works, and then apply it in a 2.2.x release if it does, so we can move forward on testing+deploying a LSO-free click-to-play flash.

Trac:
Cc: mikeperry, ioerror, sjmurdoch to mikeperry, ioerror, sjmurdoch, erinn

Trac:
Cc: mikeperry, ioerror, sjmurdoch, erinn to mikeperry, ioerror, sjmurdoch, erinn, shondoit@gmail.com

Unfortunately ciiph's patch does not work. All it does is change the Process Environment Variable, however, SHGetFolderPath does not use this variable, but uses the registry: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders"

I did find an interesting read on API hooks, injections, etc. which contains quite some information. - http://codeproject.com/KB/system/hooksys.aspx

Trac:
Component: Vidalia to Tor Browser
Summary: set %APPDATA% in Vidalia for TBB to Disable flash's "allow cookies" pref somehow
Owner: chiiph to mikeperry

Trac:
Parent: N/A to #7008 (moved)

There's another file other than settings.sol called mms.cfg we could use, but it seems even more system-wide than settings.sol. I bet Flash also uses a registry key on Windows to determine its location.

http://www.ghacks.net/2010/09/07/enforce-global-flash-player-security-and-privacy-settings/

Trac:
Keywords: N/A deleted, tbb-firefox-patch added