Re: Network Information API

Frederick wrote:
>this seems aligned with recent discussions elsewhere that a low level
>interface is required to allow agility in use; however I appreciate
>Anssi's goal of simplification/abstraction.

>how does this interface communicate the performance characteristics of
>each interface, or is that assumed to be known to the application (based
>on what, the names?)

Performance characteristics should be determined by using a WebPerf API to
a specific remote endpoint. There isnąt a meaningful performance value
without a remote endpoint. (Try comparing how fast your links in China
were to Chinese sites vs. how fast your links were to US sites while you
were @ TPAC.)

>a couple of privacy questions:

>does this API enhance fingerprinting possibilities by allowing
>enumeration of interfaces?

Technically you can find this by abusing network requests (both triggering
magic dns requests to determine dns provider, and making arbitrary ip
based connections to figure out local topography).

I think that for the average web page, instead of providing łnetwork
added˛ or each new network, instead, browsers could simply provide
łnetwork changed˛ when the primary network link changes. This should avoid
fingerprinting / enumeration of interfaces for the average app.

>does exposing a  persistent uuid provide user identifying information to
>applications enabling correlation of activity across applications thus
>creating a privacy risk?

So, this is a bit of a disaster of course, Iąm quite happy for it to be a
randomly generated number which is only meaningful for a single session of
a single web page - just enough so that a web site can distinguish between
the current one and the previous one or something like that.

It might instead of a uuid be a random uint4 where it promises not to
recycle the last one or two values now lost connections to the web page
and where each 

I havenąt spent enough time trying to figure out how one would want to use
it, at some point Iąll try to prototype an app or two based on an api
(definitely not this year, possibly not even next quarter).

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 9 December 2013 18:18:54 UTC