[OpenWireless Tech] Low Bandwidth HTTPS Open WiFi

[Erik Soderquist]

> On 20:05 Tue 16 Dec     , Erik Soderquist wrote:
> ...
>> As to encrypting the connection, privacy alone is a good enough
>> reason.  I don't necessarily want anyone with a sniffer being able to
>> see clear text of the fitness/health details.
>
> I guess my text wasn't really clear: Instead of HTTPS I would suggest "raw"
> TLS (not HTTP). At least it should be allowed so polling and other overhead
> can be avoided if implemented.

I'll certainly agree that 'raw' TLS rather than HTTP over TLS is more
efficient, but that is outside the scope of the open wireless
projects, and is up to the device/application programmers for things
like the example pedometer to handle.  I'm (personally at least) also
against attempting to specifically block unencrypted connections, as
that gets into either picking and choosing which ports to allow/deny,
and not every encrypted application uses the standard ports, nor does
every application using a standard encrypted port use encryption (yes,
I've found unencrypted traffic on 443 many times), or trying to look
inside the packets to test if the payload is encrypted, which means
lots more overhead, and having to be able to identify every variant of
every encryption tat might be used. Either I think would be a
nightmare to support, and again, is outside the scope of the open
wireless projects.

Rate limiting, on the other hand, I can see being a very useful
feature.  For example, a rate limit of 128-256 Kb/s (still several
times faster than the dial up most of us have used) per IP address
with a 512 Kb/s cap on the open segment would allow the example
devices ample bandwidth to update, while very effectively discouraging
warez downloaders from using the open connection, and greatly limiting
the impact to home users if someone does download huge files at that
slow rate anyway.

-- Erik