Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[dialog] Set the header date to a different TIMEZONE than the machine time zone?
10 views
Skip to first unread message
R Radev
Sep 1, 2018, 9:09:58 PM9/1/18
to
Hopefully Michael Bauerle or Bernd Rose or Jernej Simoncic will see this.
*Is there a way to set the resulting DATE header to a given TIME ZONE?*
If I do nothing, 40Tude Dialog will use the Windows 10 system date and time
zone as the default Dialog-generated date header. For example:
Date: Sat, 1 Sep 2018 12:34:56 +0300
In an "OnBeforeSendingMessage" script I can remove that default
dialog-generated date header so that the nntp newssesrver default time zone
will replace my Windows 10 system date. For example:
Date: Sat, 1 Sep 2018 12:34:56 +0000 (UTC)
Conversely, I can do nothing in Dialog and just change my system time zone.
For example, if I change that time zone to "Dublin", the date header is:
Date: Sat, 1 Sep 2018 12:34:56 +0100
If I change that Windows 10 system time zone to "Tehran", the header is:
Date: Sat, 1 Sep 2018 12:34:56 +0300
(Ignore that the time & date may change - just look at the UTC offset!)
My rationale is dead simple as to "why" I wish to spoof the time zone.
a. I don't wish to give out my time zone (ie UTC offset), and
b. I don't wish to be obvious with a "+0000 (UTC)" time zone.
I understand this is a difficult question for anyone to answer, which is
why I hope Michael Bauerle or Bernd Rose or Jernej Simoncic will see this.
Is there a way to spoof the date header in 40tude Dialog 2.0.15.84 on
Windows 10 without having to actually change the system date?
*Is there a way to set the resulting DATE header to a given TIME ZONE?*
If I do nothing, 40Tude Dialog will use the Windows 10 system date and time
zone as the default Dialog-generated date header. For example:
Date: Sat, 1 Sep 2018 12:34:56 +0300
In an "OnBeforeSendingMessage" script I can remove that default
dialog-generated date header so that the nntp newssesrver default time zone
will replace my Windows 10 system date. For example:
Date: Sat, 1 Sep 2018 12:34:56 +0000 (UTC)
Conversely, I can do nothing in Dialog and just change my system time zone.
For example, if I change that time zone to "Dublin", the date header is:
Date: Sat, 1 Sep 2018 12:34:56 +0100
If I change that Windows 10 system time zone to "Tehran", the header is:
Date: Sat, 1 Sep 2018 12:34:56 +0300
(Ignore that the time & date may change - just look at the UTC offset!)
My rationale is dead simple as to "why" I wish to spoof the time zone.
a. I don't wish to give out my time zone (ie UTC offset), and
b. I don't wish to be obvious with a "+0000 (UTC)" time zone.
I understand this is a difficult question for anyone to answer, which is
why I hope Michael Bauerle or Bernd Rose or Jernej Simoncic will see this.
Is there a way to spoof the date header in 40tude Dialog 2.0.15.84 on
Windows 10 without having to actually change the system date?
Bernd Rose
Sep 2, 2018, 2:51:34 AM9/2/18
to
On Sun, 2nd Sep 2018 04:10:02 +0300, R Radev wrote:
> *Is there a way to set the resulting DATE header to a given TIME ZONE?*
[...]
> *Is there a way to set the resulting DATE header to a given TIME ZONE?*
> My rationale is dead simple as to "why" I wish to spoof the time zone.
> a. I don't wish to give out my time zone (ie UTC offset), and
> b. I don't wish to be obvious with a "+0000 (UTC)" time zone.
I'm not convinced, that your intentions really are beneficial (or at least
> a. I don't wish to give out my time zone (ie UTC offset), and
> b. I don't wish to be obvious with a "+0000 (UTC)" time zone.
non-harmful) to the Usenet. But since there are several obvious ways (some
of them already pointed out by you) to spoof the timezone information, and
you /may/ need to cover participation in a political discourse from an
undemocratic government or the like, I'll give you some loose pointers:
OnBeforeSendingMessage can not only be used to delete headers, but also
to modify them. You'd need to modify the timezone offset as well as the
hour part to get consistent information. And if you cross midnight doing
so, you'd need to adjust date information (including the weekday string),
as well. The Dialog Script Library may give you some ideas:
http://dialog.datalist.org/scripts/script_library.html
There have been versions of the nFilter news proxy program around, which
supported the modification of /outgoing/ messages as well as incoming.
There may be other tools available, doing the same.
If you run Dialog inside a virtual machine, you can set its date to
whatever timezone you like. - Independently to your main (host) machine.
And that's all I have to say on these matters.
As a side-note:
> in 40tude Dialog 2.0.15.84
Dialog .84 is in Alpha state with no real functional updates, but several
severe changes under the hood, that are buggy. (Although the program
all-in-all is stable in most situations.) Marcus did several updates,
afterwards, but never released any. (Even the .84 wasn't released, but
leaked by an alpha-tester.)
Some problems (e.g. with the new memory manager) were unresolvable. So
Marcus ended development. The only version that, IMHO, should be used,
is .41, which had been officially released via Mantis and is the last
version of the earlier development chain. Only people using certain older
(rare) AMD processors, that trigger a bug in the older Delphi libraries
used to compile the .41 are better off using .84.
Bernd
R Radev
Sep 2, 2018, 4:26:22 AM9/2/18
to
Bernd Rose <b.rose...@arcor.de> - 2018/09/02
> I'm not convinced, that your intentions really are beneficial (or at least
> non-harmful) to the Usenet. But since there are several obvious ways (some
> of them already pointed out by you) to spoof the timezone information, and
> you /may/ need to cover participation in a political discourse from an
> undemocratic government or the like, I'll give you some loose pointers:
Thanks Bernd for suggesting a possible timezone setting method in Dialog.
Note that I've roughly duplicated your headers simply by way of example.
(I didn't bother getting an Albasani account although I could have if I had
enough time to obtain one before sending this message out as an example.)
I can already change the time zone manually from within Windows, so what I
simply need is to figure out the best way to get Dialog to change the time
zone. NOTE: I'm using Dialog for this message.
As far as I know, the easiest non-Dialog way to change JUST the timezone on
Windows 10 is to have dialog run a simple script such as this one.
@echo off
REM tzset_tehran.bat
C:\Windows\System32\tzutil.exe /s "Iran Standard Time"
exit
Where it's easy to check the current time zone using something like
echo off
REM tzlist_current.bat
C:\Windows\System32\tzutil.exe /g
pause
exit
As far as I can tell, this causes absolutely zero problems for Usenet since
the local time in the newly set timezone automatically adjusts perfectly.
The question is how to get Dialog to run that script, I guess, if that's
the only way the system timezone can be changed from within Dialog.
NOTE: I do not want to set the whole static date like I did with the
message id of this message, so I have no intention of manually setting the
entire Date header (although I certainly can do that - it's not elegant in
the least and it's too manual).
I guess I could have dialog figure out the system time though, and THEN set
the date header based on the current system time and the desired time zone.
Is _that_ what you're suggesting?
> OnBeforeSendingMessage can not only be used to delete headers, but also
> to modify them.
I have never been able to get the time-zone related headers modified in
OnBeforeSendingMessage without having to change the _entire_ Date header
(which isn't what I want unless that's the _only_ way to set the timezone
from inside of Dialog).
Certainly OnBeforeSendingMessage can easily delete (and reset as desired)
the following local headers such that they are never sent to the nntp
server by Dialog.
'Date: '
'User-Agent: '
'Message-ID: '
'Mime-Version: '
'Content-Type: '
'Content-Transfer-Encoding: '
But unless you explicitly set the entire date (which isn't the question), I
have never found a way yet to change JUST the timezone that Dialog reports
to the nntp server from within OnBeforeSendingMessage scripts.
I should repeat that I have zero intention to set the entire date field.
I only want to change the timezone. Nothing else.
The time and date should AUTOMATICALLY set themselves based on the TZ.
> You'd need to modify the timezone offset as well as the
> hour part to get consistent information.
I apologize for not being clear in that I have no intention to change the
time or date. I ONLY want to set the TIMEZONE. Nothing else.
As noted, I can easily do this OUTSIDE of Dialog (using tzutil.exe).
I'm just asking for a way to do it INSIDE of Dialog.
> And if you cross midnight doing
> so, you'd need to adjust date information (including the weekday string),
> as well. The Dialog Script Library may give you some ideas:
>
> http://dialog.datalist.org/scripts/script_library.html
I've been there MANY times. Many many many times.
For example, this removes any of those easily removed headers.
http://dialog.datalist.org/scripts/RemoveAnyHeader.html
And this changes a header:
http://dialog.datalist.org/scripts/ScriptChangeheader.html
And this customizes the user agent:
http://dialog.datalist.org/scripts/CustomizeUserAgent.html
As I said, I can remove & statically set any of these default headers:
'Date: '
'User-Agent: '
'Message-ID: '
'Mime-Version: '
'Content-Type: '
'Content-Transfer-Encoding: '
The problem is setting JUST the time zone.
I don't want to set the date.
Of course _that_ would work to set the date manually.
I guess I could script a lookup that figures out the current date and then
given the desired GMT offset it writes the date code exactly for each
message.
Is _that_ what you suggest?
Allow me to be clear that I didn't want to do that - but is that what
you're suggesting which is to write a script that figures out the current
date and then which applies its own offset to that current date and sends
that static date as a STATIC Date header?
> There have been versions of the nFilter news proxy program around, which
> supported the modification of /outgoing/ messages as well as incoming.
> There may be other tools available, doing the same.
I am not sure what NFilter does, but I already have no problem modifying
outgoing messages with STATIC complete headers such as the Date header.
But I don't want to write a STATIC date header if I can avoid it.
I just want to change the TIMEZONE that Dialog uses when communicating to
the nntp news server.
The question is whether that is possible or not.
> If you run Dialog inside a virtual machine, you can set its date to
> whatever timezone you like. - Independently to your main (host) machine.
Yes. Agreed. It's easier though to just set the TimeZone using the Windows
tzutil.exe command since it can be placed in a batch script.
I just got an idea though. Maybe I can get OnBeforeSendingMessage to run
that batch script to set the system timezone (tzset_tehran.bat) and then,
after the message is sent, then Dialog could reset the system timezone back
to the original (tzset_london.bat)?
Would you suggest that approach?
> Dialog .84 is in Alpha state with no real functional updates
Thanks for that advice. I can use any Dialog and I've been using the
current version for many years, but if it crashes too much, I can change
the version without any problems whatsoever. Thanks for that advice.
> I'm not convinced, that your intentions really are beneficial (or at least
> non-harmful) to the Usenet. But since there are several obvious ways (some
> of them already pointed out by you) to spoof the timezone information, and
> you /may/ need to cover participation in a political discourse from an
> undemocratic government or the like, I'll give you some loose pointers:
Note that I've roughly duplicated your headers simply by way of example.
(I didn't bother getting an Albasani account although I could have if I had
enough time to obtain one before sending this message out as an example.)
I can already change the time zone manually from within Windows, so what I
simply need is to figure out the best way to get Dialog to change the time
zone. NOTE: I'm using Dialog for this message.
As far as I know, the easiest non-Dialog way to change JUST the timezone on
Windows 10 is to have dialog run a simple script such as this one.
@echo off
REM tzset_tehran.bat
C:\Windows\System32\tzutil.exe /s "Iran Standard Time"
exit
Where it's easy to check the current time zone using something like
echo off
REM tzlist_current.bat
C:\Windows\System32\tzutil.exe /g
pause
exit
As far as I can tell, this causes absolutely zero problems for Usenet since
the local time in the newly set timezone automatically adjusts perfectly.
The question is how to get Dialog to run that script, I guess, if that's
the only way the system timezone can be changed from within Dialog.
NOTE: I do not want to set the whole static date like I did with the
message id of this message, so I have no intention of manually setting the
entire Date header (although I certainly can do that - it's not elegant in
the least and it's too manual).
I guess I could have dialog figure out the system time though, and THEN set
the date header based on the current system time and the desired time zone.
Is _that_ what you're suggesting?
> OnBeforeSendingMessage can not only be used to delete headers, but also
> to modify them.
OnBeforeSendingMessage without having to change the _entire_ Date header
(which isn't what I want unless that's the _only_ way to set the timezone
from inside of Dialog).
Certainly OnBeforeSendingMessage can easily delete (and reset as desired)
the following local headers such that they are never sent to the nntp
server by Dialog.
'Date: '
'User-Agent: '
'Message-ID: '
'Mime-Version: '
'Content-Type: '
'Content-Transfer-Encoding: '
But unless you explicitly set the entire date (which isn't the question), I
have never found a way yet to change JUST the timezone that Dialog reports
to the nntp server from within OnBeforeSendingMessage scripts.
I should repeat that I have zero intention to set the entire date field.
I only want to change the timezone. Nothing else.
The time and date should AUTOMATICALLY set themselves based on the TZ.
> You'd need to modify the timezone offset as well as the
> hour part to get consistent information.
time or date. I ONLY want to set the TIMEZONE. Nothing else.
As noted, I can easily do this OUTSIDE of Dialog (using tzutil.exe).
I'm just asking for a way to do it INSIDE of Dialog.
> And if you cross midnight doing
> so, you'd need to adjust date information (including the weekday string),
> as well. The Dialog Script Library may give you some ideas:
>
> http://dialog.datalist.org/scripts/script_library.html
For example, this removes any of those easily removed headers.
http://dialog.datalist.org/scripts/RemoveAnyHeader.html
And this changes a header:
http://dialog.datalist.org/scripts/ScriptChangeheader.html
And this customizes the user agent:
http://dialog.datalist.org/scripts/CustomizeUserAgent.html
As I said, I can remove & statically set any of these default headers:
'Date: '
'User-Agent: '
'Message-ID: '
'Mime-Version: '
'Content-Type: '
'Content-Transfer-Encoding: '
The problem is setting JUST the time zone.
I don't want to set the date.
Of course _that_ would work to set the date manually.
I guess I could script a lookup that figures out the current date and then
given the desired GMT offset it writes the date code exactly for each
message.
Is _that_ what you suggest?
Allow me to be clear that I didn't want to do that - but is that what
you're suggesting which is to write a script that figures out the current
date and then which applies its own offset to that current date and sends
that static date as a STATIC Date header?
> There have been versions of the nFilter news proxy program around, which
> supported the modification of /outgoing/ messages as well as incoming.
> There may be other tools available, doing the same.
outgoing messages with STATIC complete headers such as the Date header.
But I don't want to write a STATIC date header if I can avoid it.
I just want to change the TIMEZONE that Dialog uses when communicating to
the nntp news server.
The question is whether that is possible or not.
> If you run Dialog inside a virtual machine, you can set its date to
> whatever timezone you like. - Independently to your main (host) machine.
tzutil.exe command since it can be placed in a batch script.
I just got an idea though. Maybe I can get OnBeforeSendingMessage to run
that batch script to set the system timezone (tzset_tehran.bat) and then,
after the message is sent, then Dialog could reset the system timezone back
to the original (tzset_london.bat)?
Would you suggest that approach?
> Dialog .84 is in Alpha state with no real functional updates
current version for many years, but if it crashes too much, I can change
the version without any problems whatsoever. Thanks for that advice.
R Radev
Sep 2, 2018, 5:05:49 AM9/2/18
to
R Radev <rradev...@blizoo.bg> - 2018/09/02
> I just got an idea though. Maybe I can get OnBeforeSendingMessage to run
> that batch script to set the system timezone (tzset_tehran.bat) and then,
> after the message is sent, then Dialog could reset the system timezone back
> to the original (tzset_london.bat)?
Note: I deleted the date header, so this example should show TZ +0000.
For example: Sun, 2 Sep 2018 09:03:14 +0000 (UTC)
Hi Bernd,
Thinking about your response, are you suggesting I have two options to set
the TimeZone dynamically from within Dialog?
(Assume I am in London but I want a message to have a Berlin TimeZone.)
1. Make Dialog set the system TZ to Berlin before sending the message?
tzutil /s "W. Europe Standard Time"
(then have Dialog reset the system TZ back to London after sending?)
tzutil /s "GMT Standard Time"
2. Make Dialog get the date & time & timezone before sending the message
date /T (this gets the current system date)
time /T (this gets the current system time)
tzutil /g (this gets the current system TZ)
(then calculate the new date based on the new desired time zone?)
NOTE that this second method sets a *static* Date header, which I was
trying to avoid because any mistake will cause the nntp server to barf.
> I just got an idea though. Maybe I can get OnBeforeSendingMessage to run
> that batch script to set the system timezone (tzset_tehran.bat) and then,
> after the message is sent, then Dialog could reset the system timezone back
> to the original (tzset_london.bat)?
For example: Sun, 2 Sep 2018 09:03:14 +0000 (UTC)
Hi Bernd,
Thinking about your response, are you suggesting I have two options to set
the TimeZone dynamically from within Dialog?
(Assume I am in London but I want a message to have a Berlin TimeZone.)
1. Make Dialog set the system TZ to Berlin before sending the message?
tzutil /s "W. Europe Standard Time"
(then have Dialog reset the system TZ back to London after sending?)
tzutil /s "GMT Standard Time"
2. Make Dialog get the date & time & timezone before sending the message
date /T (this gets the current system date)
time /T (this gets the current system time)
tzutil /g (this gets the current system TZ)
(then calculate the new date based on the new desired time zone?)
NOTE that this second method sets a *static* Date header, which I was
trying to avoid because any mistake will cause the nntp server to barf.
Bernd Rose
Sep 2, 2018, 5:06:20 AM9/2/18
to
On Sun, 2nd Sep 2018 10:26:26 +0200, R Radev wrote:
> I have never been able to get the time-zone related headers modified in
> OnBeforeSendingMessage without having to change the _entire_ Date header
> (which isn't what I want unless that's the _only_ way to set the timezone
> from inside of Dialog).
[...]
> I have never been able to get the time-zone related headers modified in
> OnBeforeSendingMessage without having to change the _entire_ Date header
> (which isn't what I want unless that's the _only_ way to set the timezone
> from inside of Dialog).
> I should repeat that I have zero intention to set the entire date field.
> I only want to change the timezone. Nothing else.
> The time and date should AUTOMATICALLY set themselves based on the TZ.
The date header is already adjusted to your current OS settings when it
> I only want to change the timezone. Nothing else.
> The time and date should AUTOMATICALLY set themselves based on the TZ.
arrives at OnBeforeSendingMessage. (With regard to 40tude Dialogs internal
header processing, it is fixed and not to be looked at, again. The code
inside OnBeforeSendingMessage is the last code modifying a posting inside
Dialog.) So, of course, you'd have to adjust the /whole/ date entry, if you
wish it to resemble a different timezone while still being consistent with
the time of earlier messages in threads and with the first time a server
outside your reach receives the message.
> The problem is setting JUST the time zone.
> I don't want to set the date.
>
> Of course _that_ would work to set the date manually.
suggest to manually enter the changed date/time. You'd need to do this by
creating substrings of the original date header and write sub-functions
for the necessary date/time arithmetic, all by yourself. Because of the
high potential of misuse I will /not/ support you with this.
>> There have been versions of the nFilter news proxy program around, which
>> supported the modification of /outgoing/ messages as well as incoming.
>> There may be other tools available, doing the same.
>
> I am not sure what NFilter does, but I already have no problem modifying
> outgoing messages with STATIC complete headers such as the Date header.
>
> But I don't want to write a STATIC date header if I can avoid it.
> I just want to change the TIMEZONE that Dialog uses when communicating to
> the nntp news server.
>
> The question is whether that is possible or not.
wrote "versions". These modifications of course adjusted the date/time to
mirror the altered timezone. And no, I /won't/ give you any more detailed
pointer or download addresses.
Bernd
R Radev
Sep 2, 2018, 5:15:02 AM9/2/18
to
> 2. Make Dialog get the date & time & timezone before sending the message
> date /T (this gets the current system date)
> time /T (this gets the current system time)
> tzutil /g (this gets the current system TZ)
> (then calculate the new date based on the new desired time zone?)
This is a test of the suggestion above.
> date /T (this gets the current system date)
> time /T (this gets the current system time)
> tzutil /g (this gets the current system TZ)
> (then calculate the new date based on the new desired time zone?)
Hence this is a *manual* setting of the entire date line to the date of:
Sun, 2 Sep 2018 10:15:00 +0200
Please note I was trying to NOT set the entire date line statically.
But this is just an example and a test of the concept.
The concept would be for Dialog to create the Date line by running
the "date", "time" and "tzutil" commands above.
R Radev
Sep 2, 2018, 6:03:55 AM9/2/18
to
> So, of course, you'd have to adjust the /whole/ date entry,
Thanks for confirming I'd have to change the whole date header line.
I want to repeat that I have no intention to set the *entire* date line.
It's just crazy to do that.
The ONLY thing I want to change is the Time Zone.
I don't want to mess with the date line at all.
Just the time zone.
It seems we both agree that it's crazy to adjust the whole date entry.
It's just too dangerous in terms of potential screwups.
I have no intention to mess with the entire date line.
I just want to change the time zone.
That means the only viable option to change JUST the time zone is to figure
out how Dialog can call a script to set the timezone before the timezone is
sent to Dialog.
I noted you said that this timezone (and date) is provided to
OnBeforeSendingMessage so it might be too late to run the tzutil command in
OnBeforeSendingMessage.
I guess I could set a custom script in Dialog to simply call tzutil.exe.
Do you know, offhand, the syntax to call a Windows command from a script?
I'm looking for any example in
http://dialog.datalist.org/scripts/script_library.html
that runs a Windows command from inside of Dialog.
This seems to run a Windows command:
http://dialog.datalist.org/scripts/ScriptSoundOnEmail.html
I'll try to modify that script to run this command to set the time zone:
'c:\windows\system32\tzutil /s "Iran Standard Time"'
Simply setting the Windows system time zone is the SAFEST way.
I repeat: I don't want to touch the rest of the DATE header!
All I want is to run "tzutil" from inside of Dialog to set the Time Zone.
Bernd Rose
Sep 2, 2018, 7:42:08 AM9/2/18
to
On Sun, 2nd Sep 2018 10:00:49 +0000 (UTC), R Radev wrote:
> It seems we both agree that it's crazy to adjust the whole date entry.
> It's just too dangerous in terms of potential screwups.
No. My opinion is: "Don't mess with date/timezone, at all". Not because it
> It seems we both agree that it's crazy to adjust the whole date entry.
> It's just too dangerous in terms of potential screwups.
is hard to do or easy to screw up. Actually, carefully written it is quite
easy and safe.
IMHO, most people who "require" such a function are just trolls who try
to avoid certain kill filters. In my first answer I mentioned a possible
reason outside this scope. (If I wouldn't still give you the benefit of
doubt, we wouldn't discuss this matter, at all.)
But in any case, such obfuscation techniques usually don't protect in the
long run. Word choice, spelling, grammar, presence or absence of certain
typos help to classify postings, even if they seem to come from different
authors. These posts can then be analyzed by timing patterns: Core sleeping
time, work time, lunch, time for shopping, holidays, feast days and so on.
This helps to guess the timezone.
When simulating postings from a certain timezone, you'd also need to
simulate local language patterns. Changing to flexible timezones would
single out your postings, if you (maybe automatically) choose timezones
where usually nobody posts to the Internet (on a specific subject). So,
neither automatic nor manual changes prevent from creating identifiable
patterns. Most people would neglect their own timezone (at all or more
often than others). Again, a pattern by itself.
Intersecting (even small) unusual answering time lags with network outage
in certain regions of the Internet can narrow down your location further.
Some of these lags are probably induced on purpose. - Not because of you,
specifically, but to identify a whole bunch of users.
The quickest answer times with long typed texts done by you can be an age
indicator (typing speed). The list goes on and on.
> I noted you said that this timezone (and date) is provided to
> OnBeforeSendingMessage so it might be too late to run the tzutil command in
> OnBeforeSendingMessage.
to OnBeforeSendingMessage. If you replace the whole date line with sth.
else (no matter, how the new date has been deduced/created) the new date
and time will be the ones seen by any server and client, afterwards.
> I guess I could set a custom script in Dialog to simply call tzutil.exe.
> Do you know, offhand, the syntax to call a Windows command from a script?
Bernd
R Radev
Sep 2, 2018, 10:59:50 AM9/2/18
to
> No. My opinion is: "Don't mess with date/timezone, at all". Not because it
> is hard to do or easy to screw up. Actually, carefully written it is quite
> easy and safe.
WARNING: Skip to the last two sentences for the technical stuff.
> is hard to do or easy to screw up. Actually, carefully written it is quite
> easy and safe.
90% of this post is a philosophical answer to your innuendo & questions! :)
I agree. I can already set the time zone (as I showed you with examples).
I'm only trying to execute the tzutil command from within Dialog to do so.
I love Dialog.
I love the power of Dialog.
But I am not a programmer.
If I was a programmer, I'd be telling you how to set the time zone.
Not asking for advice on how to run the tzutil command from within Dialog.
> IMHO, most people who "require" such a function are just trolls who try
> to avoid certain kill filters. In my first answer I mentioned a possible
> reason outside this scope. (If I wouldn't still give you the benefit of
> doubt, we wouldn't discuss this matter, at all.)
If I wanted to troll, I would have done so long ago. I realize that anyone
who wishes his privacy does similar stuff as do trolls, but wasting time on
this troll issue is like asking me if I rob little old ladies, or if I'm
gay, or if I'm a communist.
The evidence is as flimsy on all three.
If I wanted to troll, just as if I had wanted to rob little old ladies, I
wouldn't need to nor care to set the time zone more elegantly from within
Dialog to do so.
> But in any case, such obfuscation techniques usually don't protect in the
> long run. Word choice, spelling, grammar, presence or absence of certain
> typos help to classify postings, even if they seem to come from different
> authors. These posts can then be analyzed by timing patterns: Core sleeping
> time, work time, lunch, time for shopping, holidays, feast days and so on.
> This helps to guess the timezone.
The evidence you have that I wish to troll is the same as the evidence you
have that I wish to rob little old ladies or that I'm a communist or that
I'm gay. There's no difference in the accusations with respect to evidence.
If I was trolling, or robbing little old ladies, or a communist, or gay, or
whatever you want to accuse me of on zero evidence, would my denial make
any different do you anyway.
You can either believe I care about privacy, or you don't believe it.
If you don't believe it, then stop responding to my queries.
And I'll stop responding to yours.
It's really that simple.
You either trust me at my word or you don't.
But let's not waste time on this issue if you don't trust my word.
I value your knowledge and you know that because I specifically called you
out as one of the top three Dialog-knowledgeable people in this ng.
But if we spend the entire conversation accusing each other of robbing
little old ladies on zero evidence, then let's stop wasting everyone's time
who has to wade through this dialog.
> When simulating postings from a certain timezone, you'd also need to
> simulate local language patterns. Changing to flexible timezones would
> single out your postings, if you (maybe automatically) choose timezones
> where usually nobody posts to the Internet (on a specific subject). So,
> neither automatic nor manual changes prevent from creating identifiable
> patterns. Most people would neglect their own timezone (at all or more
> often than others). Again, a pattern by itself.
It's not only philosophical. It's also logical.
I'm not sure you're aware that there are different kinds of privacy.
a. There is header privacy
b. There is body privacy
c. (there are plenty of others, e.g., newsgroup privacy)
Privacy is not always simple just like, I'm sure you're aware, browser
fingerprinting privacy is not always simple.
In terms of privacy, the HEADER is completely different than the BODY.
Personally, I'm not seeking BODY privacy.
I'm only seeking HEADER privacy.
Why, you would naturally ask?
My answer is the threat model.
Who is my antagonist?
Whom am I hiding from?
My answer is simple, and logical, and (I believe) perfectly reasonable.
But if you want to make this a conversation of the philosophy of the
various threat models, this thread is going to go off topic fast.
A. The threat model from robotic harvesters (like Google, Facebook, Amazon,
etc.) is completely different than the threat model from people (like you,
Michael Bauerle or Jernej Simoncic), which itself is completley different
than the thread model from a well-funded adversary such as a government
entity.
You know, of course, for example, that China has been harvesting Linked-In
information en masse, right?
How are they harvesting all that private information?
They're doing it with robots, of course,
They don't have individuals reading everyones' BODY of their messages and
then determining who those people are from the BODy of the message.
People are sufficiently sloppy that all a robot adversary needs is the
HEADER of the Usenet message.
For privacy against the robotic threat model, the BODY is probably
meaningless. Sure, a really well funded adversary will find that every
message has a "unibomber manifesto" fingerprint in slang, misspellings,
idiom, word choice, etc.
My threat model for this question of privacy is the robotic harvesters.
Those robotic harvesters are most likely HEADER harvesters.
We can wax philosophically whether that is a logical assessment of the
threat model, and you can rightly ask if I know of any current robotic
header harvesters, where, to go more deeply into this type of adversary, we
should change the subject line to something like:
OT: Philosophy 101. What is the robotic harvester adversary threat model?
> Intersecting (even small) unusual answering time lags with network outage
> in certain regions of the Internet can narrow down your location further.
> Some of these lags are probably induced on purpose. - Not because of you,
> specifically, but to identify a whole bunch of users.
The HEADER is one of the easiest ways though.
We could discuss the philosophy of header privacy in other terms but again,
we'd be engaging in a conversation of no ending if we ask what value the
specific header lines provide, in reality.
For my question, for example, does it matter what nntp server I use?
For my question, which is a technical one, does it matter what my name is?
Does my email address make any different to the answer to the question?
Why would my nntp posting host matter to a human for a technical question?
What technical significance to the question is my Time Zone?
Why would my Usenet agent matter when I said it clearly in the OP body?
I can easily argue, logically so, that the header provides almost no value
to the respondent outside of the subject line.
I can even more easily argue that the header provides a robotic adversary
with lots of value, interestingly, also outside of the subject line.
In fact, what's interesting, philosophically, is that the subject line
provides almost zero value to robotic adversaries, while the subject line
is ALL the value to the human respondent.
Hence
A. The SUBJECT line is the only meaningful header for technical questions.
B. The rest of the lines provide almost zero value to human respondents.
C. Yet, the rest of the lines are what robotic adversaries would harvest.
> The quickest answer times with long typed texts done by you can be an age
> indicator (typing speed). The list goes on and on.
Obviously I'm erudite, for example. Obviously I'm well educated.
Obviously I'm experienced at Usenet. Obviously I know you are well known
for Dialog expertise. (I can list the obvious for a long time.)
Do you think I can't purposefully misspell words if I wanted to?
But what value would that provide me when I ask a technical question?
Do you think this is some kind of Nigerian Bank Scam?
I have said clearly that I wish for privacy in my headers.
I have explained above (albeit only recently) that the adversary is a
robot.
Do I know of any of these robotic adversaries?
Nope.
Do I think they exist?
Yep.
Do you?
I don't know. Do you?
>> I noted you said that this timezone (and date) is provided to
>> OnBeforeSendingMessage so it might be too late to run the tzutil command in
>> OnBeforeSendingMessage.
>
> The whole raw ready-for-transmission message (headers and body) is handed
> to OnBeforeSendingMessage. If you replace the whole date line with sth.
> else (no matter, how the new date has been deduced/created) the new date
> and time will be the ones seen by any server and client, afterwards.
I need to repeat that I didn't want to mess with the entire date line.
I only wanted to change the time zone.
Since you've already explained that there is no way to change just the time
zone in the date line (and I'm not an idiot so I understood that), then I
give up on that approach.
The only other viable approach that I can think of is simply to set Dialog
to run a Windows command before I compose the article.
There is one other approach, but since I am not a programmer, it's out of
my league, which is to run a sequence of 'date', 'time', and 'tzutil'
commands and use the results from those commands to re-define the entire
date header - which I've said many times is not what I wish to do.
>> I guess I could set a custom script in Dialog to simply call tzutil.exe.
>> Do you know, offhand, the syntax to call a Windows command from a script?
>
> Reference the ShellExecute function from shell32.dll.
Dialog, as this is only the SECOND on-topic sentence in your post. :)
Searching, the n.s.r archives first
https://groups.google.com/forum/#!forum/news.software.readers
I find only one instance of those two keywords, from the year 2002
https://groups.google.com/d/msg/news.software.readers/JxcXUgy_jQw/0mjETtpHuxYJ
which even the venerable Marcus Monnig participated on in those days!
-------------------
http://dialog.datalist.org/scripts/ScriptShowHelpMaximized.html
http://dialog.datalist.org/scripts/ReadArticleInGoogleGroups2.html
-------------------
Program ShowHelp;
uses
Forms;
const
SW_NORMAL = 1;
SW_MAXIMIZE = 3;
SW_MINIMIZE = 6;
function ShellExecute(hwnd: LongWord; lpOperation: pchar;
lpFile: pchar; lpParams: pchar;
lpDir: pchar; nShow: integer): LongWord;
external 'ShellE...@shell32.dll stdcall';
Begin
ShellExecute(Application.MainForm.Handle, 'open',
pchar(ExtractFilePath(Application.ExeName) +
'dialog.chm'), '', '', SW_MAXIMIZE);
End.
-------------------
Is that the kind of use model for "tzutil.exe" you were kindly suggesting?
Bernd Rose
Sep 2, 2018, 12:53:25 PM9/2/18
to
On Sun, 2nd Sep 2018 14:56:44 +0000 (UTC), R Radev wrote:
[Spoofing timezone information]
the information to obfuscate trolling, then nevertheless trolls /will/ read
and profit from anything written here. Therefore, even /if/ you create a
scripted solution to your problem, I ask you to /not/ publish it here.
> But if we spend the entire conversation accusing each other of robbing
> little old ladies on zero evidence, then let's stop wasting everyone's time
> who has to wade through this dialog.
You got as much pointers from me as I intend to share in public. And I won't
answer such questions by mail, if this thought should occur you...
> People are sufficiently sloppy that all a robot adversary needs is the
> HEADER of the Usenet message.
You either underestimate current KI models of Usenet/Internet analysis and
information processing or have no /real/ need to protect your Net identity
to a degree, where altering the timezone information matters. You obviously
think otherwise. - So just follow one of the pointers already given.
>> The quickest answer times with long typed texts done by you can be an age
>> indicator (typing speed).
>
is no analysis of the body necessary. (Although counting the number of
citation lines or even better the number of characters in citation would
considerably refine the result...)
[Message processing information]
telling you reasons, why IMHO such an attempt usually is futile on the long
run. Which means: Better leave the subject be and use your time for other
things.
> The only other viable approach that I can think of is simply to set Dialog
> to run a Windows command before I compose the article.
>
> There is one other approach, but since I am not a programmer, it's out of
> my league, which is to run a sequence of 'date', 'time', and 'tzutil'
> commands and use the results from those commands to re-define the entire
> date header - which I've said many times is not what I wish to do.
You should read my posts more carefully, if you want to take utilizable
information from them. If you go the scripting path, certain programming
skill are of course necessary...
>>> I guess I could set a custom script in Dialog to simply call tzutil.exe.
>>> Do you know, offhand, the syntax to call a Windows command from a script?
>>
>> Reference the ShellExecute function from shell32.dll.
[...]
and timezone information. I just answered your explicit question on how
to execute such an external program from Dialog script.
Bernd
[Spoofing timezone information]
>> IMHO, most people who "require" such a function are just trolls who try
>> to avoid certain kill filters. In my first answer I mentioned a possible
>> reason outside this scope. (If I wouldn't still give you the benefit of
>> doubt, we wouldn't discuss this matter, at all.)
>
> How do I defend myself from such an accusation?
You don't need to. Everything written here is public. So if /you/ don't want
>> to avoid certain kill filters. In my first answer I mentioned a possible
>> reason outside this scope. (If I wouldn't still give you the benefit of
>> doubt, we wouldn't discuss this matter, at all.)
>
> How do I defend myself from such an accusation?
the information to obfuscate trolling, then nevertheless trolls /will/ read
and profit from anything written here. Therefore, even /if/ you create a
scripted solution to your problem, I ask you to /not/ publish it here.
> But if we spend the entire conversation accusing each other of robbing
> little old ladies on zero evidence, then let's stop wasting everyone's time
> who has to wade through this dialog.
answer such questions by mail, if this thought should occur you...
> People are sufficiently sloppy that all a robot adversary needs is the
> HEADER of the Usenet message.
information processing or have no /real/ need to protect your Net identity
to a degree, where altering the timezone information matters. You obviously
think otherwise. - So just follow one of the pointers already given.
>> The quickest answer times with long typed texts done by you can be an age
>> indicator (typing speed).
>
> Again, I make zero attempt to obfuscate the body of the message.
As I said: You underestimate algorithms. For the typing speed statistics
is no analysis of the body necessary. (Although counting the number of
citation lines or even better the number of characters in citation would
considerably refine the result...)
[Message processing information]
> This is really the FIRST on-topic sentence in your entire post! :)
I consider it on-topic to your question (how to change timezone information)
telling you reasons, why IMHO such an attempt usually is futile on the long
run. Which means: Better leave the subject be and use your time for other
things.
> The only other viable approach that I can think of is simply to set Dialog
> to run a Windows command before I compose the article.
>
> There is one other approach, but since I am not a programmer, it's out of
> my league, which is to run a sequence of 'date', 'time', and 'tzutil'
> commands and use the results from those commands to re-define the entire
> date header - which I've said many times is not what I wish to do.
information from them. If you go the scripting path, certain programming
skill are of course necessary...
>>> I guess I could set a custom script in Dialog to simply call tzutil.exe.
>>> Do you know, offhand, the syntax to call a Windows command from a script?
>>
>> Reference the ShellExecute function from shell32.dll.
> Is that the kind of use model for "tzutil.exe" you were kindly suggesting?
I /didn't/ suggest calling some external program to fetch the date/time
and timezone information. I just answered your explicit question on how
to execute such an external program from Dialog script.
Bernd
R Radev
Sep 2, 2018, 3:01:28 PM9/2/18
to
> You don't need to. Everything written here is public. So if /you/ don't want
> the information to obfuscate trolling, then nevertheless trolls /will/ read
> and profit from anything written here. Therefore, even /if/ you create a
> scripted solution to your problem, I ask you to /not/ publish it here.
IMHO, trolls don't need Dialog to troll.
> the information to obfuscate trolling, then nevertheless trolls /will/ read
> and profit from anything written here. Therefore, even /if/ you create a
> scripted solution to your problem, I ask you to /not/ publish it here.
Trolls can troll with any newsreader.
Asking me not to publish a script that calls a Windows command is like you
telling me not to publish the bank hours because someone might use that
bank hour information to rob a bank.
It's just not a realistic fear. (IMHO).
It's hysteria (IMHO).
It's like declaring martial law simply becuase some terrorist planted a
bomb. It's hysteria like the McCarthy Era hysteria on communism. (IMHO).
Heck, trolls can write a telnet script, as you're well aware, to troll.
Then they can change everything.
Everyone knows how to do this since it's the most trivial script around.
telnet reader80.eternal-september.org 80
200 news.eternal-september.org InterNetNews NNRP server INN 2.7.0 (20180114 snapshot) ready (posting ok)
help
post
340 Ok, recommended message-ID <tr43eq$a3b#6...@anonymous.dont-email.me>
GROUP alt.test
222 2551 3 5236 alt.test
POST
340 Send Article to be Posted
From: tr...@troll.org
Subject: You don't need Dialog to troll
Date: Sun, 2 Sep 2018 18:53:24 +0200
Message-ID: <tr43eq$a3b#6...@anonymous.dont-email.me>
Newsgroups: alt.test
Everyone knows how to use Telnet to test nntp servers.
It's published all over the net for heaven's sake.
.
next
body
quit
Anyway, I'm sick of this troll philosophical discussion.
People how have no technical knowledge always love to claim everyone is a
troll. You've seen it happen. It happened in this thread with the "I" guy.
He has zero knowledge of Dialog. None. And yet he can talk about trolls
because even my baby sister can talk about trolls.
If you think I'm going to troll, then you don't believe in my privacy.
That's fine.
But then we're both just wasting everyone's time.
And Usenet is not supposed to be about wasting everyone's time.
It's supposed to be about people helping people around the world.
And then publishing the results so that others stand on our shoulders.
But if you don't want me to publish a successful Dialog script, I won't.
But think about the logic of that request.
I am not a programmer. So for me it is work to modify a script.
But for a programmer like you - it would be trivial.
You know that. I know that. Everyone knows that.
It's like you telling me not to publish the bank hours because someone
might use that information to rob a bank.
>> But if we spend the entire conversation accusing each other of robbing
>> little old ladies on zero evidence, then let's stop wasting everyone's time
>> who has to wade through this dialog.
>
> You got as much pointers from me as I intend to share in public. And I won't
> answer such questions by mail, if this thought should occur you...
You just shut the door.
I don't wish to be ungracious so I sincerely THANK YOU for your advice.
Since this is my last post to you in this thread, allow me to explain how I
will proceed and why.
1. First, the original intent was NOT to change the system time zone.
2. That can be done, but then I have to munge the entire DATE header.
3. That can be done, but it could screw up the nntp server mechanisms.
4. So I really prefer NOT to mess with the entire DATE header line.
5. The next best thing is to simply change the system time zone.
6. I never wanted to do that, but all it takes is a tzutil command.
7. The trick is to get Dialog to run the tzutil command.
8. You pointed me to the best way to do that - which I appreciate!
9. Since I'm not a programmer, I must modify an existing Dialog script.
10. I will do that since I can certainly run trial-and-error tests.
11. At your request, I won't post any successful results to n.s.r.
12. However, I think you are implementing martial law out of hysteria.
>> People are sufficiently sloppy that all a robot adversary needs is the
>> HEADER of the Usenet message.
>
> You either underestimate current KI models of Usenet/Internet analysis and
> information processing or have no /real/ need to protect your Net identity
> to a degree, where altering the timezone information matters. You obviously
> think otherwise. - So just follow one of the pointers already given.
you have no more information to provide.
For you to intimate that nobody has a "real need for privacy" shows a lack
of concern for peoples' feelings. That's fine. You don't have to care about
how I feel about my privacy.
With the well-funded adversaries literally tapping the fiber-optic feeds,
anyone hiding from a state-sponsored adversary isn't going to be posting on
Usenet using a free public NNTP server for heaven's sake. They're just not.
These well funded adversaries spend BILLIONS of dollars a year harvesting
everything on the Internet for heaven's sake. No private person can defend
themselves against that threat model.
I'm just a regular person. Like you are (I assume).
I never said or intimated I was an expert at "security" or "privacy".
I'm just a person. Like any other person.
I value my privacy. Like any other person.
If my threat model were a well-funded adversary, I'd be dead long ago.
My adversary are privacy robbing robots.
You may or may not have that same threat model.
I don't begrudge you your particular threat model, whatever it may be.
Since I'm not a privacy expert, I don't even know, offhand, what "KI"
stands for. Googling, the term "KI" doesn't seem to exist in this context.
Perhaps you meant "AI", which makes sense in this context?
>
>>> The quickest answer times with long typed texts done by you can be an age
>>> indicator (typing speed).
>>
>> Again, I make zero attempt to obfuscate the body of the message.
>
> As I said: You underestimate algorithms. For the typing speed statistics
> is no analysis of the body necessary. (Although counting the number of
> citation lines or even better the number of characters in citation would
> considerably refine the result...)
and HEADER profiling.
It's almost as if I told you I wanted to wear long clothes to protect
against the sun and not necessarily against thorns while hiking, where all
you can think of is telling me that thorns exist in the forests.
I KNOW they can fingerprint based on the BODY.
You think I don't know that?
I said I'm not worried about that threat model.
If I was worried about that threat model, I'd at least TRY to change the
BODY fingerprint.
What you're saying is that I can't easily change the body fingerprint.
I am telling you that this is a red herring argument because I already said
my threat model has NOTHING to do with body fingerprinting.
It's like you telling me to wear long sleeves at night when hiking even
though I told you I only wear long sleeves to protect against the sun.
You have to take into context the threat model.
In my threat model, the BODY is not of any concern to me.
(If the body was of concern, I'd bother to change things - but I don't).
My threat is clearly stated to be privacy from HEADER harvesting robots.
I appreciate that you tell me that body privacy harvesting is
sophisticated. I don't doubt that this is the case. But it's too much work
to bother with body obfuscation when the BODY is where the technical
question lies.
Obfuscating the body is like cutting off the fingertips of your hands so
that nobody can fingerprint you. (IMHO).
To be clear, I'm not doubting that BODY robot AI-based harvesters exist.
I'm just saying that my threat model doesn't care about BODY robots.
My threat model is about HEADER robots.
They're two completely different things, IMHO.
This is a philosophical discussion though, which has NOTHING whatsoever to
do with the technical question. As such, it's a waste of not only your time
and my time but anyone's time who read this long-winded philosophical
discussion.
> [Message processing information]
>> This is really the FIRST on-topic sentence in your entire post! :)
>
> I consider it on-topic to your question (how to change timezone information)
> telling you reasons, why IMHO such an attempt usually is futile on the long
> run. Which means: Better leave the subject be and use your time for other
> things.
We are allowed to disagree about the weight of robotic harvesting concerns.
My argument is that header robotic harvesting is trivial.
My argument is that body robotic harvesting is certainly possible.
My argument is that protection from header robotic harvesting is feasible.
My argument is that protection from body robotic harvesting is difficult.
Why would anyone disagree with those logical valid points of view?
The ONLY way you can logically disagree is if you assume that protection
from header robotic harvesting is not feasible when the threat is the likes
of Google and Amazon and Facebook and NOT a well-funded adversary such as
the NSA is.
If the adversary is the NSA - you're already dead.
They spend BILLIONS every year on this stuff.
All I'm doing is asking for header robotic harvesting privacy.
Why would anyone begrudge header privacy?
> You should read my posts more carefully, if you want to take utilizable
> information from them. If you go the scripting path, certain programming
> skill are of course necessary...
But you don't have to be a medical doctor to have kids who get sick.
It's nice to be a diplomat when you go on a world-wide vacation.
But you don't have to be a diplomat to go on a world-wide vacation.
It's nice to be a professional weatherman when you go on a camping trip.
But you don't have to be a professional weatherman to go on a camping trip.
It's nice to be a programmer when you modify existing Dialog scripts.
But you don't have to be a programmer to modify existing Dialog scripts.
Not everyone likes programming.
I hate it, for example.
I do it when I must - but otherwise - I leave it to the programmers.
But I can modify a script by trial and error - which is what I'll do.
> I /didn't/ suggest calling some external program to fetch the date/time
> and timezone information. I just answered your explicit question on how
> to execute such an external program from Dialog script.
The question is how to change JUST the timezone in Dialog.
The answer is you can't.
Then the question morphs to how to change JUST the entire DATE line.
The answer is that this is easy - but it involves programming to obtain the
current date and the current time and then to forumulate a STATIC date line
based on that current date and current time (and then to calculate the time
in the given time zone).
Since that's more programming than I wish to perform, the simpler option is
to dynamically change the SYSTEM time zone using a call from Dialog to
tzutil.
The example file I'll modify is this one - but even virgin - this file
failed to work - so it has some (as yet unknown) issues in Dialog.
http://dialog.datalist.org/scripts/ScriptShowHelpMaximized.html
No need to respond as I will not respond further in this thread but I will
read all responses for the next few days at least, just in case others know
how to call a Windows command from inside of Dialog.
Thank you for your advice, concern, and helpful intent.
Frank Slootweg
Sep 2, 2018, 3:12:59 PM9/2/18
to
R Radev <rradev...@blizoo.bg> wrote:
> Bernd Rose <b.rose...@arcor.de> - 2018/09/02
>
> > No. My opinion is: "Don't mess with date/timezone, at all". Not because it
> > is hard to do or easy to screw up. Actually, carefully written it is quite
> > easy and safe.
>
> WARNING: Skip to the last two sentences for the technical stuff.
> 90% of this post is a philosophical answer to your innuendo & questions! :)
Indeed! It's inexcusable that Bernd has the audacity to - even
> Bernd Rose <b.rose...@arcor.de> - 2018/09/02
>
> > No. My opinion is: "Don't mess with date/timezone, at all". Not because it
> > is hard to do or easy to screw up. Actually, carefully written it is quite
> > easy and safe.
>
> WARNING: Skip to the last two sentences for the technical stuff.
> 90% of this post is a philosophical answer to your innuendo & questions! :)
indirectly - talk about trolls etc. in a response to one of *your*
posts!
After all, you are a well respected netizen who only *occasionaly* uses
a different nym, such as
Paul M Cook
VPN User
Joe Clock
Marob Katon
Chris Rangoon
Henry Jones
Aardvarks
Horace Algier
Danny D.
Algeria Horan
Stijn De Jong
Martim Ribeiro
Jonas Schneider
Tomos Davies
Roy Tremblay
Lionel Muller
harry newton
Joe Scotch
Harold Newton
Ragnusen Ultred
Ragnusen Ultred
Ragnusen Ultred
Uhtred Ragnussen
Bob J Jones
Amethyst
Horst H Schneider
Arlen Holder
Louis Fabron
After all, don't we all use 30-odd different nyms!? Does that make us
'trolls'!?
Shame on you, Bernd!
Frank Slootweg
Sep 2, 2018, 4:12:15 PM9/2/18
to
R Radev <rradev...@blizoo.bg> wrote:
[Other usual rants deleted.]
[Broken records deleted.]
> My argument is that header robotic harvesting is trivial.
True.
> My argument is that protection from header robotic harvesting is feasible.
Possibly, but - as you've been told umpteen times - *not* the way
you're (not) doing it.
> Why would anyone disagree with those logical valid points of view?
Because they're neither logical, nor valid.
> The ONLY way you can logically disagree is if you assume that protection
> from header robotic harvesting is not feasible when the threat is the likes
> of Google and Amazon and Facebook and NOT a well-funded adversary such as
> the NSA is.
In your dreams! Anyone with modest programming skills - and who can
actually be bothered to prove the blatantly obvious - can be your
'threat'/'adversary'.
You've been told this umpteen times, *with* clue-by-fours as to *why*
it is trivial to break your (non-)'protection'. But you didn't listen
and apparently still haven't learned anything. Not that anybody is
surprised, but still.
[Other usual rants deleted.]
[Broken records deleted.]
> My argument is that header robotic harvesting is trivial.
> My argument is that protection from header robotic harvesting is feasible.
you're (not) doing it.
> Why would anyone disagree with those logical valid points of view?
> The ONLY way you can logically disagree is if you assume that protection
> from header robotic harvesting is not feasible when the threat is the likes
> of Google and Amazon and Facebook and NOT a well-funded adversary such as
> the NSA is.
actually be bothered to prove the blatantly obvious - can be your
'threat'/'adversary'.
You've been told this umpteen times, *with* clue-by-fours as to *why*
it is trivial to break your (non-)'protection'. But you didn't listen
and apparently still haven't learned anything. Not that anybody is
surprised, but still.
Bernd Rose
Sep 2, 2018, 4:46:37 PM9/2/18
to
On 2nd Sep 2018 19:12:57 GMT, Frank Slootweg wrote:
> Indeed! It's inexcusable that Bernd has the audacity to - even
> indirectly - talk about trolls etc. in a response to one of *your*
> posts!
>
> After all, you are a well respected netizen who only *occasionaly* uses
> a different nym, such as
<Snipped nym list>
> Indeed! It's inexcusable that Bernd has the audacity to - even
> indirectly - talk about trolls etc. in a response to one of *your*
> posts!
>
> After all, you are a well respected netizen who only *occasionaly* uses
> a different nym, such as
> After all, don't we all use 30-odd different nyms!? Does that make us
> 'trolls'!?
>
> Shame on you, Bernd!
You are perfectly right! I'm off meditating - trying to better myself. ;-)
> 'trolls'!?
>
> Shame on you, Bernd!
Bernd
0 new messages