[webkit-dev] Network Information API reboot: request for early feedback

Ryosuke Niwa rniwa at webkit.org
Mon Aug 30 08:48:32 PDT 2021


On Mon, Aug 30, 2021 at 2:58 AM Thomas Steiner <tomac at google.com> wrote:

> On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner <tomac at google.com> wrote:
>>
>>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>
>>>> I don't think exposing the information about whether the connection is
>>>> metered or not is acceptable from the privacy standpoint. Based on the IP
>>>> address of a user & this metered status, a website may even be able to tell
>>>> what kind of carrier plan a given user is in.
>>>>
>>>
>>> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
>>> would be a manual user setting, not a browser heuristic. This means you
>>> could easily mark your all-data included WiFi at home as metered if you
>>> wanted to, or, on the opposite end, mark your roaming data plan you
>>> purchased for a ton of money at the airport as unmetered. None of this
>>> happens without the user voluntarily revealing the information.
>>>
>>
>> I don't think it's fair to characterize any given user telling the OS to
>> reduce the data usage as a consent to be profiled by random websites. I
>> would certainly not expect such information to be exposed to ad trackers
>> and alike.
>>
>
> Apple seems to see no issue in exposing this information to iOS/iPadOS
> apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.
>
>
>> You could make the same argument for turning on low power mode but
>> battery level being low or having low power mode turned on may reveal the
>> user's socioeconomic status or user's immediate need to take
>> certain actions. It can lead to egregious consequences like this:
>> https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
>> I definitely would not want to be seeing ads promoting new SIM cards or ads
>> for a cafe with free WiFi service nearby just because I requested my phone
>> to reduce data usage.
>>
>
> Yes, bad things like that can happen, and the fact that companies like
> Uber make "evil" use of available information is no secret. At the same
> time, companies that make "good" use of information, like Algolia's example
> (
> https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client/),
> hopefully outweigh the disadvantages. We don't prohibit hammers because
> they can be abused as a weapon.
>

Please refer to https://www.w3.org/TR/design-principles/#safe-to-browse.
It's not okay to add a new API which makes the web less safe & private for
users just because the API can be used for good purposes.

And again, the information is exposed to random native apps that can
> likewise profile you. I agree there is a difference between a random native
> app and a random website, but at the same time we have mitigations like
> third-party blocking (and ITP on Apple devices) that make such profiling
> harder and harder.
>

The web and native apps have fundamentally different security &
privacy models. We don't let websites access random files in your system
without an explicit user consent.

On Mon, Aug 30, 2021 at 6:54 AM Thomas Steiner <tomac at google.com> wrote:

> > None of this happens without the user voluntarily  revealing the
>> > information.
>>
>> How would that possibly work? A new type of permission prompt? It's
>> easy for users to decide whether a website should have geolocation or
>> microphone access, but the risk here is just extra entropy, which is
>> going to be real hard to explain to users.
>>
>
> The current thinking is that there would be no additional permission
> needed. Note that the proposal reduces the overall entropy compared to the
> current API, which exposes more information:
> https://wicg.github.io/netinfo/#networkinformation-interface (compared to
> https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinformation-interface
> ).
>

That's an API WebKit has never supported and never will for various privacy
& security reasons. Also, I don't think the notion that this old API
exposed more information is necessarily true. The user actively choosing to
use low data mode is very much new information that websites couldn't
necessarily infer from the old API.

Overall, I don't think there is much left to discuss here. What you're
proposing will introduce a serious privacy concern, and it's not acceptable.

I'm going to stop replying to this thread going forward since I have other
things to do but please note that my lack of future response does not, in
any way, constitute a lack of signal or acceptance of an argument, idea, or
amendment to the proposal.

Apple's WebKit team is against this proposal like we were with the old API,
and that's not going to change unless a substantial amendment is made to
address all of the concerns we've raised thus far (as well as any new
concerns we may raise in the future) for this proposal and the old API.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210830/f3d48dbf/attachment.htm>


More information about the webkit-dev mailing list