Re: Draft finding - "Transitioning the Web to HTTPS"

On Thu, Jan 15, 2015 at 7:00 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> On Thu, Jan 15, 2015 at 4:00 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
>> On Fri, Jan 9, 2015 at 7:37 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>> Pervasive low-bandwidth and power/CPU constrained edge networks are
>>> going to become very common.
>>
>> The case where a caching proxy helps in theory is when the uplink is
>> constrained compared to the edge network from the proxy to the end
>> point. If the edge network is itself slow, the case for proxy caches
>> is weak even on theoretical grounds.
>
> If each hop has low QoS (e.g. with high drop rates or congestion), the
> link slowness compounds. I believe this makes the case for local proxy
> caches stronger rather than weaker.

Is there some document that explains why the link quality would be bad
and who'd operate the proxies? And whether any of this has relevance
to case where one end of the pipe is a Web browser?

>>> Smarter hub nodes with
>>> minimal/intermittent uplink could profitably serve signed/hashed
>>> resources in a proxy context
>>
>> Why would these "things" all be requesting the same large resources?
>> (Surely the "things" aren't all requesting currently-popular movies on
>> the same edge network.)
>
> Things might want to load:
>
> - new OS images
> - new firmware images

I sure hope that "things", unlike many phones, really end up
downloading these often. There being a cache sharing opportunity,
though, assumes that the "things" on a given network would be
homogenous enough for the same software updates to be applicable to
multiple "things".

>>> for use cases where confidentiality is
>>> not necessary and direct HTTPS authority is too heavy.
>>
>> What are these use cases? Isn't the expectation that the "things" on
>> the Internet of Things will be even closer to people and, therefore,
>> be even more privacy-sensitive than what we have now?
>
> Some of their traffic will be very privacy sensitive. This traffic may
> flow over different links (e.g. opportunistic bluetooth) or use
> different protocols (tunnels built from preshared keys to hub
> devices).
>
> Some of their traffic will not in itself be privacy sensitive but
> metadata about its flows will be privacy sensitive. For instance, I do
> not want my sensors communicating directly with a third-party Internet
> service because:
>
> 1. Listeners to my uplink will know how many/what type of sensors I
> have and when they poll.
> 2. The third-party service can know precisely which sensors are
> contacting it from my connection.
> 3. Sensors may report my personal data behind my back. I desire to be
> in full control of and own my devices and I should not be required to
> permit encrypted traffic between vendor A's device and vendor A to
> achieve functionality.
>
> I may prefer to get my IoT updates over an anonymization network like
> Tor but I do not want each of my sensors running Tor (nor do I think
> most vendors or projects will nor should design for Tor from the
> sensor). In this case, it makes sense to aggregate and/or tunnel
> update requests from a hub.

These issues seem to fall under the *Internet* of Things and not under
the *Web*.

>>> Is the Web going to be part of the "Internet of Things"?
>>
>> I think debating that question requires agreement on what the Web is.
>> See https://www.mnot.net/blog/2014/12/04/what_is_the_web
>>
>> If you assume the proxy to be near the "thing" in the Internet of
>> things, it implies the "thing" would be a client--i.e. a Web browser.
>> The W3C has already been through an era when it was claimed that
>> limited browsers on underpowered devices were important. Writing specs
>> with that assumption turned out to be a mistake: The Web really took
>> off on mobile once the devices became powerful enough to run the kind
>> of browser engine desktop browser also use.
>
> I guess we should let the various software package management tools
> using HTTP(S) know that they aren't part of the Web.

Do developers of package management tools like apt-get think the tools
are part of "the Web" if they use HTTP?

Anyway, I think it would be a mistake to scope this TAG finding to
cover "everything addressable by a URL" or "everything that uses
HTTP". Such a broad scope would import enough special interests to
limit what can be definitively said. I think it's more useful to say
something more confident/definitive about the Web (or "the browsable
Web" for those who believe in more expansive definitions of "the Web")
than to say something more vague about "everything addressable by a
URL" or "everything that uses HTTP".

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Thursday, 15 January 2015 19:07:43 UTC