nile_c

Thanks. Take a look at fotka.pl too.

Hi Gatt, You might want to try blocking the Image Hosting: Unmoderated category. This will stop user-uploaded background images from displaying.

We're due to release such a category quite soon. It will be added as a beta initially. Care to PM me which ones are causing particular bother? I'd like to think Deep URL filtering will catch most of the circumvention attempts. Cheers,

Well that will certainly make life easier for those without HTTPS interception. I'm (personally) still amazed that they did this, given all the fuss that occurred when Bing was released. * Back then, Microsoft was seen to have failed in its duty to maintain the status quo set by Google and others. Fast forward to now and Google have failed to maintain their own status quo, consequently breaking many filters. Then again, the "status quo" is something you ought not cling to on the internet. That's why we're here ;-) Keep it safe folks... * backstory: Bing Community

This is far from ideal (since it should be in the stock builds) but I've noticed Cyanogen 5.x has a settings menu for adding a proxy. Perhaps one of you G1/ Magic / N1 guys could try that?

You're welcome. Keep us all posted and feel free to submit a ticket to support if required.

Ok, to answer your original question, no - the URL for each game doesn't change. Not in a way that would be readily useful to you. All of the BBC's multimedia is unified around a small set of flash player objects. What actually gets played is determined though variables in an XML config file, which is a separate HTTP request to the video player. This would be the route to look down, however it won't always be intuitively obvious what is coming from where, or why. It's certainly not a task you want to be racing to do just before every kick-off. Let's say we manage to get all the live games blocked... The kids will always take the path of least resistance, so what do we do once they reach IraqGoals.TV - The Best site for live streaming sports for example? It may be easier to turn this "game" on it's head, block Audio and Video, and then see where the complaints arise.

Try the following, to get you started: bbc.co.uk/player bbc.co.uk/iplayer bbc.co.uk/emp

As promised, we've put out a paper, and you guys are first to read it! See: http://www.edugeek.net/forums/internet-related-filtering-firewall/58036-smoothwall-googlessl.html It's a general document, so if you need the nuts'n'bolts of "what to do" with your Smoothie our support team are 100% au fait with all this. Alternatively me, @tom_newton: or @rob_f: are around :-)

Ladies and gents, I know this has been a hot topic, so we're very happy to give you first dibs on this one. Please find below our White Paper on Google's new secure search and what this means to you. This shan't be live on our website for a little while yet. GoogleHTTPS_whitepaper.pdf

Hi Folks. I've heard similar rumblings from E2BN and elsewhere in the country. Google have really put the cat amongst the flying rats here... As we see it, there are 3 methods to remedy the filtering concerns: 1. Block google.com HTTP&HTTPS. 2. Block google.com HTTPS only. 3. Full HTTPS interception. Methods 1 and 2 will break any web app that requires a Google Accounts logon and kill google.com in general. Boo :-( Option 2 is lesser impact - it still allows search, toolbars, and custom search etc. to work properly over HTTP. Option 3 is the most comprehensive - it allows your filter to work "as normal" with Google - just like 2 weeks ago :-) We will be publishing a white paper on this topic Very Soon TM, but our current best practice advice for those of you with in-house smoothies is Option 3 - HTTPS interception.

Good question... I wrote it down on a piece of paper for such an occasion, tell you when I find it :-)

If anyone has any specific examples (modules, files, etc.) where this is happening, feel free to poke them my way. Tom may be onto something with the lingering connection.

Cyanogen v5.0.7 is from a 2.1 (Eclair) base. I have had this on my rooted Magic for a week or two. I think that's about the newest (stable) thing you'll find.

There's another thread discussing this somewhere over here: http://www.edugeek.net/forums/news/56228-google-offer-encrypted-search-week.html As far as filtering goes, SmoothWall has HTTPS interception and when enabled but this should mean "secure" Google is treated the same as "regular Google. We're yet to give any best practice advice for those without the HTTPS option but you folks are sure to hear it here first ;-)

Hi Folks, you can also look to your web filter to protect against UltraSurf. Best practice on a SmoothWall is to visit 'guardian » filtering » per group settings' and set "Block invalid SSL certificates" and "Intercept HTTPS" for the relevant groups. Naturally, you should make sure the Web Proxies category is blocked in your filtering policy and that clients do not have direct net access.

Hmm, I'm only 6 weeks late here, but: Yes. Deep URL filtering will stop the blighters in the first instance, and dynamic analysis for the remainder.

Short answer: Transparently proxied client is not aware of auth. (Tom is on leave)

Folks, If you refresh your AV signatures via the web interface at 'system » maintenance » licenses' this issue will be solved. Otherwise, they will be updated at the next scheduled update.

Hi, We believe this to be a false positive from a recent antivirus signature. I would recommend adding the site to your custom allowed list as a temporary measure. Hopefully this will be resolved ASAP!

Like buses...

When viewing the web log filter at 'information > logs > web filter' you can restrict the view to imageshack.us using the 'Domain filter'. What appears here? Do any of the logged entries show an "EXCEPTION"?

Thanks, got that domain added into blocklist now. Nearly all of the game SWFs were flash blocked fortunately... now working on the rare exceptions.

Which web filter are we discussing tommej?

Ok, I probably wouldn't use your pac for this. It call all be done at the Smoothie. If you want to block all HTTPS: On the guardian > policy page you can create a new filter. When you click on the 'Filter:' dropdown there is a special category called All HTTPS Content. The Block action can then be used to block HTTPS. You can use either your existing allowed content rules, or create an additional filter to allow those HTTPS sites which you need. The second option is to use your SmoothWalls built-in functionality for filtering HTTPS content. Under 'guardian > filtering > per-group settings' you have the following options available: * Block invalid SSL certificates: This blocks the invalid certificates that many HTTPS based proxies will use. * Intercept HTTPS: This decrypts the connection to HTTPS sites, allowing the guardian engine to "see" the content, just as it would with plain HTTP. This is useful against the newest proxies that use valid certificates and cycle through domains rapidly. There is a little bit of extra configuration involved with HTTPS interception; your clients each need to recognize the Smoothwall as a valid CA, by importing its CA cert.