The Un-Official Proxomitron Forum

Pages: 1 2 3

What about writing a new config between all creating a new standard?

It should modify almost nothing, it is the base.

It should decide what must be or not parsed by proxomitron (many files are not filtered by default. For example the syndication of this forum)

It should define many variables, wich would act to give more safety to our filters, making them also more easy to write. (Defining variables to know where we are, html, body, head, post-html, script, url parts, etc...)

We could investigate to create a good method to filter things but using Header filters, injecting info in the URL to know if it is offsite, to write some info in the killed page, etc...

The basic filters everybody should share and know how to use. With that, we could create complex filters and share them easily in the forum.

Filtering ads it's nice but not to be included in the base. Althought we could create a .js file with standard functions like toggle.

It might seem a very a ambitious project, but it isn't really. Its only to start it. Some people here, me one of them, wrote their own configs from scratch and could help a lot with our experiences. It could be like a Sidki lite, but improved with new helps.

I hope everybody get the idea behind this thread, and think the same. From "the base config" different configs could be created easily.

Write what you think, what would you add, from where you want we begin...

Yeah lets get started Smile!

I think sidki config set will be outdated some day. So lets start nice and early and get it "right"

Let's begin...

Enabling filtering by extension____________________________________

This filter was created to enable filtering in files wich usually are not parsed by proxomitron by default.

An example: http://prxbx.com/forums/syndication.php
Extensions by now: php (more extensions will be added in the future)

Code:

[HTTP headers]

In = TRUE

Out = FALSE

Key = "Content-Type: Enabling filtering by extension {ln}081218"

URL = "*.(php)(\?*|)"

Match = "\1"

Replace = "\1$FILTER(true)$LOG(wEnable filtering by extension)"

How to contribute to this filter: if you find a extension wich is not filtered by default. Replace (php) with (php|your_extension1|your_extension2|your_extension3)
Test if it works, and PM me the extension you added to improve this filter.
If you have an improvement to this filter post it here Wink

These following filters allows you to confirm when downloading executables. The autor is Kye-U.
I removed confirmation on .exe files. Firefox includes a confirm, if you want to add it, replace eml for eml|exe in both filters

Code:

[HTTP headers]

In = FALSE

Out = TRUE

Key = "!-URL-Killer: Catch Suspicious Extensions {Kye-U} (out) REMOVED EXE"

URL = "(^$LST(Trusted-Web))(^*=(^http://*.(^([a-z]+{2,4})(^/))))*.(hta|eml|hlp|jse|lnk|url|ba(s|t)|c(om|md)|vb(e|s|)|s(cr|hs)|p(if|cd)|a(d(e| p)|nr)|c(hm|pl|rt)|i(ns|sp)|m(d(b|e)|s(c|i|p|t))|ws(f|h|c))(^?)$LOG(R$DTM(c) URL-Killer, Catch suspicious extensions: BLOCK?)$CONFIRM(SUSPICIOUS FILE EXTENSION FOUND\n\nBlock connection to the URL below?\n\u)"

Replace = "\k"

In = TRUE

Out = FALSE

Key = "Content-Disposition: Catch Suspicious Extensions {Kye-U} (in) REMOVED EXE"

URL = "(^$LST(Trusted-Web))"

Match = "(*filename=$AV(\1.((hta|eml|hlp|jse|lnk|url|ba(s|t)|c(om|md)|vb(e|s|)|s(cr|hs)|p(if|cd)|a(d(e |p)|nr)|c(hm|pl|rt)|i(ns|sp)|m(d(b|e)|s(c|i|p|t))|ws(f|h|c))\2)))$LOG(R$DTM(c) Content-Disposition,Catch suspicious extensions: BLOCK?)$CONFIRM(SUSPICIOUS FILE EXTENSION FOUND\n\nBlock connection to the file below?\n\n\1.\2\n\nHost:\n\h\n\nPath:\n\p\n)"

Replace = "\k"

Kill favicons not arriving like images. Autor: {ln}, me.
It uses favicon.ico in html folder.

Code:

[HTTP headers]

In = TRUE

Out = FALSE

Key = "Content-Type: Kill non image FavIcons {ln}081213 (in)"

URL = "*\/favicon.ico"

Match = "(\2;*|\2)&(^ image/*)"

Replace = "$LOG(R$DTM(c): Killed non image FavIcon (\2) at \u) \k $JUMP(http://local.ptron/favicon.ico)"

Bypass web filtering in the webs you put in the list Trusted-Web

Code:

[HTTP headers]

In = FALSE

Out = TRUE

Key = "URL: Bypass web filters in Trusted webs (out)"

Match = "$LST(Trusted-Web)"

Replace = "$FILTER(False)$LOG(wBypass web filters in Trusted webs in /u)"

Rapid access to debugging. Autor: me.
These filters provides rapid acces to debug and to see source bypassed. It works pressing the selected keys while loading the page.
You can select the key you prefer with the command $KEYCHK, see the help of proxomitron and about_keys from the config of Sidki.

Code:

[HTTP headers]

In = FALSE

Out = TRUE

Key = "URL: Redirect to bypassed source on pressing F8 key {ln}081116 (out)"

URL = "$KEYCHK(^F8)"

Match = "*"

Replace = "$RDIR(http://\xsrc..bypass..\h\p\q\a)$LOG(!RBypassed source================)"

In = FALSE

Out = TRUE

Key = "URL: Redirect to debug on pressing F6 key {ln}081027 (out)"

URL = "$KEYCHK(^F6)"

Match = "*"

Replace = "$RDIR(http://\xdbug..\h\p\q\a)$LOG(!RDebug================)"

The purpose of this filter is to have a more informative log window

Code:

[HTTP headers]

In = TRUE

Out = FALSE

Key = "URL: Log requests for non images and highlight info sent in URL {ln}081213 (in)"

URL = "(^local.ptron*)"

Match = "(*(;*)\3|*)\1$IHDR(Content-Type:(\2;*|\2))(^$TST(\2= image*))"

Replace = "\1$LOG(W***OPEN $DTM(c) (\2)*** \h\p\q) ($SET(0=\q\a)$TST((\0)=*)$LOG(C    \0)|) ($TST((\3)=*)$LOG(C    \3)|)"

And I $STOP() and wait for more experts Wink

any volunteer out there that wants to be Captain of this endeavor?

basically, as this "base config" expands, someone that is willing to "package" said 'base config' - ie, a downloadable file, extracted independently of whatever config readers herein are currently using...

that way, readers herein can download the "base" every once in a while, test it out, no "sandboxie" required (as Proxo is VERY "pc-friendly"), make a comment or two, then revert to their "day-to-day" config 'cause it will take quite a while for the "base" to evolve into a "day-to-day" Big Teeth

I won't post filters from sidki config, the one wich almost people use, because i don't know it. But i made a filter to resume his config to it's required filters (all the filters marked with .r)

How to use, rename de default.cfg from sidki to default.cfg.html and filter it with proxomitron enabling only this filter

This filter is not for the base config. It's only to resume the sidki's config

Code:

[Patterns]

Name = "<util> Proxomitron. Delete non required filters {ln}081216"

Active = FALSE

Limit = 2000

Match = "("

        "\[("

        "HTTP headers\]$SET(Header_filters=1)|"

        "Patterns\]$SET(Header_filters=)$SET(Web_filters=1)"

        ")PrxFail$TST()"

        ")|("

        "In = (FALSE|TRUE) "

        "Out = (FALSE|TRUE) "

        "Key = $AV(*(^*.r*))"

        "*\r\n\r\n$TST(Header_filters=1)"

        ")|("

        "Name = $AVQ(*(^*.r*)) "

        "*\r\n\r\n$TST(Web_filters=1)"

        ")"

People, post base filters from Sidki, i will not 'cause i don't know it.

I modified the filter "URL: Bypass web filters in Trusted webs (out)" adding it $LOG(wBypass web filters in Trusted webs in /u)"
Could be a good law, to add $LOG(w text refering to the title of the filter) to all the header filters for the base config.
We could define a "standard" to use Green colour for Out header filters and Yellow for In headers, or the pink colour adding H: at the beginning...

(Dec. 18, 2008 11:51 PM)ProxRocks Wrote: [ -> ]no "sandboxie" required (as Proxo is VERY "pc-friendly")

If your not running firefox i would recommend using a program i never spoke about it, it's called Sandboxie or something similar, that's to prevent the exploits of their browsers hehehehe Wink

I don't work for them and not have comissions for speaking about Sandboxie, mmmhh i will email them...

I'm a bit late here, but here's my take on this.

A new "base" config is an excellent idea and one ProxRocks has brought up before.
I think proxo needs a config supported by the community, not an individual.
It's just too much work for one person.

lnminente Wrote:It should modify almost nothing, it is the base.

I'd agree with that. In my opinion, what's needed is a framework.
All configs have some common issues that have to be dealt with.
What these issues are should be discussed.
Off the top of my head, here's a few I can think of.

First off, should a reply be filtered?
Enabling web filters based solely on the file extension, $TYPE or content-type header is not reliable.
I see a fair amount of replies come back as text/html when it's not.
Doing so can lead to filtering and/or code injection into data that is not html.
The result of this is usually not good.
To avoid this, some content sniffing needs to be done.

Another common issue is injecting scripts and css into the "head" of web pages.
Injecting "head" code at the wrong place can cause problems.
Where to inject header code is a moving target.

The js injected can also be an issue.
What should the base js do?
How do you extend whatever the "base" js turns out to be and avoid name conflicts and redundancy?
I proposed one solution here:
http://prxbx.com/forums/showthread.php?tid=844
The idea needs more work, but as an example, the tfr filter js uses this concept.

Replacement text for filters that can match in js has to be considered.
Using the wrong quote characters in replacement text can easily cause problems.
A web filter the determines when proxo is parsing js is required.

In my mind, these are some of the things a "base" config should do.
No doubt, more things need to be considered.

Scott Lemmon included several different configs with proxo, "Level 1", Level 2" etc.
Borrowing that idea, what I described above would be a "Level 0" type of config.
It doesn't really do anything except set the stage.
Other configs could be made that include various filters.
But they should be based on the "Level 0" config.

z12

thanks, couldn't have said it better myself, lol...

Thanks for contributing Mike. I propose all of us to post our favourite base filters here and now, to have in few time a working beta base config.
At the same time argue about concepts/issues wich will take us a more time, but we need to see soon a config, when we make it, more people will come to this project.

We need sidkis and grypens bases.

In above posts i wrote a filter to resume the sidki config to its required filters. An easier tip is writing .r in the find bar (for web filters and for header filters) selecting all these showing filters and exporting them to clipboard...

it's not so easy as simply posting fav's from sidki, grypen, altosax, jd5000, jakx, z12, ln, kye-u, lwc, paranoid2000, dissident, jjoe, siamesecat, belthazor, mele20, shea, whenever, leecovuk, maxbaggi, darthtrader, et cetera, ad nauseam...

doing so actually opens up a BIGGER can of worm...

that's why "framework" is important...
'cause you can't "merge-o-matic" sidki + grypen + jd5000 + altosax + jakx and expect the resultant outcome to "function"...

sure, tossed salads of a bunch of leafy greens is nice and all, but just because there are green m&m's, green jelly bellies, and green mint candies, i'm not about to toss them in there also just 'cause they're "green", lol...

PR, what i don't want is this thread got forgotten like the others... because of that i'm looking for near metas.

I can't post filters from configs i don't use, but i can test the BASE filters others posted here. Having a beta framework (aka base cfg) soon we could give it the shape all of we want. But let's go, let's give dynamics to this project Big Teeth

I updated my html zones filters, they have a part to define the start filters, the end filters and the inside scripts. If anyone of you consider they work well, we could add it here. The name of the variables used is the less important, i just used what i think will be more easy to remember and can be modified of course.

perhaps it might be a better start if we "define" exactly what a "base config" is going to be...

i mean, sidki's config has an html folder with 12 files and 2 sub-folders, one folder containing 10 files, the other containing 9 files... sidki's config has a lists folder containing 26 files, one being merely a "separator"...

sooo... is our "base config" going to be something that is simply a collection of "filters" that operate fully independently of one another?

not likely, many filters will rely on other filters, no independence at all... so this is what i mean by saying a "framework" needs established - the skeleton needs to be in place so the muscles and cartilage have a place to attach themselves to... once the skeleton, muscles, and cartilage are in working order, we can start applying our skin...

is our "base config" going to be a checkers board (the red and black version, not the Chinese version, lol)? or is it going to be a chess board where moving parts are much more intricate, the king can't castle without the rook?

In a forum is really complex and sooooo slow to take decissions for that reason i try to run, and if i run too much i like the others say me to stop. If anyone knows a faster/better way of creating document/framework online between all, something like wikipedia, everybody can edit the same document could be helpful here...

PR, I know you use the sidki config, what would you take from it? I'm curious and needed of information to start thinking the possibilities...

By the moment we could create different threads, to organize better the big amount of information we can get here. For example one thread for speaking about a format to writing filters \1 for hrefs \3 for sources... \9 for matches inside lists..., other for defining variables, etc...

I don't mind giving someone FTP access to a subfolder so that they can upload the latest config set and manage a page.
I also don't mind setting up a "Dev Wiki".

I think this is a great idea, and I'd be more than happy to provide the necessary services to aid development and release.

I don't have experience in wikis, but if it is as i think, a document online wich can be modified by us, then this would be very helpful for this project Smile!

Pages: 1 2 3