[webkit-dev] Content Security Policy for WebAssembly

[Francis McCabe via webkit-dev]

Hello Webkit devs
  We would like to get an official position on this proposal.
  The proposal is to extend the coverage of W3C Content Security Policy (
https://www.w3.org/TR/CSP3/) to include WebAssembly modules.
  Currently, CSP has an option to manage policy for WebAssembly execution
through the 'unsafe-eval' source directive. However, the primary role of
that directive is to allow eval in JavaScript.
 This change adds a specific source directive 'wasm-unsafe-eval' to CSP
that permits an engine to compile and instantiate a wasm module. In
addition, the proposal is to extend the coverage of existing script-src
directives to include wasm modules downloaded using the fetch API. This
would affect instantiateStreaming and compileStreaming.

The link to the proposed changes to CSP is
https://github.com/w3c/webappsec-csp/pull/293.
The link to the proposed change in WebAssembly's web API is
https://github.com/WebAssembly/content-security-policy/tree/fgm-patch-4

Thank you
Francis McCabe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for Position on Exception Handling in WebAssembly

[Saam Barati via webkit-dev]

Hi Andreas,

We're in favor of this proposal.

Tracking work for this proposal in: 
https://bugs.webkit.org/show_bug.cgi?id=229681

Cheers,

- Saam

> On Aug 27, 2021, at 3:26 AM, Andreas Haas via webkit-dev 
>  wrote:
> 
> Hello webkit-dev,
> 
> We would like to get an official position from WebKit on the Exception 
> Handling in WebAssembly proposal 
> (https://github.com/WebAssembly/exception-handling 
> ). We experimented with 
> WebAssembly Exception Handling successfully in an Origin Trial and plan to 
> ship our implementation soon.
> 
> Cheers, Andreas Haas
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa via webkit-dev]

On Mon, Aug 30, 2021 at 2:58 AM Thomas Steiner  wrote:

> On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa  wrote:
>
>> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:
>>
>>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  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  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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/l

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

[Thomas Steiner via webkit-dev]

>
> OK, so you are using the existing OS-level network interface settings.
> At least on Linux, that is a heuristic-based per-interface setting with
> a manual override.
>

That's great. It's an entirely manual setting on Android and Windows, but I
imagine certain rules like "SSID is 'Android AP'" already would go a long
way. The way this signal is obtained is not part of the proposal, the
proposal barely focuses on reflecting what the OS provides. This does not
mean browsers couldn't add an override, but it definitely does mean that
the browser is in no way involved with guessing if the current network is
metered or not.


> > 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
).

Cheers,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro via webkit-dev]

OK, so you are using the existing OS-level network interface settings. 
At least on Linux, that is a heuristic-based per-interface setting with 
a manual override.


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.


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

> Why would it be implemented as a manual setting in the browser, rather
> than a per-connection setting controlled by the OS?


It’s exactly this, a per-connection setting controlled by the OS and
reflected as is by the browser:
https://github.com/tomayac/netinfo/blob/relaunch/README.md#metered-connections
.

Cheers,
Tom
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro via webkit-dev]

On Mon, Aug 30 2021 at 10:16:54 AM +0200, Thomas Steiner via webkit-dev 
 wrote:
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.


Why would it be implemented as a manual setting in the browser, rather 
than a per-connection setting controlled by the OS?


On Linux, NetworkManager already knows whether each network interface 
is metered or not. Users can override the choice in the unlikely event 
it guesses wrong. Why should a web browser offer a second level of 
override in addition to existing system settings? Are you planning to 
offer a browser-level override for every network interface separately, 
or just one single toggle that doesn't consider which network interface 
is in use?


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa  wrote:

> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:
>
>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  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. 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.

Cheers,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

(I noticed the spec preview link had gone stale. Please use
https://raw.githack.com/tomayac/netinfo/relaunch/index.html instead.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa via webkit-dev]

On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:

> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  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. 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.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev