Pat, the Editor

For your convenience in reading: Subject lines are printed in RED and Moderator replies when issued appear in BROWN.
Previous Issue (just one)
TD Extra News
Add this Digest to your personal   or  

 

TELECOM Digest     Mon, 13 Jun 2005 14:45:00 EDT    Volume 24 : Issue 265

Inside This Issue:                             Editor: Patrick A. Townson

    Http Request Smuggling (Lisa Minter)
    Snocap Opens to Independent Artists (Lisa Minter)
    Nokia Cooperates With Apple on New Web Browser (Lisa Minter)
    Hong Kong Plans to Enact New Anti-Spam Law (Lisa Minter)
    Qualcomm Announces Winners of BREW 2005 Developer Awards (Monty Solomon)
    Cable Outlets Decline to Air Abstinence ad (Monty Solomon)
    T-Mobile: 450,000 People Paid to Use WiFi (Monty Solomon)
    T-Mobile Focuses on WiFi (Telecom DailyLead from USTA)
    Re: Cell Phone Rental in Europe (John Stahl)
    Re: Companies Subvert Search Results to Squelch Criticism (Steve Sobol)
    Re: 'Phone Tapping' Modem Traffic ? (John McHarry)
    Re: Bellsouth Caller ID (Joseph)
    Re: Schools Prohibit Personal E-mail Sites (Lisa Hancock)
    Re: Microwave Fading 6 Gig (Harry Hydro)

Telecom and VOIP (Voice over Internet Protocol) Digest for the
Internet.  All contents here are copyrighted by Patrick Townson and
the individual writers/correspondents. Articles may be used in other
journals or newsgroups, provided the writer's name and the Digest are
included in the fair use quote.  By using -any name or email address-
included herein for -any- reason other than responding to an article
herein, you agree to pay a hundred dollars to the recipients of the
email.

               ===========================

Addresses herein are not to be added to any mailing list, nor to be
sold or given away without explicit written consent.  Chain letters,
viruses, porn, spam, and miscellaneous junk are definitely unwelcome.

We must fight spam for the same reason we fight crime: not because we
are naive enough to believe that we will ever stamp it out, but because
we do not want the kind of world that results when no one stands
against crime.   Geoffrey Welsh

               ===========================

See the bottom of this issue for subscription and archive details
and the name of our lawyer; other stuff of interest.  

----------------------------------------------------------------------

From: Lisa Minter <lisa_minter2001@yahoo.com>
Subject: Http Request Smuggling
Date: Sun, 12 Jun 2005 21:10:39 -0500

Some comments of interest from SlashDot over the weekend you might 
find interesting to read:

            Posted by CmdrTaco on Sunday June 12, @11:28AM
            from the this-could-get-fun dept.
            cyphersteve writes "Multiple vendors are vulnerable to a new
class of attack named 'HTTP Request Smuggling' that revolves around
piggybacking a HTTP request inside of another HTTP request, which could let
a remote malicious user conduct cache poisoning, cross-site scripting,
session hijacking, as well as bypassing web application firewall protection
and other attacks. HTTP Request Smuggling works by taking advantage of the
discrepancies in parsing when one or more HTTP devices are between the user
and the web server. CERT has ranked this attack and the associated
vulnerabilties found in multiple products as High Risk. The authors (Amit
Klein, Steve Orrin, Ronen Heled, and Chaim Linhart) have published a
whitepaper describing this technique in detail."

The Fine Print: The following comments are owned by
whoever posted them. We are not responsible for them in any way.

                  by ilyanep (823855) on Sunday June 12, @11:34AM
(#12795033)
                  (Last Journal: Thursday June 09, @07:18PM)
                  Now let's take packet A. Do an MD5 sum (or similar) on it.
Send it to the end user. Have the end user's browser do a similar check on
it and send it to the server. IF the server green flags it, then show the
page.

                  This shouldn't become a speed problem on broadband
machines because it'll only mean 2 or 3 times more packets (but you can
always increase packet size).

                  Call the new standard something like HTTPS 2.0.
                  [ Reply to This ]
                    a.. Re:Validation by Anonymous Coward (Score:3) Sunday
June 12, @11:40AM
                    b.. Re:Validation by mp3LM (Score:2) Sunday June 12,
@11:40AM
                      a.. Ah! by ShaniaTwain (Score:3) Sunday June 12,
@11:58AM
                      b.. Re:Validation by Jeff DeMaagd (Score:2) Sunday
June 12, @12:19PM
                        a.. Re:Validation by Master of Transhuman (Score:1)
Sunday June 12, @05:10PM
                          a.. 1 reply beneath your current threshold.
                    c.. Re:Validation by AndroidCat (Score:2) Sunday June
12, @11:52AM
                      a.. That's already what Apache does by wtarreau
(Score:2) Sunday June 12, @12:33PM
                        a.. Re:That's already what Apache does by AndroidCat
(Score:1) Sunday June 12, @01:00PM
                    d.. Re:Validation by Lord Kano (Score:2) Sunday June 12,
@02:30PM
                    e.. Re:Validation by Bert690 (Score:2) Sunday June 12,
@02:55PM
                    f.. 3 replies beneath your current threshold.

                  This has been going on for some time. (Score:2, Flamebait)
                  by WindBourne (631190) on Sunday June 12, @11:41AM
(#12795077)
                  (Last Journal: Sunday September 21, @09:34PM)
                  I noticed that 3 months ago.
                  [ Reply to This ]

                  Article Text (Score:3, Informative)
                  by Anonymous Coward on Sunday June 12, @11:43AM
(#12795088)
                  AC = No Karma Whoring

                  HTTP REQUEST SMUGGLING
                  CHAIM LINHART (chaiml@post.tau.ac.il)
                  AMIT KLEIN (aksecurity@hotpop.com)
                  RONEN HELED
                  AND STEVE ORRIN (sorrin@ix.netcom.com)
                  A whitepaper from Watchfire
                  TABLE OF CONTENTS
                  Abstract 1
                  Executive Summary 1
                  What is HTTP Request Smuggling? 2
                  What damage can HRS inflict? 2
                  Example #1: Web Cache Poisoning 4
                  Example #2: Firewall/IPS/IDS evasion 5
                  Example #3: Forward vs. backward HRS 7
                  Example #4: Request Hijacking 9
                  Example #5: Request Credential Hijacking 10
                  HRS techniques 10
                  Protecting your site against HRS 19
                  Squid 19
                  Check Point FW-1 19
                  Final note regarding solutions 19
                  About Watchfire 20
                  References 21

                  ABSTRACT
                  This document summarizes our work on HTTP Request
Smuggling, a new attack technique that has
                  recently emerged. We'll describe this technique and
explain when it can work and the damage it can do.
                  This paper assumes the reader is familiar with the basics
of HTTP. If not, the reader is referred to the
                  HTTP/1.1 RFC [4].
                  EXECUTIVE SUMMARY
                  We describe a new web entity attack technique - "HTTP
Request Smuggling." This attack technique, and
                  the derived attacks, are relevant to most web environments
and are the result of an HTTP server or device's
                  failure to properly handle malformed inbound HTTP
requests.
                  HTTP Request Smuggling works by taking advantage of the
discrepancies in parsing when one or more
                  HTTP devices/entities (e.g. cache server, proxy server,
web application firewall, etc.) are in the data flow
                  between the user and the web server. HTTP Request
Smuggling enables various attacks - web cache
                  poisoning, session hijacking, cross-site scripting and
most importantly, the ability to bypass web application
                  firewall protection. It sends multiple specially-crafted
HTTP requests that cause the two attacked entities to
                  see two different sets of requests, allowing the hacker to
smuggle a request to one device without the other
                  device being aware of it. In the web cache poisoning
attack, this smuggled request will trick the cache
                  server into unintentionally associating a URL to another
URL's page (content), and caching this content for
                  the URL. In the web application firewall attack, the
smuggled request can be a worm (like Nimda or Code
                  Red) or buffer overflow attack targeting the web server.
Finally, because HTTP Request Smuggling enables
                  the attacker to insert or sneak a request into the flow,
it allows the attacker to manipulate the web server's
                  request/response sequencing which can allow for credential
hijacking and other malicious outcomes.
                  HTTP REQUEST SMUGGLING
                  © Copyright 2005. Watchfire Corporation. All Rights
Reserved. 2
                  WHAT IS HTTP REQUEST SMUGGLING?
                  HTTP Request Smuggling ("HRS") is a new hacking technique
that targets HTTP devices. Indeed, whenever
                  HTTP requests originating from a client pass through m
                  Read the rest of this comment...

                  [ Reply to This ]
                    a.. patent blanket! by matt me (Score:1) Sunday June 12,
@03:17PM
                    b.. Re:Article Text -- Karma whoring???? by camusflage
(Score:2) Sunday June 12, @02:02PM
                    c.. 1 reply beneath your current threshold.

                  piggybacking (Score:2, Funny)
                  by Edzor (744072) on Sunday June 12, @11:53AM (#12795146)
                  I like to use 'piggybacking' as well, it makes me sound
technical but cool at the same time.
                  [ Reply to This ]

                  Why is this news? (Score:2, Insightful)
                  by duh_lime (583156) on Sunday June 12, @11:54AM
(#12795156)
                  If there is ANY communications path, it can be used for
anything... If you have cooperating applications, anything that passes at
least "a bit" can be subverted for another purpose. You could do Morse code
using ICMP Echo Requests, with the packet size determining whether it's a
dot or a dash... Whatever... Again, why is this particular technique news?
                  [ Reply to This ]
                    a.. Re:Why is this news? by cduffy (Score:2) Sunday June
12, @12:39PM
                          Re:Why is this news? (Score:5, Insightful)
                          by segmond (34052) on Sunday June 12, @03:26PM
(#12796508)
                          (http://www.segmond.com/)
                          Shut up! RTFP!

                          The attack allows attack worse than XSS if an XSS
vulnerability exists since this time, it doesn't require you to intereact
with the client. It allows cache poisoning. It allows you to smuggle data
past some firewall/filters that try to prevent HTTP attacks by parsing
requests, for example, so servers will filter out GET requests like
/foo/../../../whatever or /foo?cmd.exe You can use this to bypass it. This
is NEWS because it is a NEW attack. This is not about using HTTP as a tunnel
for other form of communication.
                          This exploits the fact that the cache
server/firewall and webserver might parse the same request different when it
has two "Content Length:" in it... Read the paper.
                          [ Reply to This | Parent ]

                      a.. Re:Why is this news? by argent (Score:2) Sunday
June 12, @10:02PM
                    b.. 1 reply beneath your current threshold.

                  I think this appeared in DDJ sometime ago... (Score:1)
                  by soapdog (773638) on Sunday June 12, @11:54AM
(#12795158)
                  (http://www.soapdog.org/)
                  Folks, hiding one HTTP request inside another is not the
same HTTP request hijacking technique that appeared in Doctor Dobbs journal
some months ago... I can't recall the edition...
                  [ Reply to This ]
                    a.. Re:I think this appeared in DDJ sometime ago... by
cyphersteve (Score:1) Sunday June 12, @02:57PM

                  Question of Compatibility vs. Reliability (Score:5,
Insightful)
                  by l2718 (514756) on Sunday June 12, @11:55AM (#12795161)
                  This exploit is interesting, and is related to a cultural
issue: how do you handle malformed input?

                  There are two basic approached to this: either you reject
it (the sound, security-concious way), or you attempt to make sense of it
(the compatible way). The second solution allows your software to interface
with badly-written external code, at the cost of interfacing with
intentionally malformed requests like the exploit the describe.

                  The reason the exploit works is that different people have
different methods for determining what the sender of the malformed packet
really meant, and if two different interpretations are applied to the same
packet you can use the resulting "confusion" to your advantage. Different
recount results which depend on guessing "voter intent" from malformed
ballots in Florida comes to mind.

                  [ Reply to This ]
                          Re:Question of Compatibility vs. Reliability
(Score:4, Insightful)
                          by iabervon (1971) on Sunday June 12, @01:11PM
(#12795669)
                          (http://iabervon.org/~barkalow/ | Last Journal:
Saturday May 31, @03:01AM)
                          The actual issue is cases where someone makes
sense of malformed input and then passes that input on to something else.
The proper thing to do is always pass on correctly-formed input. If you get
malformed input and interpret it somehow, you then need to pass on your
interpretation, not the original. The guideline is to be permissive in what
you accept and strict in what you transmit; when you're passing something
on, you need to canonicalize it in transit.

                          A good example of this is how the legal system
works. When a court makes a decision on the application of a law to an
unclear situation, that becomes part of the case law, such that there is a
consistent interpretation, rather than an ambiguous situation being
interpreted randomly each time it occurs.
                          [ Reply to This | Parent ]

                      a.. Re:Question of Compatibility vs. Reliability by
Lord Kano (Score:2) Sunday June 12, @02:39PM

                  Be very careful (Score:5, Funny)
                  by Anonymous Coward on Sunday June 12, @11:58AM
(#12795178)
                  It is unethical and immoral. Some HTTP requests even
time-out and have died doing this! Also be aware that some vigilante border
gateway protocols have sprung up in the south looking for smuggled HTTP
requests. Also new federal legislation may require all web servers to
validate the HTTP request's green packets before responding.
                  [ Reply to This ]
                    a.. Re:Be very careful by PerspexAvenger (Score:1)
Sunday June 12, @12:08PM
                    b.. 1 reply beneath your current threshold.

                  Possible way to burn down RSS? (Score:3, Interesting)
                  by krowten21 (891493) on Sunday June 12, @12:03PM
(#12795215)
                  Scenario: Vulnerable web server for popular blogging site,
compromised by this or other attack, RSS feed used to broadcast exploit
against vulnerable IE 7.0 clients. predicted at www.threatchaos.com att he
beginning of the year.
                  [ Reply to This ]
                    a.. Re:Possible way to burn down RSS? by SpaceLifeForm
(Score:2) Sunday June 12, @04:55PM

                  Quick Summary (Score:3, Informative)
                  by MojoRilla (591502) on Sunday June 12, @12:08PM
(#12795244)
                  Due to bad handling of borderline html, some web servers
will see extra requests that front end servers (cache, proxies) don't see.
This is due http keepalive (so that more than one request can be processed
in a stream) and malicious http headers. This seems to be implemented mostly
by sending duplicate or invalid content length headers.

                  I'm sure that all of these problems will be quickly
patched. All of these issues would be fixed by tighter HTTP parsing
specifications. However, buggy software will always exist, and always be
exploited.
                  [ Reply to This ]
                    a.. Re:Quick Summary by wfberg (Score:2) Sunday June 12,
@01:10PM
                      a.. Re:Quick Summary by John Hasler (Score:2) Sunday
June 12, @02:26PM
                    b.. Re:Quick Summary by MooseGuy529 (Score:3) Sunday
June 12, @02:38PM
                    c.. 1 reply beneath your current threshold.

                  Hype it up? (Score:1, Insightful)
                  by Anonymous Coward on Sunday June 12, @12:12PM
(#12795264)
                  This paper discusses potential exploitation of poor HTTP
parsing in specific applications. Potential applications include cache
poisoning and hijacking user credentials but it requires the victim to be
behind a vulnerable proxy/firewall.

                  Why not just issue seperate advisories and inform the
respective vendors? Seems to me like they bundled multiple flaws in multiple
products so they could be creditied with discovering a new class of
vulnerability.
                  [ Reply to This ]
                    a.. Re:Hype it up? by Sven Tuerpe (Score:2) Sunday June
12, @12:46PM
                    b.. 2 replies beneath your current threshold.

                  publicfile (Score:2, Informative)
                  by sugarmotor (621907) on Sunday June 12, @12:12PM
(#12795271)
                  (http://stephan.sugarmotor.org/)
                  http://cr.yp.to/publicfile.html [cr.yp.to], publicfiloe,
is not mentioned.
                  [ Reply to This ]

                  Well this is not good (Score:2, Insightful)
                  by suitepotato (863945) on Sunday June 12, @12:33PM
(#12795404)
                  From TFA:

                  Conclusion: We have seen that there are many pairs
(proxy/firewall servers and web servers) of vulnerable systems.
Particularly, we demonstrated that the following pairs are vulnerable: PCCA
o IIS/5.0 o Tomcat 5.0.19 (probably with Tomcat 4.1.x as well) Squid
2.5stable4 (Unix) and Squid 2.5stable5 for NT o IIS/5.0 o WebLogic 8.1 SP1
Apache 2.0.45 o IIS/5.0 o IS/6.0 o Apache 1.3.29 o Apache 2.0.45 o WebSphere
5.1 and 5.0 o WebLogic 8.1 SP1 o Oracle9iAS web server 9.0.2 o SunONE web
server 6.1 SP4 ISA/2000 o IIS/5.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE
web server 6.1 SP4 DeleGate 8.9.2 o IIS/6.0 o Tomcat 5.0.19 o Tomcat 4.1.24
o SunONE web server 6.1 SP4 Oracle9iAS cache server 9.0.2 o WebLogic 8.1 SP1
SunONE proxy server 3.6 SP4 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web
server 6.1 SP4 FW-1 Web Intelligence kernel 55W beta (the IIS 48K technique
probably works with R55W) o IIS/5.0 This is a partial list - there are many
pairs we did not test and there are likely many other web servers and cache
servers we did not test for lack of hardware and software. Of course, there
are probably many more similar techniques.

                  Yeah, really? I'd like to see a much broader list laid
out, and preferably before it becomes another net disaster.

                  If this was strictly a Microsoft thing we'd be hearing
cries for blood, or at least an app to check if your setup was vulnerable.
Since it is much broader than that, if checking for this doesn't become part
of a security toolkit, we may well wish it had.

                  Oh well. At least we got this much warning this much in
advance. Anyone want to take bets on how long till some malware weasels make
this a point and click thing in another script kiddie kit? My guess is
before the security world makes a test app to check for it.
                  [ Reply to This ]
                    a.. Tomcat workaround by mparaz (Score:2) Sunday June
12, @03:24PM

                  Working example available? (Score:2)
                  by pongo000 (97357) on Sunday June 12, @12:36PM
(#12795423)
                  The world is full of hypotheticals...can someone actually
point us to a working example of this alleged exploit? If not, I'll just
file it away as "cool information with little practical impact on my daily
life."
                  [ Reply to This ]
                    a.. Re:Working example available? by failure-man
(Score:2) Sunday June 12, @01:25PM
                    b.. Re:Working example available? by slavemowgli
(Score:2) Sunday June 12, @01:44PM

                  PCCA?? (Score:2, Interesting)
                  by d3ac0n (715594) on Sunday June 12, @12:56PM (#12795570)
                  (Last Journal: Monday October 13, @10:39AM)
                  Does anyone have any idea what the Popular Commercial
Cache Appliance is? The PDF doesn't say and we have a few cache appliances
at my office (intranet and internet). I'd like to know just vunerable we are
to this type of thing.
                  [ Reply to This ]
                    a.. Re:PCCA?? by cyphersteve (Score:2) Sunday June 12,
@02:50PM
                    b.. Re:PCCA?? by d3ac0n (Score:1) Sunday June 12,
@01:25PM
                    c.. 1 reply beneath your current threshold.

                  Smuggling, eh? (Score:1)
                  by Aldric (642394) on Sunday June 12, @03:43PM (#12796617)
                  When will HTTP Customs be introduced as a fix?
                  [ Reply to This ]

                  Re:Problem reading the PDF... (Score:3, Funny)
                  by Dogers (446369) on Sunday June 12, @11:39AM (#12795064)
                  (Last Journal: Saturday May 07, @10:10AM)
                  Tried to do a copy and paste, but the lameness filter wont
let me. DRM in force! ;)
                  [ Reply to This | Parent ]
                    a.. I AC posted the article by camusflage (Score:2)
Sunday June 12, @11:50AM
                    b.. Re:Problem reading the PDF... by Damhna (Score:1)
Sunday June 12, @11:54AM

                  Re:and here's where... (Score:3, Interesting)
                  by Anonymous Coward on Sunday June 12, @11:59AM
(#12795191)
                  Actually the whitepaper sates that IIS and Apache
automatically dump the malformed packet.

                  Microsoft does write a few good lines of code.
                  [ Reply to This | Parent ]
                    a.. Re:and here's where... by ohzero (Score:1) Sunday
June 12, @12:15PM
                    b.. Re:and here's where... by gtwilliams (Score:1)
Sunday June 12, @01:12PM
                    c.. Re:and here's where... by drumist (Score:1) Sunday
June 12, @05:06PM

                  Re:Problem reading the PDF... (Score:3, Informative)
                  by Anonymous Coward on Sunday June 12, @12:00PM
(#12795197)
                  Here is a link:
                  http://www.gatech-edu.org/HTTP-Request-Smuggling.p df
[gatech-edu.org]
                  [ Reply to This | Parent ]
                    a.. Re:Problem reading the PDF... by arose (Score:2)
Sunday June 12, @01:37PM
                    b.. Re:Problem reading the PDF... by shepmaster
(Score:1) Sunday June 12, @05:25PM

                  Re:and here's where... (Score:1)
                  by ohzero (525786) <mharrigan@f8e n t ertainment.com> on
Sunday June 12, @12:12PM (#12795272)
                  (http://www.f8entertainment.com/ | Last Journal: Tuesday
September 09, @02:59PM)
                  flamebait? Anyone with half a clue would understand that
this is just a fact. If you don't believe me.. watch the updates. I
guarantee you that headlines will read almost verbatim what I said come
Monday.

                  Then again, this is slashdot... I guess I shouldn't expect
people to understand things.
                  [ Reply to This | Parent ]

                  Re:Prediction (Score:1, Insightful)
                  by Anonymous Coward on Sunday June 12, @12:36PM
(#12795426)
                  This is Slashdot, News for Nerds, not "your average bloke
on the street".

                  Your post would make alot more sense if the article was
mentioned on CNN.com or the like, but not here.
                  [ Reply to This | Parent ]

                  Re:Old news... (Score:2)
                  by Panaflex (13191) on Sunday June 12, @01:57PM
(#12795941)
                  I wrote my own web server 5 years ago.. faster than
Apache, cheaper than others. Doesn't have this problem.

                  -Pan
                  [ Reply to This | Parent ]
                    a.. Re:Old news... by rbarreira (Score:2) Sunday June
12, @03:45PM
                    b.. 1 reply beneath your current threshold.

                  Re:Old news... (Score:2)
                  by JRHelgeson (576325) on Sunday June 12, @02:26PM
(#12796125)
                  (Last Journal: Sunday October 19, @05:54PM)
                  Bah, I'm a reseller who enjoys a product... is it so wrong
to share it with people? I have no dog in this fight.
                  [ Reply to This | Parent ]

                  a.. 9 replies beneath your current threshold.



                  By failing to prepare, you are preparing to fail.
              All trademarks and copyrights on this page are owned by their
respective owners. Comments are owned by the Poster. The Rest © 1997-2005
OSTG.

      [ home | awards | contribute story | older articles | OSTG | advertise
| about | terms of service | privacy | faq | rss ]


------------------------------

From: Lisa Minter <lisa_minter2001@yahoo.com>
Subject: Snocap Opens to Independent Artists
Date: Mon, 13 Jun 2005 10:18:14 -0500


The online music service Snocap said on Monday that it would allow
independent artists and small record labels to register their songs to
receive payment when they are traded over Internet "peer-to-peer"
networks.

Snocap, the latest venture of Napster founder Shawn Fanning, uses
digital "fingerprint" technology to identify songs that are swapped
online.

Peer-to-peer networks can use Snocap to block unauthorized copies of
songs and replace them with protected versions that can be controlled
by their owners.

Only one peer-to-peer service has signed up to use Snocap so far, but
the company says it is in talks with others.

Snocap officials hope that existing peer-to-peer services like Kazaa
and LimeWire will turn to Snocap as a way to end their legal battles
with recording companies and convert the millions of songs that are
copied over their networks into a steady revenue stream.

Three out of the four major labels -- Universal Music Group, (EAUG.PA)
Sony BMG (6758.T)(BERT.UL) and EMI Group Plc (EMI.L) -- have
registered their songs with Snocap, as have larger independent labels
like TVT and Rykodisc.  Snocap said it is in talks with the fourth
major label, Warner Music Group Corp. (NYSE:WMG - news).

Snocap founder Fanning first shot to notoriety when he turned the
music industry upside down with Napster, the first software program
that allowed users to copy music from each others' hard drives for
free.

Napster has since been relaunched as an industry-approved download
service.


Copyright 2005 Reuters Limited. 

NOTE: For more telecom/internet/networking/computer news from the
daily media, check out our feature 'Telecom Digest Extra' each day at
http://telecom-digest.org/td-extra/more-news.html . Hundreds of new
articles daily.

------------------------------

From: Lisa Minter <lisa_minter2001@yahoo.com>
Subject: Nokia Cooperates With Apple on New Web Browser
Date: Mon, 13 Jun 2005 10:20:25 -0500


Nokia is developing a mobile browser for its Series 60 smartphone
software in cooperation with Apple Computer Inc. , the Finnish
telecoms equipment maker said on Monday.

Nokia said in a statement the new browser will use the same open
source components as Apple's Safari Internet browser. Nokia added the
browser will be available during the first half of 2006 and said it
would continue to cooperate with Apple.

In March, Nokia signed a deal with Apple's competitor, Norway's Opera
Software, to put Opera's mobile Internet software on more Nokia
phones, after having licensed Opera's browser for a total of 11 Nokia
models in recent years.


Copyright 2005 Reuters Limited.

NOTE: For more telecom/internet/networking/computer news from the
daily media, check out our feature 'Telecom Digest Extra' each day at
http://telecom-digest.org/td-extra/more-news.html . Hundreds of new
articles daily.

------------------------------

From: Lisa Minter <lisa_minter2001@yahoo.com>
Subject: Hong Kong Plans to Enact Anti-Spam Law
Date: Sun, 12 Jun 2005 21:12:45 -0500


Hong Kong plans to enact an anti-spam law next year to crack down on
companies that send unsolicited e-mails or make automated
telemarketing calls to consumers, an official has said.

The government has consulted with industry groups to craft a law that
would combat junk faxes, e-mails, text messages and telemarketing
calls.

Au Man-ho, director-general of the Telecommunications Authority, said
in a statement Saturday that direct marketing companies using
automated calling on an unsolicited basis "can be considered a spam
problem."

However, Au said the law -- to take effect at an unspecified date in
2006 -- would not cover "manually made cold calls" to avoid
interfering with normal business activities.

He said the issue still requires public discussion and that the
government was working with fixed-line and mobile operators to create
a code of practice for telemarketing.

Copyright 2005 The Associated Press.

NOTE: For more telecom/internet/networking/computer news from the
daily media, check out our feature 'Telecom Digest Extra' each day at
http://telecom-digest.org/td-extra/more-news.html . Hundreds of new
articles daily.

------------------------------

Date: Sun, 12 Jun 2005 21:08:37 -0400
From: Monty Solomon <monty@roscom.com>
Subject: Qualcomm Announces Winners of BREW 2005 Developer Awards


- U.S. and International Wireless Publishers and Developers Receive
                          Recognition at BREW 2005 -

SAN DIEGO, June 6 /PRNewswire/ -- QUALCOMM Incorporated (Nasdaq:
QCOM), pioneer and world leader of Code Division Multiple Access
(CDMA) digital wireless technology, today announced the winners of its
BREW 2005 Developer Awards, a global awards program that recognizes
and promotes the best BREW(R) applications created by wireless
publishers and developers.  The winners were revealed during an awards
ceremony at the BREW 2005 Conference, being held at the Manchester
Grand Hyatt in San Diego.

QUALCOMM congratulates the BREW 2005 Developer Awards winners:

    -- Most Innovative Use of Technology:  AtlasBook by Networks in Motion
       (U.S.) and Buggy Boom with Motion Detection by MEDIASEEK Inc.
       (Japan)/3G Vision Inc. (Israel)
    -- Best Business Application:  Remo by Remoba Inc. (U.S.)
    -- Best Location-Based Service Application:  Friend-Finder Service by
       Pointi Corporation (Korea)
    -- Best Communications Application: Pop Mailer by MEDIA SOCKET Inc.
       (Japan)
    -- Best Information Application: Diabetes Management by Healthpia Inc.
       (Korea)
    -- Best Entertainment Application:  Song IDentity by Rocket Mobile Inc.
       (U.S.)
    -- Best Game Application: Asphalt: Urban GT by Gameloft (France)
    -- Best Ringtone Application: Modtones DJ by Moderati (U.S.)
    -- People's Choice Award: Song IDentity by Rocket Mobile Inc. (U.S.)

     - http://finance.lycos.com/home/news/story.asp?story=49654232

------------------------------

Date: Sun, 12 Jun 2005 22:11:42 -0400
From: Monty Solomon <monty@roscom.com>
Subject: Cable Outlets Decline to Air Abstinence Ad


By Associated Press 

FALL RIVER -- A television ad urging teenagers to abstain from sex has
been deemed inappropriate for young children by some networks on
Comcast Corp. cable television and will not be seen on several
channels geared to younger viewers.

The spot, sponsored by the Catholic Social Services program, ACTION,
which stands for Abstinence Challenging Teens in Our Neighborhood, was
supposed to run on cable stations in seven communities in southeastern
Massachusetts. An official with Comcast said the decisions were up to
the individual networks and not the cable company.

http://www.boston.com/news/local/massachusetts/articles/2005/06/12/cable_outlets_decline_to_air_abstinence_ad/

------------------------------

From: Monty Solomon <monty@roscom.com>
Subject: T-Mobile: 450,000 People Paid to Use Wi-Fi
Date: Mon, 13 Jun 2005 13:00:00 CDT 


By BRUCE MEYERSON AP Business Writer

NEW YORK (AP) -- T-Mobile USA disclosed user statistics from its Wi-Fi
business for the first time Monday, reporting that 450,000 customers
have paid to access the wireless Internet service in the past three
months.

The cell phone company declined to provide a year-ago customer tally
for comparison, but did release figures showing a sharp increase in
usage for the service, which provides high-speed Internet access for
laptops at locations such as Starbucks coffee shops, airports and
hotels.

For example, T-Mobile Hotspot users are staying online an average of 
64 minutes per login in 2005, up from 45 minutes last year and 23 
minutes in 2003. The total number of log-ins has totaled 3 million in 
the past three months, vs. about 8 million in all of 2004.

The Wi-Fi service is a key business for T-Mobile, which unlike many of
its mobile phone rivals is not upgrading its cellular network to
deliver high-speed Internet access in addition to phone service.


      - http://finance.lycos.com/home/news/story.asp?story=49800520

------------------------------

Date: Mon, 13 Jun 2005 12:54:51 -0400 (EDT)
From: Telecom dailyLead from USTA <usta@dailylead.com>
Subject: T-Mobile Focuses on Wi-Fi


Telecom dailyLead from USTA
June 13, 2005
http://www.dailylead.com/latestIssue.jsp?i=22285&l=2017006

		TODAY'S HEADLINES
	
NEWS OF THE DAY
* T-Mobile focuses on Wi-Fi
BUSINESS & INDUSTRY WATCH
* Analysis: Daichendt's exit a setback for Nortel
* Microsoft picks Aruba for corporate Wi-Fi network
* SOMA raises $50M
* Vonage gives away wireless routers
USTA SPOTLIGHT 
* USTAs VoIP Webinar Series: Now Available On Demand!
HOT TOPICS
* Nortel's president resigns
* Qwest eyes XO, source says
* BT set to launch hybrid phone
* VoIP has a long way to go
* FCC makes E911 order official
EMERGING TECHNOLOGIES
* Broadcom, France Telecom test HDTV over DSL
* Ericsson unveils technology to allow in-flight calls
REGULATORY & LEGISLATIVE
* Dispute over wireless e-mail patents gets messier

Follow the link below to read quick summaries of these stories and others.
http://www.dailylead.com/latestIssue.jsp?i=22285&l=2017006

------------------------------

Date: Sun, 12 Jun 2005 15:59:50 -0400
From: John Stahl <aljon@stny.rr.com>
Subject: Re: Cell Phone Rental in Europe


My wife frequently travels to Europe, Asia, etc. so she has needs for a 
cell phone. She uses phones from an outfit called CellHire USA.

Their URL is http://www.cellhire.com/.

She has found this outfit easy to work with and they pay for the
freight to send you the phone just before you leave and for its return
upon your return home.

Not sure about phones, rates, etc. but you can check them out at the
above URL as they show various phones for various countries depending
upon your travel plans.


John Stahl
Data/Telecom Consultant
Aljon Enterprises

------------------------------

From: Steve Sobol <sjsobol@JustThe.net>
Subject: Re: Companies Subvert Search Results to Squelch Criticism
Date: Sun, 12 Jun 2005 14:47:22 -0700
Organization: Glorb Internet Services, http://www.glorb.com


Monty Solomon wrote:

> It's not illegal, but it's SEO gone bad. Companies such as Quixtar are
> using Google-bombing, link farms and Web spam pages to place positive
> sites in the top search results -- which pushes the negative ones
> down.

Yeah, and there may be no laws against it, but if it's done on a large
enough basis you can bet they'll get sued.

Quixtar's slimy anyhow ... it doesn't surprise me that they were used
as the example in the quoted article.

JustThe.net - Steve Sobol / sjsobol@JustThe.net / PGP: 0xE3AE35ED
Coming to you from Southern California's High Desert, where the
temperatures are as high as the gas prices! / 888.480.4NET (4638)

"Life's like an hourglass glued to the table"   --Anna Nalick, "Breathe"

------------------------------

From: John McHarry <jmcharry@comcast.net>
Subject: Re: 'Phone Tapping' Modem Traffic ?
Date: Sun, 12 Jun 2005 23:34:39 GMT
Organization: EarthLink Inc. -- http://www.EarthLink.net


On Fri, 10 Jun 2005 06:13:12 -0500, jg wrote:

> Hi, 

> I believe my 'voice line' is being tapped [the line feeds through the 
> 'opponents' switchboard].

> How difficult is it for them to 'decode' my modem [to ISP] traffic ?
> I'm guessing/hoping that my modem has to 'synchronise' with the ISP's
> in analog mode, so it's difficult for a '3rd' party to listen ?

> Is this right ?

I don't think it is difficult at all. The modems negotiate a speed
that will work over the link, but if the tap is getting as good a
signal as the end points, it should be no problem to listen in. Your
only hope would be to use some form of encryption with shared
secrets. You are not likely to have an ISP that supports that.

------------------------------

From: Joseph <JoeOfSeattle@yahoo.com>
Subject: Re: Bellsouth Caller ID
Date: Sun, 12 Jun 2005 18:20:18 -0700
Reply-To: JoeOfSeattle@yahoo.com


On Sun, 12 Jun 2005 04:12:48 -0400, Choreboy
<choreboyREMOVE@localnet.com> wrote:

> The next day your phone begins chirping during a funeral.  Because
> your wife and daughter are with you, you never expected this.  By the
> time you turn it off you are getting dirty looks.

If you are such an insensitive clod to not put your phone on silent or
shut it off they *should* give you dirty looks.  Ever heard of using a
little common sense?  Shut the damned thing off when you're in a
movie, a concert, a funeral or any number of other situations where
it's not just tacky it's rude.  Take some personal responsibility for
your own actions. 
           

[TELECOM Digest Editor's Note: First of all (going back to the
original complaint about someone getting your cell phone number from
caller ID) use *67 on cell phones in the same way you use it on your
landline phone. Caller ID is not passed in that case.) Second, I _always_
put my cell phone on silent (or sometimes just turn it off) whenever I
am in a church or at a concert or lecture. Usually I just turn it to
silent mode or battery vibrating mode, then I can glance at the
display and if it is a call I want to receive, I can excuse myself and
go outside to deal with it.  PAT]

------------------------------

From: hancock4@bbs.cpcn.com
Subject: Re: Schools Prohibit Personal E-mail Sites
Date: 13 Jun 2005 07:48:17 -0700


Fred Atkinson wrote:

> So, then you are saying that they should remove ham radio books from
> the library?  I don't think so.

I wouldn't think a reputable quality ham-radio book would present any
problem in a school library.  Because the book would be for younger
readers, I would hope that the book contains prominent cautions and
warnings about any power dangers in the equipment or installing
outside aerials.  When I was a kid there were ham radio books in both
school and public libraries.  It was considered a wholesome hobby.
There were also ham radio clubs in school.

>> As to the Internet: There is a great deal of mis-information out
>> there, some of it even dangerous.  Anybody can set up a site and put
>> anything they want on it; that by no means makes it authoritative or
>> appropriate.  Even legitimate organizations screw up on their Internet
>> sites by failing to keep the information timely and accurate.

> There has been misinformation in publications since the beginning of
> time.  Anyone can write and sell a book if they want to go to the
> trouble.  How is this any different?

While anyone can write a book and pay to publish it, getting it
distributed and purchased is another matter entirely.

There is a big difference between book publishing and Internet web
pages.  Anyone can set up a web page at very modest cost that looks
authoritative and accurate but may be actually garbage or even a scam.

On the other hand, to get a book published and distributed takes a lot
of effort.  Reputable book publishers make some effort to edit serious
non-fiction offerings (not including fad books such as diet books).
Books for libraries are reviewed and rated.  It is by no means a
perfect system; but my point is that there is at least some editing
and selection process going on at various levels; on the Internet
there is none whatsoever.

>> As mentioned, student "access" is already quite limited in many ways.

> So, we justify limiting them to things that could be beneficial to
> them to achieve that end?

The original argument "students are now being limited to what they can
see" was a bad premise to begin with -- kind of a "Have you stopped
beating your wife yes/no?" question.  Every time this issue comes up
activists get all excited about supposed constitutional rights, etc.,
and things get blown all out of proportion.  Starting statements like
that is bad public discourse.

My response remains merely that for a variety of reasons things were
always limited to students.  I also note that schools and institutions
bear much liability if kids abuse what they have.  That is, the school
and its administrations get into the trouble, not the kids who did the
mischief.  It is only reasonable for the administrators to take steps
to protect themselves.  It is no different that employers who limit
employee's Internet access or "free speech" in the workplace to cover
their liability.

It's easy for outsiders, who bear no liability risks, to tell other
people what to do and what risks to bear.  But not exactly fair.


[TELECOM Digest Editor's Note: Lisa Hancock, I really do not care for
your attitude on this. If books are good (because they were very
time-consuming and costly to prepare and edit) and web pages are bad
(basically for the lack of the same reasons) then how do you explain
some of the total crap which has been published over the years, such
as the literature published by A. Hitler and others in Germany during
the 1920-30's and much also in America?  And although I am only a mere
web publisher and could not begin to meet the expenses required of
having an editorial/fact-checking staff, my attitude is that the
_truth will eventually prevail_ and any sort of ethical web publisher
tries his best to make room for _all sides_ of an issue to be aired. 

What you have done is give a slap in the face to everyone who has 
attempted to present some social issue or another using the web as the
media of choice because of its low cost and ease of use. Not everyone
can _afford_ the cost of fancy printing and binding; all they want to
do is present the facts as they know them to the largest number of
people possible. Many or most of us under those circumstances do at
least use a kind of peer-review policy. PAT] 

------------------------------

From: HarryHydro <harryhydro@hotmail.com>
Subject: Re: Microwave Fading 6 Gig
Date: 13 Jun 2005 11:03:59 -0700


GlowingBlueMist wrote:

> HarryHydro <harryhydro@hotmail.com> wrote in message
> news:telecom24.259.5@telecom-digest.org:

>> Hi Folks:

>>    I wrote a qbasic program that scans 4 Alcatel radios.  It also
>> pages me on problems.  I was called almost 10 times around 1:30AM this
>> morning (6/9/05) and again around 4:00AM even more times!  My heel are
>> draggin'.  Anyway,  this has been going on for the last few days.
>> These are not stormy evenings, or even windy.  In the plots this
>> program makes, I see signals dropping, or maybe it's noise level
>> increasing, enough to break microwave paths.  This is 6gig stuff ... The
>> 4 radios at this site point in different directions, and the radios
>> almost go wacky the same time, but not exactly.  For a half hour, the
>> signal on one radio faded to almost break while the others were doing
>> OK.  Sometimes the two receivers on one radio will fade together,
>> sometimes not. (diversity)  I've associated some of these to mag
>> storms, but most are weather related.  However, these last few days
>> have been pretty stable.

>> Could it be temperature inversions at 1:30 in the morning doing this?

>> Harry

> I don't know about your location but when I was monitoring microwave
> sites for the military in Germany, most of the temperature inversion
> problems we ran into was in the early morning.  The hills would cool
> off but the valleys would hold the heat unless a breeze was blowing.
> As you have already identified, the fact that your diversity beams
> tend to drop out at slightly different times helps to point to a
> temperature inversion problem if weather was ruled out.

> We did tend to have one other problem with fighter aircraft using our
> towers as practice targets.  Either the bulk of the aircraft
> themselves or the aircraft electronic systems would drop the link as
> they came in for the final run.

Hi: Thanks for the reply:

I'm in Jersey.  Our microwave runs out of Southern Pennsylvania, into
Jersey, then out Northern PA.  Hills all over.  We're having all kinds
of MW problems this morning, but this time signals look good, but
maybe multipath.  Plus, there is a rather long Magnetic storm
happening.  It's slowly clearing up, at the same time everyone is
trying to 'fix' it..;-) 

Take Care!

Hydro

------------------------------


TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
networks such as Compuserve and America On Line, Yahoo Groups, and
other forums.  It is also gatewayed to Usenet where it appears as the
moderated newsgroup 'comp.dcom.telecom'.

TELECOM Digest is a not-for-profit, mostly non-commercial educational
service offered to the Internet by Patrick Townson. All the contents
of the Digest are compilation-copyrighted. You may reprint articles in
some other media on an occasional basis, but please attribute my work
and that of the original author.

Contact information:    Patrick Townson/TELECOM Digest
                        Post Office Box 50
                        Independence, KS 67301
                        Phone: 620-402-0134
                        Fax 1: 775-255-9970
                        Fax 2: 530-309-7234
                        Fax 3: 208-692-5145         
                        Email: editor@telecom-digest.org

Subscribe:  telecom-subscribe@telecom-digest.org
Unsubscribe:telecom-unsubscribe@telecom-digest.org

This Digest is the oldest continuing e-journal about telecomm-
unications on the Internet, having been founded in August, 1981 and
published continuously since then.  Our archives are available for
your review/research. We believe we are the oldest e-zine/mailing list
on the internet in any category!

URL information:        http://telecom-digest.org

Anonymous FTP: mirror.lcs.mit.edu/telecom-archives/archives/
  (or use our mirror site: ftp.epix.net/pub/telecom-archives)

RSS Syndication of TELECOM Digest: http://telecom-digest.org/rss.html
  For syndication examples see http://www.feedrollpro.com/syndicate.php?id=308
    and also http://feeds.feedburner.com/TelecomDigest

*************************************************************************
*   TELECOM Digest is partially funded by a grant from                  *
*   Judith Oppenheimer, President of ICB Inc. and purveyor of accurate  *
*   800 & Dot Com News, Intelligence, Analysis, and Consulting.         *
*   http://ICBTollFree.com, http://1800TheExpert.com                    *
*   Views expressed herein should not be construed as representing      *
*   views of Judith Oppenheimer or ICB Inc.                             *
*************************************************************************

ICB Toll Free News.  Contact information is not sold, rented or leased.

One click a day feeds a person a meal.  Go to http://www.thehungersite.com

Copyright 2004 ICB, Inc. and TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.

              ************************

DIRECTORY ASSISTANCE JUST 65 CENTS ONE OR TWO INQUIRIES CHARGED TO
YOUR CREDIT CARD!  REAL TIME, UP TO DATE! SPONSORED BY TELECOM DIGEST
AND EASY411.COM   SIGN UP AT http://www.easy411.com/telecomdigest !

              ************************

Visit http://www.mstm.okstate.edu and take the next step in your
career with a Master of Science in Telecommunications Management
(MSTM) degree from Oklahoma State University (OSU). This 35
credit-hour interdisciplinary program is designed to give you the
skills necessary to manage telecommunications networks, including
data, video, and voice networks.

The MSTM degree draws on the expertise of the OSU's College
of Business Administration; the College of Arts and Sciences; and the
College of Engineering, Architecture and Technology. The program has
state-of-the-art lab facilities on the Stillwater and Tulsa campus
offering hands-on learning to enhance the program curriculum.  Classes
are available in Stillwater, Tulsa, or through distance learning.

Please contact Jay Boyington for additional information at
405-744-9000, mstm-osu@okstate.edu, or visit the MSTM web site at
http://www.mstm.okstate.edu

              ************************

   In addition, gifts from Mike Sandman, Chicago's Telecom Expert
   have enabled me to replace some obsolete computer equipment and
   enter the 21st century sort of on schedule. His mail order 
   telephone parts/supplies service based in the Chicago area has
   been widely recognized by Digest readers as a reliable and very
   inexpensive source of telecom-related equipment. Please request
   a free catalog today at http://www.sandman.com 
   ---------------------------------------------------------------

Finally, the Digest is funded by gifts from generous readers such as
yourself who provide funding in amounts deemed appropriate. Your help
is important and appreciated. A suggested donation of fifty dollars
per year per reader is considered appropriate. See our address above.
Please make at least a single donation to cover the cost of processing
your name to the mailing list. 

All opinions expressed herein are deemed to be those of the
author. Any organizations listed are for identification purposes only
and messages should not be considered any official expression by the
organization.

End of TELECOM Digest V24 #265
******************************

Return to Archives**Older Issues