Privoxy: Submitting Javascript-Forms

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We just found a post on the onionforum (tor required) with a nice filter for privoxy.

It adds a submit-button to forms that are usually submitted via javascript and makes them usable for javascript-disabled browsers.

Add this to your .filter -file

FILTER: unhide
s@(<input type="?)hidden("?[^>]+name="?([^" >]+)"?)@$1text$2 style="background-color:RoyalBlue" title="$3"@gis
s@<input type="submit" value="s" style="background-color:RoyalBlue"></form>@<input type="submit" value="s" style="background-color:RoyalBlue"><input type="submit" value="s" style="background-color:RoyalBlue"></form>@gis
s@display: ?none@background-color:CornflowerBlue@gis
s@(<[^>]*?)disabled(="disabled")?@$1@gis

...and the following to your .action -file:

{ +filter{unhide} }
/

..or to enable this only for specific sites:

{ +filter{unhide} }
.evilshare.com/
.example.com

If it does not work, you can try:

{ +filter{unhide} +prevent-compression }

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFH64tjLAZ+Vq4hPgARAnh7AJ9AM140LvxN7PYYiC3q+gREN4TrPgCfSrnQ
eZUGPh2diU98pDmXLAfC7q0=
=Rq8g
-----END PGP SIGNATURE-----

faster ssh/scp on SMP/multi-core systems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A nice paper just popped up on
the tor-mailing list.

Abstract
SCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients. However, the host receiving the data must have a properly tuned TCP/IP stack. Please refer to this tuning page for more information.

The amount of improvement any specific user will see is dependent on a number of issues. Transfer rates cannot exceed the capacity of the network nor the throughput of the I/O subsystem including the disk and memory speed. The improvement will also be highly influenced by the capacity of the processor to perform the encryption and decryption. Less computational expensive ciphers will often provide better throughput than more complex ciphers.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFHs/FVLAZ+Vq4hPgARAt3SAKCe3ntK729GBG3uAY6PMh6Xa9WjXgCg1Swr
vv3DTUO3G+/c4w7utqmuCuI=
=pzqX
-----END PGP SIGNATURE-----

getting anonymous gpg-keys signed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


GPG is a fine thing with it's web of trust.
But the probleme here being...a web of trust is not anonymous.
There is no identity to prove to get a key sign if you want to
be anonymous.

One nice service here is the
PGP Global Directory.
It does only checks that one of the email-adresses in the key indeed works.
Just like a double-opt-in.

Another one is the robotCA, where you send an email to robotca AT signedtimestamp DOT org with the subject "sign key: your key id" (e.g. "sign key: AE213E00") and it will load that key from a keyserver and send a signed copy to the email-adresses in it.

But at least that's something that can be done.
Verify that the key-owner can recevive at that that address without sending a message yourself.
(Like, if that key is to be used outside of an email-context.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFHuZdjLAZ+Vq4hPgARAoJUAJ975yR30c11Tj0PI0oOLMmmkgm2KQCdFTl6
dq9/QQi+jM396gv8XAFmurQ=
=y1vL
-----END PGP SIGNATURE-----