Alpha config, possibly

[ProxRocks]

after a partial-day of "alpha-surfing", i've only bumped into TWO log-rare entries:

Code:

WEB HTML_Hex_iFrame     %3A+The+Case+for+More+Gains+Ahead     http://finance.yahoo.com/tech-ticker/article/253214/Rally-Hits-Roadblocks-The-Case-for-More-Gains-Ahead?tickers=%5EDJI,%5EGSPC,SPY,DIA,XLF,TLT,TBT
WEB Java_Object     MS ClassID     http://www.cnbc.com/js/cnbc_quote_components.js

perhaps of more interest though is that the Flash does not toggle on that first site, it doesn't actually "play" after toggling it 'on'...

[sidki3003]

Very important finding!

In proxjs-full.js, below "// Dummies.", above "// Called by Proxomitron instead of the real names", we have to add back:

Code:

// Prophylactic definitions.
var expires = new Date(0);

[sidki3003]

ProxRocks, i assume posted change did fix the Flash issue for you too?
And thank *you* for finding it!

[ProxRocks]

yep, fixed it...

along with some Flash issues that didn't create a log-rare entry, i figured one step at a time and post those later, turns out it was two birds with one stone and the above fixed them also...

[Toppy]

Just to post my current Log-Rare entries.
(Cleaned out the logfile right before applying the Alpha config.

Code:

WEB JS_Method    eval unescape     http://i.i.com.com/cnwk.1d/html/pt/pt.js
AKEY-J pkBaseURL     http://winmerge.org/
AKEY-J pkBaseURL     http://winmerge.org/downloads/
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=summary
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=commit;h=ea224ee82377496cd356999b5deadd03a2001514
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=blobdiff;f=encoder/encoder.c;h=ab9dac0bd639eb42f9f9ef00143c428cc777614a;hp=76651c409da04873e4805d1fd6c9de86f07811bc;hb=ea224ee82377496cd356999b5deadd03a2001514;hpb=3da3f957c096ad7885312b58d7ab12a7fab10111
WEB JS_Method    eval unescape     http://i.i.com.com/cnwk.1d/html/pt/pt.js
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=summary
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=blobdiff;f=encoder/me.c;h=55ca937795aae8dc559952632dfe6ea46f5f5ffd;hp=6fb4dd955b034bc8de159aeba4da02667516a04b;hb=8572d517a52cb46692d2fcc0723fdbd01d1878b6;hpb=79377d7309844d4e197ddf043fa9f115015fe286
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=commit;h=f7bfcfaa36ac3f04447f668f94db73801ca86e4d
HDR_In CT_Orig    application/xhtml+xml     http://git.videolan.org/?p=x264.git;a=blobdiff;f=encoder/me.c;h=f13e84b1b9119cc1a5ef4a815295c4213f907ef1;hp=55ca937795aae8dc559952632dfe6ea46f5f5ffd;hb=f7bfcfaa36ac3f04447f668f94db73801ca86e4d;hpb=8572d517a52cb46692d2fcc0723fdbd01d1878b6

Edited : Removed duplicate log entries.

[sidki3003]

Thanks Toppy. You (all) can also use Kye-U's log submit form. It's working.

[whenever]

Just submitted my 9.1k log using the form.

Should I empty the log or leave them there for the next submit?

[sidki3003]

Thanks. Yes please (empty).

BTW, looking at your log, i'm aware that the "<div> Remove: Floating Layers" webfilter has a high False Positive ratio, which is especially true for Chinese sites.

In fact, it's one of the two most troublesome filters in the config set (the other one being "Remove: Ad Functions II - Code", hence the reduced byte limit 1500 -> 900 in this alpha), but i don't see a way to make it safer. Nothing breaks if you uncheck it (except for possible extra pop-ins).

[whenever]

(May. 31, 2009 06:58 PM)sidki3003 Wrote:  ...but i don't see a way to make it safer...

Keep it as is will be OK. There won't be a filter to suit all situations. At least you give us choices to turn them on or off by the Exceptions-U.ptxt.

[whenever]

Example URL: http://news.sina.com.cn/s/p/2009-05-29/0...8784.shtml

The mood vote doesn't work under Alpha config while work under 0213 config.

When check any mood emoticon, below url is requested:

Code:

http://counter.sina.com.cn/querylist?format=js&entry=moodarray&callback=moodCallback&id=8&key=8%25231-1-17908784%2523http%253A%252F%252Fnews.sina.com.cn%252Fs%252Fp%252F2009-05-29%252F022117908784.shtml%2523NULL

It is caught by Top Sniff: JS & VBS Content filter under Alpha config while not under 0213 config. I am not sure if it is because of the updated Top JS Mark: Start filter.

Disable Top Sniff: JS & VBS Content filter under Alpha config will make voting work. However, the below entry in Exceptions-U.ptxt just doesn't work, which I couldn't figure out why.

Code:

counter.sina.com.cn/                $SET(0=a_jssigns.)

[sidki3003]

(Jun. 03, 2009 07:17 AM)whenever Wrote:  Example URL: http://news.sina.com.cn/s/p/2009-05-29/0...8784.shtml

The mood vote doesn't work under Alpha config while work under 0213 config.

When check any mood emoticon, below url is requested:

Code:

http://counter.sina.com.cn/querylist?format=js&entry=moodarray&callback=moodCallback&id=8&key=8%25231-1-17908784%2523http%253A%252F%252Fnews.sina.com.cn%252Fs%252Fp%252F2009-05-29%252F022117908784.shtml%2523NULL

It is caught by Top Sniff: JS & VBS Content filter under Alpha config while not under 0213 config. I am not sure if it is because of the updated Top JS Mark: Start filter.

Thanks. Although a false positive, it's not caused by a regression in the config, but actually by an improvement in the JS detection. Scripts from "counter" subdomains, especially if coming as text/html, should get blocked by default.

However, i see that "count" blocking is restricted to off-domain hosts. Maybe "counter" should be handled similarly. I don't know yet, but i'll look into it.

Quote:Disable Top Sniff: JS & VBS Content filter under Alpha config will make voting work. However, the below entry in Exceptions-U.ptxt just doesn't work, which I couldn't figure out why.

Code:

counter.sina.com.cn/                $SET(0=a_jssigns.)

That works for me. Maybe you already have a more general sina.com entry in your list, overriding the new one?
You can see the assigned keyword in the log window.

[whenever]

(Jun. 03, 2009 11:00 AM)sidki3003 Wrote:  Maybe you already have a more general sina.com entry in your list, overriding the new one?

Yes, I have another entry in my list, which is far below the counter entry:

Code:

[^.]+.sina.com.cn/                $SET(0=i_iframe:2.)

I read below words from the help file and had thought the upper entries in the blockfile would be scanned earlier than below entries, so entry position could affect URL matching.

Quote:Each line in the list is checked until a match is found - otherwise the list returns false.

By that position arrangement, I think counter.sina.com.cn will trigger the counter entry and be assigned with a_jssigns keyword, while other sina hosts will trigger the [^.]+ entry and be assigned with i_iframe:2 keyword.

It seemed I was wrong in this example. Or is it because of the internal positions changed after hashing?

[sidki3003]

Yep, the entries are rearranged internally. While you *could* get around it, better don't try it, just stick to "Each URL expression must match only once!". It's easy to achieve, have a look at the (rewritten) examples in the list's top comment.

[n8chavez]

Is it possible to get an updated version of the Google preview filter for this set? The one there is no does not work right with this "alpha."

[ProxRocks]

it's not really a sidki filter, just something i carried over from Grypen's/JD's old config and tweaked to work with sidki's config...

i've been running alpha as-is, no tweaks (not even my password form-fillers, which is hard to live without, lol)...


for the time being, i'm going to hold off on "alpha-tizing" the Google Preview filters as what's more important at this stage is reporting log-rare's to sidki for alpha improvements...

that is, unless sidki reports that he doesn't mind the Preview feature getting added in... that's his call, we do try to keep too many site-specific filters from being "in"... Google and Yahoo are kind of exceptions...