Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Herb L]

A friend once commented, "If it's free, -=YOU=- are the product."  It
should be updated to, "If it's free, -=YOU & EVERYONE YOU INTERACT WITH=-
are the product."

/herb

On Fri, Sep 8, 2023 at 10:25 AM John Gilmore  wrote:

> It is totally possible to turn off the spyware in MailChimp.  You just
> need to buy an actual commercial account rather than using their
> "free" service.  To save $13 or $20 per month, you are instead selling
> the privacy of every recipient of your emails.  See:
>
>   https://mailchimp.com/help/enable-and-view-click-tracking/
>
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
>
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
>
>   https://mailchimp.com/help/about-open-tracking/
>
> John
>

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[John Gilmore]

Ryan Hamel  wrote:
> For you to say, "my privacy has been sold", is simply not true.

I agree with you somewhat about tracking links.  They only spy on a
person when that person tries to follow them.  I do find it much less
useful to read mailing lists that include references to external
resources that I decline to access, because I don't want to follow
bugged links.

But the "web bugs" that I mentioned as a second default-on Mailchimp
tracking technology ARE specifically designed to be triggered any time a
recipient reads a message in an HTML-based web browser.

Back when postal mail was the default, senders had no idea whether the
recipient opened, read, or forwarded a letter, versus tossing it into
the fireplace as kindling.  Society carried forward that expectation
when postal mail was gradually replaced by electronic mail.  Ordinary
email senders don't know if you have read their message (unless they get
social clues from your subsequent actions, just as with paper mail).
Tracking was never part of the Internet email protocols; it was glued-on
by abusing HTML email features and making unique URLs sent to each
recipient, whose corresponding web server logs when they are accessed.

These email tracking technologies deliberately violate the social
expectation that reading a letter is a private act.  They produce
detailed records of the private, in-home or at-work activities of every
recipient.  They do all this covertly; you will not find a MailChimp
mailing list message plainly telling you, "If you want to safeguard your
privacy as an email reader, do not open these messages, because we have
filled them with spyware."  That would produce too many unsubscribes and
too much outrage.  Instead, a recipient has to be technically
sophisticated to even notice that it's happening.  (Many bulk email
senders also don't know that their emails have spyware quietly inserted
into them as they are distributed.  I have engaged on this topic with
many nonprofit CEOs and marketing executives, who really had no idea.)

Those detailed email-reading and link-clicking records are not just
accessible to the sender.  There's an agency problem.  They are kept and
stored and sold by the intermediary (MailChimp), both individually and
in bulk.  They are accessible to any government that wants to ask,
without a warrant, without probable cause, in bulk or individually,
since they are "third-party" records about you, like your banking
records or license-plate-reader records.  They are accessible to private
investigators via data brokers.  They are accessible to any business
that offers a sufficiently attractive deal to MailChimp -- places like
Google or Facebook who make billions of dollars a year from tracking
people to manipulate them with advertising.

And wouldn't you like to know just which emails your competitors'
engineers and executives are reading, and when, and where, and how many
times, and whether they forwarded the messages?  (I've often wanted the
Google Detective Agency, that I could merely pay to tell me what my wife
or my competitor or that rude guy who insulted me is searching for on
Google, what web pages they are looking at, what emails they are reading
or sending, and exactly where they are navigating in their car or on
their bike or on transit.  Google has all this information; why won't
they sell it to me?  They definitely sell it to the government, so why
not to me?  It's amazing to me that people treat Google like Santa Claus
giving them free gifts, when it's really like an NSA.gov that is
unencumbered by laws or oversight.  MailChimp isn't as bad as Google.
Its scope is smaller, but its defaults are deliberately bad, and it's
created quite a honeypot of trillions of records about billions of
people.  The point is that besides being a gross violation of the
personal privacy of the home and office, this data also has real
commercial value.

I suggest that as a technically aware organization, NANOG.org should not
be creating detailed spy dossiers on its members who read emails, and
then letting its subcontractor MailChimp sell or trade that info out
into the world.

John Gilmore

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Martin Hannigan]

What network does Nanog-news operate?

Marketing email doesn’t  belong on an operational list.  Even if its NANOG
marketing itself.  (Ack Kentik non involvement).

Warm regards,

-M<


On Fri, Sep 8, 2023 at 20:52 Ryan Hamel  wrote:

> Randy,
>
> You're right, the problem is not technical. It's a choice to click the
> links or not. NANOG does not have to sanitize links for you. Those emails
> do not have to be read, and no one is stopping you from filtering them out.
> For you to say, "my privacy has been sold", is simply not true.
>
> Ryan
>
> --
> *From:* NANOG  on behalf of
> Randy Bush 
> *Sent:* Friday, September 8, 2023 5:25 PM
> *To:* John Gilmore 
> *Cc:* nanog@nanog.org 
> *Subject:* Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming
> ISOC Course + More
>
> Caution: This is an external email and may be malicious. Please take care
> when clicking links or opening attachments.
>
>
> > It is totally possible to turn off the spyware in MailChimp.  You just
> > need to buy an actual commercial account rather than using their
> > "free" service.  To save $13 or $20 per month, you are instead selling
> > the privacy of every recipient of your emails.  See:
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fenable-and-view-click-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Pw6uDgHDzT%2BavOz1jYAbG4VzTyP0en0oiuBq0PmTtVI%3D=0
> 
> >
> >   "Check the Track clicks box to enable click tracking, or uncheck the
> >   box to disable click tracking.  ...  Mailchimp will continue to
> >   redirect URLs for users with free account plans to protect against
> >   malicious links.  ...  When a paid user turns off click tracking,
> >   Mailchimp will continue to redirect their URLs until certain account
> >   activity thresholds are met."
> >
> > Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> > MailChimp inserts by default, too:
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fabout-open-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iqkTsuhDFD3poxVltrN4x%2FWY6eXpbIivWxf4VAWcXKA%3D=0
> 
>
>
> as usual, the problem is not technical.  there is no need for mailchump
> at all.
>
> nanog management has made a very intentional decision to sell my
> privacy.  nanog has come a long way, not all of it  good.
>
> randy
>

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Ryan Hamel]

Randy,

You're right, the problem is not technical. It's a choice to click the links or 
not. NANOG does not have to sanitize links for you. Those emails do not have to 
be read, and no one is stopping you from filtering them out. For you to say, 
"my privacy has been sold", is simply not true.

Ryan


From: NANOG  on behalf of Randy Bush 

Sent: Friday, September 8, 2023 5:25 PM
To: John Gilmore 
Cc: nanog@nanog.org 
Subject: Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC 
Course + More

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


> It is totally possible to turn off the spyware in MailChimp.  You just
> need to buy an actual commercial account rather than using their
> "free" service.  To save $13 or $20 per month, you are instead selling
> the privacy of every recipient of your emails.  See:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fenable-and-view-click-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Pw6uDgHDzT%2BavOz1jYAbG4VzTyP0en0oiuBq0PmTtVI%3D=0
>
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
>
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fabout-open-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iqkTsuhDFD3poxVltrN4x%2FWY6eXpbIivWxf4VAWcXKA%3D=0

as usual, the problem is not technical.  there is no need for mailchump
at all.

nanog management has made a very intentional decision to sell my
privacy.  nanog has come a long way, not all of it  good.

randy

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Randy Bush]

> It is totally possible to turn off the spyware in MailChimp.  You just
> need to buy an actual commercial account rather than using their
> "free" service.  To save $13 or $20 per month, you are instead selling
> the privacy of every recipient of your emails.  See:
> 
>   https://mailchimp.com/help/enable-and-view-click-tracking/
> 
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
> 
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
> 
>   https://mailchimp.com/help/about-open-tracking/

as usual, the problem is not technical.  there is no need for mailchump
at all.

nanog management has made a very intentional decision to sell my
privacy.  nanog has come a long way, not all of it  good.

randy

Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Sylvain Baya]

Dear NANOG-ers,
Hope this email finds you in good health!

Le jeudi 7 septembre 2023, Anne Mitchell  a écrit :

>
> > [...]
> >
> > can we please get URLs without all the invasive tracking?
>
> list-manage.com is Mailchimp;


>
>
Hi Anne,
Thanks for your email.

Sure! but the question could be:
Isn't why the mailinglist was chosen? :-/



> not sure it's possible to turn off tracking when using an ESP like that.
> :-(
>
>
It should be simply a matter of sharing an URI with
 a title and small intro...

The content of the email could be collected via a
FLOSS RSS [1] feed agregator and sent to the
mailinglist, in a regular basis.
__
[1]: 

No need to "over" track list-ers.
...that kind of MitM [2] isn't desirable/necessary!
__
[2]: 


Shalom,
--sb.



> Anne
>
> [...]



-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 09 Sep, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  927731
Prefixes after maximum aggregation (per Origin AS):  352669
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  452710
Total ASes present in the Internet Routing Table: 74776
Prefixes per ASN: 12.41
Origin-only ASes present in the Internet Routing Table:   64229
Origin ASes announcing only one prefix:   26357
Transit ASes present in the Internet Routing Table:   10547
Transit-only ASes present in the Internet Routing Table:454
Average AS path length visible in the Internet Routing Table:   4.2
Max AS path length visible:  70
Max AS path prepend of ASN (263725)  64
Prefixes from unregistered ASNs in the Routing Table:  1053
Number of instances of unregistered ASNs:  1055
Number of 32-bit ASNs allocated by the RIRs:  42576
Number of 32-bit ASNs visible in the Routing Table:   35055
Prefixes from 32-bit ASNs in the Routing Table:  175008
Number of bogon 32-bit ASNs visible in the Routing Table:54
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:601
Number of addresses announced to Internet:   3056133888
Equivalent to 182 /8s, 40 /16s and 231 /24s
Percentage of available address space announced:   82.5
Percentage of allocated address space announced:   82.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  308927

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   246243
Total APNIC prefixes after maximum aggregation:   70661
APNIC Deaggregation factor:3.48
Prefixes being announced from the APNIC address blocks:  239918
Unique aggregates announced from the APNIC address blocks:98702
APNIC Region origin ASes present in the Internet Routing Table:   13628
APNIC Prefixes per ASN:   17.60
APNIC Region origin ASes announcing only one prefix:   4057
APNIC Region transit ASes present in the Internet Routing Table:   1797
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 24
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8946
Number of APNIC addresses announced to Internet:  772854656
Equivalent to 46 /8s, 16 /16s and 211 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:271947
Total ARIN prefixes after maximum aggregation:   123794
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   274838
Unique aggregates announced from the ARIN address blocks:131523
ARIN Region origin ASes present in the Internet Routing Table:19086
ARIN Prefixes per ASN:

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[John Gilmore]

It is totally possible to turn off the spyware in MailChimp.  You just
need to buy an actual commercial account rather than using their
"free" service.  To save $13 or $20 per month, you are instead selling
the privacy of every recipient of your emails.  See:

  https://mailchimp.com/help/enable-and-view-click-tracking/

  "Check the Track clicks box to enable click tracking, or uncheck the
  box to disable click tracking.  ...  Mailchimp will continue to
  redirect URLs for users with free account plans to protect against
  malicious links.  ...  When a paid user turns off click tracking,
  Mailchimp will continue to redirect their URLs until certain account
  activity thresholds are met."

Don't forget to turn off the spyware 1x1 pixel "web bugs" that
MailChimp inserts by default, too:

  https://mailchimp.com/help/about-open-tracking/

John

Spoofer Report for NANOG for Aug 2023

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Aug 2023:
ASNName   Fixed-By
53274  3DB-WIRELESS   2023-08-15
10745  ARIN-ASH-CHA   2023-08-18
4005172023-08-18

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Aug 2023:
ASNName   First-Spoofed Last-Spoofed
3356   LEVEL32016-03-06   2023-08-17
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2023-08-25
20412  CLARITY-TELECOM   2016-09-30   2023-08-31
25787  ROWE-NETWORKS 2016-10-21   2023-08-31
11427  TWC-11427-TEXAS   2016-10-21   2023-08-29
10796  TWC-10796-MIDWEST 2016-10-24   2023-08-30
271BCNET 2016-10-24   2023-08-26
25660  CTC   2017-01-11   2023-08-21
852ASN8522017-04-16   2023-08-01
22883  CONDENAST 2019-05-29   2023-08-22
199524 GCORE 2020-09-02   2023-08-23
26231  SFIA-ASN  2021-10-27   2023-08-07
469972021-12-22   2023-08-31
394414 E2WS  2022-05-08   2023-08-30
400517   2022-10-03   2023-08-25
12183  TALKIE-COMMUNICATIONS 2022-12-10   2023-08-30
41378  KirinoNET 2023-03-23   2023-08-25
3701   NERONET   2023-04-18   2023-08-30
400282   2023-04-27   2023-08-25
13693  NTS-ONLINE2023-05-05   2023-08-26
46690  SNET-FCC  2023-05-20   2023-08-27
36687  WILINE2023-08-02   2023-08-21
209114 LUIZ-AMARAL   2023-08-08   2023-08-08

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

Re: Lossy cogent p2p experiences?

[Fred Baker]

It was intended to detect congestion. The obvious response was in some way to 
pace the sender(s) so that it was alleviated.

Sent using a machine that autocorrects in interesting ways...

> On Sep 7, 2023, at 11:19 PM, Mark Tinka  wrote:
> 
> 
> 
>> On 9/7/23 09:51, Saku Ytti wrote:
>> 
>> Perhaps if congestion control used latency or FEC instead of loss, we
>> could tolerate reordering while not underperforming under loss, but
>> I'm sure in decades following that decision we'd learn new ways how we
>> don't understand any of this.
> 
> Isn't this partly what ECN was meant for? It's so old I barely remember what 
> it was meant to solve :-).
> 
> Mark.

Re: Lossy cogent p2p experiences?

[Saku Ytti]

On Fri, 8 Sept 2023 at 09:17, Mark Tinka  wrote:

> > Unfortunately that is not strict round-robin load balancing.
>
> Oh? What is it then, if it's not spraying successive packets across
> member links?

I believe the suggestion is that round-robin out-performs random
spray. Random spray is what the HPC world is asking, not round-robin.
Now I've not operated such network where per-packet is useful, so I'm
not sure why you'd want round-robin over random spray, but I can see
easily why you'd want either a) random traffic or b) random spray, if
neither are true, if you have strict round-robin and you have
non-random traffic, say every other packet is big data delivery, every
other packet is small ACK, you can easily synchronise one link to 100%
util, and and another near 0%, if you do true round-robin, but not of
you do random spray.
I don't see downside random spray would have over round-robin, but I
wouldn't be shocked if there is one.


I see this thread is mostly starting to loop around two debates

1) Reordering is not a problem
   - if you control the application, you can make it 0 problem
   - if you use TCP shipping in Androids, iOS, macOS, Windows, Linux,
BSD reordering is in practice as bad as packet loss.
   - people who know this in the list, don't know it because they read
it, they know it, because they got caught pants down and learned it,
because they had reordering and tcp performance was destroyed, even at
very low reorder rates
   - we could design TCP congestion control that is very tolerant to
reordering, but I cannot say if it would be overall win or loss

2) Reordering won't happen in per-packet, if there is no congestion
and latencies are equal
   - the receiving distributed router (~all of them) do not have
global synchronisation, they do not make any guarantees that ingress
order is honored for egress, when ingress is >1 interface, the amount
of reordering this alone causes will destroy customer expectation of
TCP performance
   - we could quite easily guarantee order as long as interfaces are
in same hardware complex, but it would be very difficult to guarantee
between hardware complexes


-- 
  ++ytti

Re: Lossy cogent p2p experiences?

[Mark Tinka]

On 9/7/23 09:51, Saku Ytti wrote:


Perhaps if congestion control used latency or FEC instead of loss, we
could tolerate reordering while not underperforming under loss, but
I'm sure in decades following that decision we'd learn new ways how we
don't understand any of this.


Isn't this partly what ECN was meant for? It's so old I barely remember 
what it was meant to solve :-).


Mark.

Re: Lossy cogent p2p experiences?

[Mark Tinka]

On 9/7/23 09:31, Benny Lyne Amorsen wrote:


Unfortunately that is not strict round-robin load balancing.


Oh? What is it then, if it's not spraying successive packets across 
member links?




  I do not
know about any equipment that offers actual round-robin
load-balancing.


Cisco had both per-destination and per-packet. Is that not it in the 
networking world?




Juniper's solution will cause way too much packet reordering for TCP to
handle. I am arguing that strict round-robin load balancing will
function better than hash-based in a lot of real-world
scenarios.


Ummh, no, it won't.

If it did, it would have been widespread. But it's not.

Mark.