WTV ARCHIVES: WAR
Updated 3-22-00
This page, and the uninformed speculations contained within, © 1998-2000 ulTRAX@webtv.net

From: ulTRAX@webtv.net 
Group: alt.discuss.webtv.hacking 
Subject: WHAT DOES WTV SEE AS A THREAT? 
Date: Tue, Dec 8, 1998

If we try to get into the minds of the people who run WTV we might get a better idea what they consider a threat... and what they don't care about. The later is probably safe to post on. DragonLord's post falls into none of these categories. 

#1: Money. this is the reason they shut down the StayConnected trick 
#2: Security, both network and account. Intrusions into the network jepordize their trade secrets and arrangements with their partners. (see money). Key to maintaining security, at least from it's subscribers, is limiting access information on the system (so JS had to go) and access to WTV URLs. Often badmouthed as mere "Tricks", these are the URLs and Commands make our end of the system work and are necessary to hack. WTV has a pattern of systematically trying to eliminate our access to these URLs and Commands... though in doing so they are pushing us to bypass their main line of defense, the Client itself... and to use PCs. This approach may ultimately backfire on them. 
#3: Public relations: to the press, the public, and Wall Street. (see money). No corporation wants a bloody nose. If there is a hacking scare, or problems with the network... it is less competitive. (Too bad WTV does not see putting out an inferior product by not having RA5 and personal Java as a black mark.... but then WTV is a mere tool in MS's grand strategic schemes) 


From: ulTRAX@webtv.net
Group: alt.discuss.webtv.hacking 
Subject: WTV HAS DECLARED WAR ON US 
Date: Sat, Dec 12, 1998

With the past few upgrades WTV has systematically sought to limit our actions in every way they can.... from eliminating our access to WTV URLs to shrinking the sizes of form boxes we use for input. 

It is IMPERATIVE that there be ABSOLUTELY NO OPEN DISCUSSION on new methods to access WTV URLs or on ways to make the JS Code Reader work.
 
WTV is tempting fate. It is forcing us into finding ways to bypass the [safeguards in the] Client entirely. Then what will they do? In a few months it may look back and wish they had never taken away what were in essence harmless toys. 



From: ulTRAX@webtv.net
Group: alt.discuss.webtv.hacking 
Subject: Re: WTV HAS DECLARED WAR ON US 
Date: Sun, Dec 13, 1998

I know I am immensely frustrated... the last series of downgrades has ruined most of my plans for my HP. 
Yet, I know if I were running WTV network security I might do the same thing.... then again, maybe not. On some level it's overkill..... 

What are WTV's real priorties to protect? Subscriber accounts, network operations, info on future upgrades, info they don't want competitors or the press to get , etc. All of these concerns are legitimate... or at least necessary given corporate imperatives. But if WTV takes measures that exceed their legitimate intent, then we might rightly interprete it as overly aggressive. Even if we don't, there is a danger to WTV. 
As I stated last June when WTV first tried stop bombing by limiting access to WTV URLs.... that the bombers were "driven", and would soon find a way to bypass WTV's latest counter-measures. [Within a few weeks the audioscope bomb arrived.]

Well, I fear the same problem here. That those driven to hack... some for malicious reasons, some just out of intense intellectual curiousity, now have little alternative but to probe more deeply into how WTV works. 

WTV might have been better off trying to deal with brushfires that could be stopped with the changes in the Client. But if they are too aggressive in stamping out what might me non-threats.... they force people to think along new lines. That may be disasterous to them.... especially if this new line of inquiry is to bypass WTV's main line of defense. 

In the end.... WTV may be a virtual network, but it's really all just out there on the open web. 


 
From: ulTRAX@webtv.net 
Group: alt.discuss.webtv.hacking, power.hackers, webtv.tricks 
Subject: WHY SOME SECRECY IS ESSENTIAL 
Date: Fri, Dec 25, 1998 

[I have posted this] WTV Hit List before. But, it is important for everyone to realize why it is so critical NOT to post new tricks... especially regarding 

1: how to get to WTV URLs 
2: getting the JS code reader working again 

These items are high on WTV's Hit List. If you don't believe me look at all the things WTV has taken away this year alone. To get into the brain of WTV I urge people who have no idea what we are up against to find my post called "what WTV sees as a threat". It should still be up in news:alt.discuss.webtv.hacking 

JANUARY 98 DEMO CRACKDOWN: 
Kiddie Filter put on. 
Web access limited 
Mail shut off (there was a trick around it) NGs access stopped (there were waysaround it) Chat access stopped. 
MAY: 
Hacking accounts stopped. 
GoTo method to DEMO targeted. 

SUMMER 98 UPGRADE: 
Tricks removed from mail body 
Tricks removed from Sig 
Javascript removed from GoTo 
User ID in Return Mail Reports stopped 
Demo mail stopped 
Demo NG access stopped 
Misc Bomb codes deactivated 

TRICKS CRACKDOWN (Aug-Nov 98): 
Internal builds removed from Willie 
Blocks put up to prevent access to TestDrive Access to tricks pages stopped. Bypass codes stopped StayConnected trick killed Stiffer penalties for Hacking TRICKS & INFO 

FUNK 98 (NOVEMBER SERVER-SIDE UPGRADE): 
Mailto: link killed 
bgsound link killed 
NG Search trick killed 
JS Code reader killed 
Doom no longer accessible 
Jack no longer acessible 
Testdrive no longer accessible (again LOL) 
Many misc WTV-Trick URLs killed 

To the Clueless who still think it's safe to post tricks: notice any patterns in WTV actions? WTV has made it a top priority to kill JS because we can use it to analyize the WTV pages and WTV is determined to prevent us from accessing WTV URLs since that is how hacking is done. 
If anyone knows ways to get around what WTV has done.... please DON'T POST. Don't even CONFIRM that it can be done. Share info only with those who you really, REALLY trust. Just remember that the idiot blabermouths who are ruining things for all of us probably did not discover any of the tricks they post.... they got them from someone who foolishly trusted them. 



Group: alt.discuss.webtv.hacking 
Date: Mon, Feb 22, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) 
DUMMY LINKS: how they work  

It seems that the way (or "a" way) WTV disables WTV URLs in certain parts of the browser is by substituting dummy-links. How this is done is not well understood.... but I have a few more clues. Why is any of this important? Because if we can not access WTV URLs... we can not hack. WTV knows this and is working hard to cut us off at the pass. Word from Alpha, come the next upgrade we will lose more of the techniques we use. 

Anyway, I was converting a TXT page at my HP to HTML.... knowing that I'd have to disable the HTML code in places if I wanted to illustrate some code. So I used XMP tags before and after the code segments. It worked pretty well. 

It was not a problem until I had a 

Group: alt.discuss.webtv.hacking 
Date: Mon, Feb 22, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) 
Re: DUMMY LINKS: how they work  

One question comes to mind... where is OUR code being corrupted by WTV... in their servers or here in the browser? 
Another observation: I had tried to access to WTV Viewer page code on a HP. But I kept getting the Dummy Links. Since the pages were set up as HTML pages (even though all they contained was Text information) the Dummy Links were being inserted. What made it connfusing was not all links on a page were affected. Now I think I know why. 



Group: alt.discuss.webtv.hacking 
Date: Tue, Feb 23, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) 
Re: DUMMY LINKS: how they work  

P0ETHORN wrote:  "From what I have gathered on this topic, the XMP tag and dummy links go hand in hand .... " 

I suspect that the XMP and LISTING commands just reveal what we know must already be going on when we get the pink links. It's just that the command/URL substitutions are now being made visible.  I also suspect that WTV took the easy way out.... that this approach could be used in selected areas of the browser. Whether they considered the legal aspects (if there are any) who knows.  

"Although if you are having probs on a Tripod page and not a network page .... the question is ..... how the hell does webtv accomplish changing normal wtv-urls to dummy links outside the network? If tht is the case then it seems like cut and dry HP material tampering. But pushing an issue like that will be dead .... WNI will just change the TOS to restrict us from posting or displaying on HPs webtv related network info like wtv-urls. Or can they? " 

I don't think WTV could restrict anyone from using codes the whole world knows about by now. To whom could the restrictions apply? The TOS doesn't mean shit to a non-webtver. And it would seem that WTV has little to say over what we do at a third party HP Provider like Tripod. I can see the lawsuits flying now if WTV ever tried to limit what we did at our HPs. Then the next question would be... what of a page with look-alike WTV URLs that WTV's inelegant (ie. dumb) approach also alters? Even if they had some legal basis for attempting to censor HPs that have their codes.... what legal justification would they have in altering codes on a webpage full of WTV-FAVORITE look alikes? I suspect we maintain some legal rights to access HPs as written... What next? Having nipples blacked out in jpegs. Anyway, I've crossposted my concerns in other groups and hopefully someone will have some answers.



Group: alt.discuss.homepage 
Date: Tue, Feb 23, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) 
Re: LEGAL QUESTION: altered web content  

In answer to the question what are dummy links.... this is a section of a bounced test letter showing how two WTV URLs (wtv-home:/home and wtv-flashrom:/willie) were altered. 
</table> <p> [[[TEXT BODY AREA]]] <a 
href=x-wtv-dummy-bad-link:>Willie</a><br> <a href=x-wtv-dummy-bad-link:>Home</a><br> <p> [[[SIG AREA]]]<a 
href="http://www.zdnet.com/zdnn/stories/news/0,4586,2148062,00.html">WTV is Watching!!</a><br><a href=x-wtv-dummy-bad-link:>Willie</a> <p> </table> </body></amp> 

theWatcher1 wrote: "seems you're talking about the WTV codes (blacklist I believe it was called) that let's you display things like last URL visited, connection rate, WTV version, phone number dialled to access, etc. WTV has deactivated a lot of these, especially the "clear cache" codes. Unfortunately, if I understand you, some of these inactive codes do not give the red cursor upon highlight (WTV's standard "invalid link" indicator)." 

I'm am speaking about normal WTV URLs: wtv-home:/home etc. 

"Unfortunately, [overly simplistic here] WTV 'owns' these codes. They are their 'property'. They retain most if not all of the proprietary & other interest/ownership of these codes 'as they pertain to their system(s)', Even if you were to "copyright" your pages, your copyright would not trump their copyright so anything they do to alter their codes/code actions which alters the appearance or operation of your site is not ilegal." 

I know this arguement can be made.... but WTV has never made a legal case to delete these sites. Also, the reason I posted was that WTV's approach was so inelegant (ie. dumb) that it also worked on WTV URL lookalikes. Surely WTV has no copyright on WTV-FAVARITE:/XXXX yet it too will be converted into a dummy bad link. 
"Now, the excerpt below has me completely baffled: but it also prevents those from visiting a webpage which may contain these codes to see its content unaltered...and let's face it.... 99.999% of the use of these codes was" 
My point is that WTV may have have a valid intent in what they did... say to cut down on bombing and hacking. But their meat ax approach affects all of us who used these codes to simply put mail or other links in our sigs. I had one set of links that allowed on to check text size and call-waiting status. Hardly a thread to the general welfare. What few codes could be abused (like flashrom and customscript) could be limited in other ways. 


<hr>
Group: alt.discuss.homepage 
Date: Tue, Feb 23, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) DUMMY-BAD-LINK TEST  

All of the following URLs (except the last four) have been converted into dummy bad links by WTV. I'm beginning to suspect that the method WTV uses does not select WTV services to be "converted" into dummy links, but instead changes ALL the URLs which are not preceeded with the standard prefixes. This would seem to raise even more legal questions about WTV altering content of OUR letters and webpages. 
wtv-home:/home
wt-home:/home 
w-home:/home 
-home:/home 
home:/home
wtv-hame:/home
wtv-home:/hame
wtv-hom:/home
wt-home:/home
wtvhome:/home
wtv-home/home
wtv-home:home
wtv-homehome
http://wtv-home:/home
ftp://wtv-home:/home
mailto:wtv-home:/home
news:wtv-home:/home


<hr>
Group: alt.discuss.webtv.hacking 
Date: Wed, Feb 24, 1999
From: ulTRAX@webtv.net 
LETTER to WNI   

From: ulTRAX@webtv.net
Date: Wed, Feb 24, 1999, 1:18pm
To: guardian@corp.webtv.net
Cc: steveperlman@webtv.net, bruceleak@webtv.net
Subject: WNI's Policy on altering mail and HP content. 

Since the Summer 98 upgrade I have noticed that WTV has been substituting certain URLs with something called an x-wtv-dummy-bad-link in mail and on HPs we access. At first I believe this practice was limited only to WTV URLs. This to stop bombing and possible attempts at hacking.  But, I have just discovered that whatever method WTV uses can not descriminate between WTV URLs and a bad URL. This method in fact, is altering web, newsgroup, and mail content. For example if I write the code  <xmp><a href="vote_your_conscience_in_2000">vote</a> which obviously contains an invalid URL.... WTV will convert that to:  <a href=x-wtv-dummy-bad-link:>vote</a>.  This conversion can be seen when the letter is bounced OR if the letter is written as HTML and the code is isolated with XMP tags.  My questions are:  
1: What is the legal justification for WNI to alter possibly copyrighted  material we wish to view on a web page?  
2: What is the legal justification for WNI to alter the functionality of  web pages? By limiting use of WTV URLs, a web page may not function as intended by its creator. If, by WTV's actions, a person who runs a webpage is deprived of income, does that person have the right to seek a legal remedy?  
3: What is the legal justification for WNI to alter codes it does not  have a copyright on? The approach used is not limited to WTV URLs but disables nearly all "improperly" formated HTML actions involving URLs. 
4: Where in the TOS does it say we surrender the right to write bad HTML code? What gives WNI the right to alter code we may specifically have intended to use?  
5: At what point can subscribers be justified in charging WNI with  possible censorship, as my example above could indicate? If I choose to exercise my right to Free Speech but in the form of poorly written HTML code... a browser may not correctly impliment the code, but at least the code is intact. In this case, WNI is, in fact, using it service to alter and possiblly censor my right to Free Speech.  Please respond in writing. Thank you.



Group: alt.discuss.webtv.hacking 
Date: Wed, Feb 24, 1999
From: ulTRAX@webtv.net
What is "SAFEHTML"?   

Aside from the dummy-bad-links.... last Summer's upgrade brought something called "SAFEHTML". I haven't studied it much but this is what I know.  Like the dummy links, it shows up when a letter is bounced using the XMP method. The browser seems to to insert the tag into an HTML action that involves a URL. If the URL passes the test, ie is not a WTV URL or probably any of the other poorly written codes that are targeted, a safehtml tag is put into the code as shown below in the second example.  Below is a test where I tried using the safehtml tag in with the wtv-home:/home URL. It was converted into a dumy link. Te safehtml tag there is mine  But in the second example below.... which already had one safehtml tag, it got a second one. 
<a href=x-wtv-dummy-bad-link: safehtml>wtv-home:/home</a> 
<embed src="https://members.tripod.com/~W0IfDreamer/bg/trilogy.mid" safehtml safehtml autostart="true" hidden="true"> </embed>  Question is... can we use this safehtml tag for anything?



Group: alt.discuss.homepage 
Date: Wed, Feb 24, 1999
From: ulTRAX@webtv.net (///\ ulTRÅX \\\/) 
Re: DUMMY-BAD-LINK TEST  

theWatcher1 wrote: " All those lnks that you listed are included in what I called the "blacklist" . I may be wrong in using that term, but those codes listed are still WTV internal codes." The point of my "test" was to demonstrate that whatever method WTV uses to disable WTV codes DOES NOT STOP with WTV codes. It goes beyond their intent and is altering content in both our HP and private e-mail. 
vote

Let me try... though remember that you'll have to use the XMP bounce method to see it vote The following might work as well.... This is the same code disabled with an XMP tag 
 <a href=x-wtv-dummy-bad-link:>vote</a>


Group: alt.discuss.homepage 
Date: Wed, Feb 24, 1999
From: ulTRAX@webtv.net Do we have a right to write bad html?  

LOL..... the example I used was
<a href="vote_in_2000">vote</a> 
Though I removed some brackets, the HTML still rendered it invisible. 
Clearly, this was NOT a copyrighted WTV code... just my free expression of a political opinion.... at least my attempted free expression. 
Now at what point do we surrender the right to write bad HTML code when we sign up with WTV? 



Group: alt.discuss.webtv.technical 
Date: Sat, Jan 29, 2000
From: ulTRAX@webtv.net 
How Does WNI Kill URLAccess?  

WNI has killed Access both with server and client-side "downgrades". What I was wondering is if we can predict just what WNI can do (and how soon) by looking at what access methods were killed in the past and how it was done. 

For example STOCKS was killed with a server upgrade in Fall 98. But it took a Client upgrade to kill the SPELLCHECK and FIND method. 

What I'm thinking is that in the case of FIND, that entire function was client based. The page is file://rom/htmls an based in our box. But the STOCKS page was transmitted from WNI. Spellcheck is an odd duck since it seems to have once required a client side component, then seems to have been switched entirely over to the servers. 

So I was wondering about the wrl kill. It was being used as an embed in mail and posts so it might have been a server-side kill, but if all the sites are not affected, then there's got to be another explanation. Otherwise, it seems that the main Access killer is in the client.


Group: alt.discuss.webtv.technical 
Date: Sat, Jan 29, 2000
From: ulTRAX@webtv.net
Re: How Does WNI Kill URL Access?  

Here's a list of URL access methods and when/how they were killed. In come case I don't remember whether it was a client or server side change. It's my guess that methods involving FILE://ROM pages take a Client downgrade to kill them.... examples are FIND and GoTo. Other methods which involve the transmission of a page from WNI to us can be killed with a server side modification, but most likely it will work with the Access Killer already in the Client. 

SUMMER 98 UPGRADE:
Tricks removed from mail body ?
Tricks removed from Sig   ?
JS removed from GoTo     CLIENT 

FUNK FALL 98 
Mailto: link killed   SERVER 
bgsound link killed   SERVER
NG Search trick killed SERVER
JS Code reader killed SERVER 

STOCKS method : SERVER (jan 99?) 
SUBJECT method: SERVER 
FIND method CLIENT
SpellCheck CLIENT


Group: alt.discuss.webtv.technical 
Date: Wed, Feb 9, 2000
From: ulTRAX@webtv.net 
Re: How Does WNI Kill URL Access?  

So, if my theory is correct, WNI can't kill info until the next Client Upgrade.


Group: alt.discuss.webtv.technical 
Date: Wed, Feb 9, 2000
From: ulTRAX@webtv.net 
Re: How Does WNI Kill URL Access?  

I did a number of experiments over a year ago. They are in the WAR section of the Archives. 

I've yet to test my latest theory, that the WTV URLs are transcoded by the WNI proxies into the wtv-dummy links. If they appear in both the SSL connections and in a non-ssl comnections, then we're back looking at the Client.... or some combination. But, I think there can be some predictibility. There does seem to be a pattern in how WNI kills access as indicated above.


Group: alt.discuss.webtv.technical 
Date: Wed, Feb 23, 2000, 11:19pm  
From: ulTRAX@webtv.net
Re: How Does WNI Kill URL..brain froth  

I'm just going to ramble here. Maybe if we go back to WNI's first URL Killer, we might get some clue how it worked. 
OK.... we know that since the summer 98 upgrade WTV-URLs no longer work straight off web pages. Before that they worked on web pages and in mail/posts. 
They may have done this by altering page code in the proxies but having been a beta tester at the time and just having the client side (which they could not take back after I was kicked off the program) it seemed that the 2.2 client alone could kill WTV URLs. 
So, this must mean the WTV URLs on a Webpage were arriving at the client unaltered. (as opposed to the URLs being turned into dummy codes by the proxies). Yet... there are some step required: 
Step 1: the client was able to distinguish that web page from a WNI page. 
Step 2: The client was able to deactivate the WTV URLs. I'm assuming this occurred by substituting the wtv-dummy-links that appeared around the time of the summer 98 upgrade. But what are these dummy links? The appear in embedded page code revealed with XMP. 
These ideas are just jelling. More to come but feel free to add to them or tear them apart. 
One final thought: I have used the Code Reader to alter the HREF codes in an embedded page already loaded into the browser. Assuming they may have been dummy links, just rewriting the link to a WTV URL still did not help. The Killer did not seem to care about the loaded page.... It could kill the WTV URL anyway. 
To Be Continued.... 


Group: alt.discuss.webtv.technical 
Date: Thu, Feb 24, 2000, 5:27pm  
From: ulTRAX@webtv.net 
Re: How Does WNI Kill URL..brain froth2  

While it's pretty clear that WNI can kill URLs with server-side changes, we still don't know for sure if web page code is transcoded so WTV URLs become dummy links. They obviously have appeared in cache code and in XMPed embeds in mail. 
But there's a case against simple transcodeing. 
If I embed a page with WTV URLs in the JS Code Reader, and so a ifr.document.links[0].href 
look at the links, I get the proper code... not the dummy links. The dummy link substitution theory made sense since the browser obviously could detect WTV URLs on web pages by assigning them a pink link. It did not need to have someone try to access the URL, it already detected it. 
But, the JS code reader proves these codes, at least, have not been changed. If I use the Code Reader to write in a WTV URL in place of a Non WTV URL, the link becomes pink. If I substitute a WTV URL with a http://XXX the link will become yellow. The JS code would look like this: 
writeIn(ifr.document.links[0].href="http://www.webtv.net") 
This indicates that while there may be some transcoding involved in WNI's multi-layered defenses, the Client's Code Killer to date is independent of the proxies.


Group: alt.discuss.webtv.technical 
Date: Fri, Feb 25, 2000
From: ulTRAX@webtv.net 
Re: How Does WNI: subject/recent  
In an e-mail discussion with eric mcdonald he raised the matter of the how WNI killed the subject/recent trick with a server-side modification. Some of you will recall this was how the infamous amnesia bomb worked. One could also use the Title of their HP to introduce live code into the Recent panel. 
My theory had been that we might be able to predict what measures WNI needed to take to kill URL access by knowing the page it used. In the case of file://rom pages I predicted it would take a client side "upgrade" while other access from other WTV pages could be killed with server changes. This is still speculation and all the evidence needs to be examined. 
Eric's question was if the Recent panel could be deactivated with a server change, didn't that call into question the whole theory? 
My feeling was that there is no Recent Panel per se. While we've found the FIND and GoTo panels, etc etc, I don't think we've ever found the Recent panel. My impression was that the panel was a byproduct of the cache functions and was built from a generic pop-up that could be used for any purpose. Anyway, the subject lines in mail/posts were server based pages. Web pages with Titles also had to travel though the servers. It's probably too late to test now since there's a new client, but last spring this would have been a good test for SSL.


Group: alt.discuss.webtv.technical 
Date: Sat, Feb 26, 2000, 11:21pm  
From: ulTRAX@webtv.net Re: How Does WNI Kill URLs?  

If you having any thoughts on this please join the discussion in news:alt.discuss.webtv.technical 
Just a thought... correct me if I'm wrong.... but the only URL Access tool that has worked entirely off a homepage was Quik's JS method (and all the copycats). 
Even Info ultimately relies on a WTV file://rom panel. The rest ran off embeds in WTV pages. 
If true m it seems that the JS pop-up isolated the WTV URL from the old Client code killer... That is until the last Client killed the JS method. 
While we may continue to hunt for new WTV pages to embed/hide commands in, it would seem the ultimate challenge is to be able to use WTV URLs on a regular Web page. 
Sometimes just rephrasing the question leads to new answers.