Turn it off then!
This is entirely optional. It asks you when you first install and connect the router via the WiFi landing page if you want to use any blocking. If you don't answer the question or select no, there is no blocking at all apart form the IWF firewall stuff. Every kind of blocking comes with problems of some description. You either live with it or trust your users.
[1] £7.50/month for ADSL2 for 12 months with line rental and calls included was too good a deal to throw away. I'd go for Andrews & Arnold if I could afford idealism at the moment.
While I do agree that parental controls are not foolproof; occasionally legitimate sites get caught up in the blacklist and kids will usually find a way around many blocks, suggesting parents completely disable such censors is a little like throwing the baby out with the bath water.
I have three children, all of whom use the Internet regularly and bar some passive monitoring, I've done nothing. They have healthy browsing habits.
Blacklists, censorship, firewalls and control are missing the point...
Plus you're going to get goatse'd at some point in your life...
(b) What should you do? Phone up the tech support line and tell them you (essentially) want to look at fisting porn? What if they recognise your voice? What if someone finds out that you want to look at all that dodge extreme porn sites?[1]
[1] I'm not saying this is accurate, just how some people think.
b) No - see my post. When you connect the router and hit it with the first WiFi connection, it is configured by default to allow everything. At which point you can then tell them you don't want oodles of fisting porn shoved at you or just ignore the question and carry on getting your fix.
The only thing these statements prove is that the noiser people are consistently more likely to be wallies.
I've heard Xilo are quite good regarding filtering, quality, etc., and they're cheaper than A&A.
No catch. Confirmed no traffic management, no download limit, free router, free migration. This is purely for customer retention.
I'm 800m away from the exchange and get 12.2Mbits down and 1.1Mbits up.
I pull an average of 120Gb/month over the line with no problems.
Edit: just to add I was paying £35.50/month with O2 before which is crazy amounts.
For many users (especially your average home/family users with less technical requirements, not using it for critical purposes such as home working) they're probably perfectly adequate.
FWIW, I use BT's (formerly British Telecom) FTTC Infinity for Business product. 78Mbps down, 20Mbps up, worst case 1:20 contention, no caps or allowance-related FUP. Their customer care and technical teams are pretty decent. And I can get a /29 in addition to the dynamic PPP IP for the WAN link. Where I am (NE Scotland), BT own all of the widely available (non-private) infrastructure so it's easier to deal with a single company in the event of a failure vs being pushed between ISP and infrastructure provider. YMMV.
EDIT: FYI I pay £45 ex VAT (~AUD 102).
Why would anyone use code.jquery.com, really? They obviously don't mind a third party hosting their js, so why not use the most popular service (google) to increase the chances that users arrive at their website with jquery already cached?
Because webmasters would rather compromise the security and integrity of their site, and the privacy of their users, than pay for the initial burst of bandwidth and latency for first time visitors. jQuery 2.1.0 production, minified and gzipped is still over 30KiB, compared to this thinkbroadband page which is only 6 KiB (and yes this page uses about half a dozen external js resources, including jQuery)
Perhaps it's about time we had a way to specify the hash of <script> source inline so browsers can serve files from cache even if they are from different origins
A spec for just that was recently proposed[0], it even has support for a "canonical" script to be used in the event of that the hash check fails.
The good news is a polyfill for this can probably be created today. If CDNs serve their JS with the proper CORS headers, you can request the JS with cross-domain XHR and check it against a hash before eval()ing the script.
The bad news is that the polyfill would require you to allow `unsafe-eval` if you use Content-Security-Policy headers. Depending on your security model, it'd probably be best to host all your resources yourself. Not to mention that using a hash function written in javascript might negate any performance gains.
[0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/
They'd be much more likely to know that blocking anything from Google is probably a bad idea/false positive but they've probably never heard of jQuery and when they look at the jquery*.js files all they see is The Matrix.
So if you allow the above assumption, it's less likely that using Google's CDN would present this problem.
But for liability, a few questions pops up. Who is the offended party, and how much negligence is required for software bugs. Does it need to be a civil suit with each customer, or can the website owners sue? If a truck crash right outside a store and disrupt business, the store owner can sue even if they have no formal relation with the truck company.
They will stop working eventually
So you may try to load from them, but always have a fallback. In your website
An example: what if code.jquery.org gets compromised?
I know it's probably not considered great practice anymore but I generally just self host js libs. One less thing to go wrong and I often develop without an internet connection. Saves on having to dropback to a fallack every time.
The gain is not significant enough to balance problems like this one. It's not often than a consumer ISP does this mistake, but that's pretty common for a user behind a corporate proxy.
We went to locally-hosted copies of jquery stuff. We kept using Google for JS they hosted, since their uptime way beats ours.
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="path/to/your/jquery"><\/script>')</script>
Mind you, I'm not surprised that someone updating the list is on a Sunday night is not qualified.
That can't be true because it would make reputation attacks really easy.
Edit: Just saw this: "It appears that the jquery CDN is unblocked once more on Sky connections where the phishing filter that is part of the parental controls system was enabled."
We will continue to work with Sky to prevent this from happening in the future.