Dale_Mahalko

This is just a theory, but it seems possible to use javascript to get the user's browser ID string, and then for devices that are known to need additional fiddling to get working, direct them to a common website that tells them how to fix the problem. Here is where I would direct people: Wpad Wiki Page redirects could be created for each specific troublesome browser ID (the ID is the page, which redirects to a human-readable fix page). Part of the reasoning here is that this is hardly a problem limited to just me and my little school district. This is a problem that is only going to get worse around the planet, as mobile devices are hauled to schools in greater and greater numbers.

Say no to what, to the filtering requirement? Sure, schools and other government organizations in the USA can do that. It just means that federal E-Rate funding can not be used for the dedicated fiber-optic Internet service (covers 60+% of the Internet services bill, which is something like $4,000-$6,000 a month), nor can any network devices, equipment or cabling which was installed or purchased using e-Rate discounts be used. So.... looks like we're gonna be doing CIPA filtering of public devices....

What are other primay/secondary school districts doing with regard to supporting wifi-capable devices brought into the building by the public? Since the building wireless is E-Rate (federal funding) supported, in the United States we have to apply CIPA (child internet protection act) filtering rules to the public bringing in their own wireless-capable devices. Although adults are generally exempt from CIPA requirements, we have no way of knowing if they are an adult that is exempt from CIPA, or a child which is not, so the requirements must be applied broadly to all anonymous network users. This means proxy filtering must be applied to devices brought in by the public, and unfortunately proxying on mobile wireless devices is a horrible mish-mash of unsupported capabilities or hidden features. For example, I know from research that some Android devices have proxying built-in, but the standard user interface doesn't "expose" it to the regular user. , It appears that the best that can be offered so far is a tiered approach, offering transparent proxying for devices that make proxying really hard to do. For these devices they will not be able to have secure/encrypted web access because the transparent proxy protocol does not and can not support encryption. Not having secure web transactions available will severely hobble many devices. For the devices that support auto-proxy configuration, there can be a second tier, with a proxy.pac / proxy.wpad, but that too is a challenge because some devices which can do auto-proxy detection often default to manual mode, and still need twiddling in a control panel or with hidden settings on the device just to enable auto-proxy capabilities. Manual proxy configuration is the least desirable because these devices by their very nature do not stay at school, and may wander onto many other wireless networks. If manual proxying is forced enabled, then when they go home they can't get on the Internet because their device is still trying to use the school's proxy filtering. , Overall this whole process appears to be a quagmire since we can't control what mobile devices the public brings in and expects to be able to "just work", but this is a apparently a mess which many schools are going to be dragged into.