> 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 _______________________________________________ Tech mailing list [email protected] https://srv1.openwireless.org/mailman/listinfo/tech
