pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] My list of present problems with Pan.


From: Duncan
Subject: Re: [Pan-devel] My list of present problems with Pan.
Date: Tue, 18 Oct 2011 11:13:31 +0000 (UTC)
User-agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 8e43cc5 branch-master)

Heinrich Müller posted on Tue, 18 Oct 2011 09:41:48 +0000 as excerpted:

> Am Mon, 17 Oct 2011 20:13:48 +0000 schrieb SciFi:
> 
>> Hi,
>> 
>> I should probably post the concerns I'm still having with Pan.  I sent
>> this to imhotep82 (Heinrich Müller, before he became judgefudge), and
>> to lostcoder (K. Haley) some months ago.  These will likely apply to
>> whatever platform I end-up building.  My current Pan build can be seen
>> with this post's headers under User-Agent (I'll send judgefudge the
>> patches that "enhance" that string, soonish).
>> 
> Which patch? I see the user-agent with the git branch and commit
> checksum already in my headers. But feel free to drop me a mail.

If you checked his headers, you'd have also noted:

* git repo/tree (github.com/judgefudge/pan2/master , so way more than 
simply the branch, which when simply "master" doesn't yield much clue at 
all).

* compiler used for the build along with a bunch of compiler and build 
related info (gcc 4.2.1, with a build number, presumably apple-supplied, 
and target bit-mode, 32-bit)

* compiler build (566 (dot3))

* apparently the build target (x86_64-apple-darwin10.8.0 in his case, but 
32-bit mode, see above)


FWIW, before we get anything close to this level of detail (git commit is 
actually more info than many would be comfortable with), we really need 
to think about privacy a bit, and while having all those bits in-string 
by default is arguably good, pan should definitely have a user-agent 
customizing GUI that allows those who prefer, to opt out of bits of it, 
or indeed the whole thing.

For those who might be a bit concerned about privacy and who wish to keep 
their identity between themselves and their provider, just the pan 
version number/name string alone is already more information than many 
would prefer to have stamped on every post they make, thereby making it 
easier for other than their NSP to trace even posts with otherwise fake 
info such as email, and no in-the-clear NNTP-Posting-Host if they have a 
decent provider.  Such a version string does provide /some/ info, but 
it's a reasonable level and presumably, there's enough people running the 
same version that it's not /too/ identifying.

But adding commit ID could very well be uniquely traceable by itself, for 
those who build direct from git, and adding git tree and branch and all 
that compiler info is nearly surely so, especially on rarer pan platforms 
such as OSX.  (Tho for folks sticking to distro provided versions, it 
probably wouldn't be uniquely identifying by itself, but could be after 
taking nsp-inserted-headers into account, even if they don't include nntp-
posting-host or hash it along with a salt and the time or some such so 
it's never the same thing twice even for the same poster).

I /have/ occasionally wondered why pan doesn't expose that info for 
customization, at least in preferences.xml if not in the GUI, but this 
makes the problem /much/ worse.

FWIW, I'd suggest an option in the posting profile, with checkboxes for 
the various string components and a textbox for a customized string.  (Or 
if preferred, just the checkboxes, disabling the header entirely if 
they're all unchecked, in which case a user could add a custom header as 
they normally would, if they want an entirely custom user-agent.)

... And an observation.  The create/edit posting profile dialog might be 
big enough with the user-agent UI added, to consider making it a tabbed 
dialog.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]