Re: [webkit-dev] Same-Site cookies by default

2020-03-06 Thread John Wilander 

> On Mar 6, 2020, at 6:59 PM, Patrick Griffis  wrote:
> 
> On 2020-03-06 6:51 pm, John Wilander wrote:
>> Hi Patrick!
>> 
>> Thanks for bringing this up. I’ll share my view of where we are.
>> 
>> First of all, cookies mostly live in the http layer so the various
>> WebKit ports would have to work this out independently to some extent.
>> Maybe libcurl and libsoup have readily available APIs for this?
> 
> libsoup added samesite support this cycle implemented as the spec
> describes so I was wondering if we should add a toggle for this new
> behavior.

Do you mean implemented as per SameSite=lax by default and enforced TLS for 
SameSite=none? If so, you are indeed ready to just turn it on.

SameSite support in general does not suffice for this change though, since it 
involves two upgrades of cookies, not just adhering to what incoming cookie 
headers say.

Then there’s document.cookie. I don’t know how non-Cocoa platforms stitch up 
their cookie policy to that JavaScript API.

>> Second, we have communicated tentative support for SameSite=lax by
>> default, but in terms of its privacy protections, WebKit is far ahead
>> with its Intelligent Tracking Prevention (ITP, or Resource Load
>> Statistics in open source). Servers that expect to get default
>> third-party cookie access merely through a SameSite=none; Secure
>> configuration will find that such an option does not exist under ITP.
>> Instead, third-parties who need cookie access can make use of the
>> Storage Access API which gives users control and transparency.
> 
> There are still ports without ITP; I understand the solution there is to
> implement ITP though :)

It’s there if you want it. You just need to implement the port-specific parts 
and enable the tests.

   Regards, John

>> Finally, as far as I know, Chrome is still the only browser to try out
>> SameSite=lax plus forced TLS for SameSite=none and they seem to be at
>> 10% rollout at this moment. We’d like to hear some lessons learned
>> from them since it may be a tough rollout, at least for a browser that
>> has historically allowed all cookies in third-party contexts by
>> default. Safari is among a few browsers that has not allowed that. I
>> do not know what default cookie policies the other WebKit browsers
>> have.
>> 
>>   Regards, John
>> 
 On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
>>> 
>>> Chromium has had the idea to treat all cookies as SameSite=Lax by
>>> default as well as blocking SameSite=None over HTTP for a while now,
>>> hidden behind a flag, and seem to be rolling this out soon.
>>> 
>>> The topic is discussed in detail here:
>>> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
>>> 
>>> I just wondered if other developers had any thoughts on this move and
>>> if/when WebKit should follow. The downside is of course compatibility
>>> but the upside is improved privacy.
>>> ___
>>> 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] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Alexey Proskuryakov 


> 6 марта 2020 г., в 18:29, Ryosuke Niwa  написал(а):
> 
> On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  wrote:
>> 
>> Late on Friday seems like a good time for a terminological debate (), so I’d 
>> like to propose we revisit one of the strangest items of WebKit-specific 
>> terminology: the phrase ‘roll out’.
>> 
>> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
>> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
>> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
>> mean the exact opposite, ‘revert’ or ‘roll back’.
> 
> I think the ship has sailed on this one. People who have been working
> on the WebKit project for long enough are so used to the phrase
> "rollout a patch" that it's gonna be tricky to change the terminology.
> Having said that, I'd much prefer the term "revert" over "rollout" or
> "rollback".

I've been using "roll back" lately, but "revert" seems perfectly fine.

- Alexey

> It's also the term git uses.
>> This term is confusing enough for native English speakers outside our 
>> community, let alone non-natives (since phrasal verbs are notoriously tricky 
>> as it is).
> 
> As a non-native speaker myself, I never find this term confusing
> because I have no mental model of what "rollout" or "rollback" means.
> However, I find those two terms infinitely more confusing than the
> very direct "revert".
> 
> - R. Niwa
> ___
> 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] Same-Site cookies by default

2020-03-06 Thread Patrick Griffis 
On 2020-03-06 6:51 pm, John Wilander wrote:
> Hi Patrick!
> 
> Thanks for bringing this up. I’ll share my view of where we are.
> 
> First of all, cookies mostly live in the http layer so the various
> WebKit ports would have to work this out independently to some extent.
> Maybe libcurl and libsoup have readily available APIs for this?

libsoup added samesite support this cycle implemented as the spec
describes so I was wondering if we should add a toggle for this new
behavior.

> Second, we have communicated tentative support for SameSite=lax by
> default, but in terms of its privacy protections, WebKit is far ahead
> with its Intelligent Tracking Prevention (ITP, or Resource Load
> Statistics in open source). Servers that expect to get default
> third-party cookie access merely through a SameSite=none; Secure
> configuration will find that such an option does not exist under ITP.
> Instead, third-parties who need cookie access can make use of the
> Storage Access API which gives users control and transparency.

There are still ports without ITP; I understand the solution there is to
implement ITP though :)

> Finally, as far as I know, Chrome is still the only browser to try out
> SameSite=lax plus forced TLS for SameSite=none and they seem to be at
> 10% rollout at this moment. We’d like to hear some lessons learned
> from them since it may be a tough rollout, at least for a browser that
> has historically allowed all cookies in third-party contexts by
> default. Safari is among a few browsers that has not allowed that. I
> do not know what default cookie policies the other WebKit browsers
> have.
> 
>Regards, John
> 
>> On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
>>
>> Chromium has had the idea to treat all cookies as SameSite=Lax by
>> default as well as blocking SameSite=None over HTTP for a while now,
>> hidden behind a flag, and seem to be rolling this out soon.
>>
>> The topic is discussed in detail here:
>> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
>>
>> I just wondered if other developers had any thoughts on this move and
>> if/when WebKit should follow. The downside is of course compatibility
>> but the upside is improved privacy.
>> ___
>> 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] Same-Site cookies by default

2020-03-06 Thread John Wilander 
Hi Patrick!

Thanks for bringing this up. I’ll share my view of where we are.

First of all, cookies mostly live in the http layer so the various WebKit ports 
would have to work this out independently to some extent. Maybe libcurl and 
libsoup have readily available APIs for this?

Second, we have communicated tentative support for SameSite=lax by default, but 
in terms of its privacy protections, WebKit is far ahead with its Intelligent 
Tracking Prevention (ITP, or Resource Load Statistics in open source). Servers 
that expect to get default third-party cookie access merely through a 
SameSite=none; Secure configuration will find that such an option does not 
exist under ITP. Instead, third-parties who need cookie access can make use of 
the Storage Access API which gives users control and transparency.

Finally, as far as I know, Chrome is still the only browser to try out 
SameSite=lax plus forced TLS for SameSite=none and they seem to be at 10% 
rollout at this moment. We’d like to hear some lessons learned from them since 
it may be a tough rollout, at least for a browser that has historically allowed 
all cookies in third-party contexts by default. Safari is among a few browsers 
that has not allowed that. I do not know what default cookie policies the other 
WebKit browsers have.

   Regards, John

> On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
> 
> Chromium has had the idea to treat all cookies as SameSite=Lax by
> default as well as blocking SameSite=None over HTTP for a while now,
> hidden behind a flag, and seem to be rolling this out soon.
> 
> The topic is discussed in detail here:
> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
> 
> I just wondered if other developers had any thoughts on this move and
> if/when WebKit should follow. The downside is of course compatibility
> but the upside is improved privacy.
> ___
> 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] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Konstantin Tokarev 


07.03.2020, 05:41, "Kirsling, Ross" :
> I'd be thrilled for us to use 'revert'.
> Somehow I'd convinced myself that it'd be easier to ask for this if we kept 
> the 'roll' part, but I'm not really sure why I thought so.

On the negative side, it won't be possible anymore to say that someone is on a 
roll when they revert several patches in a row :)

>
> Of course, it's fine for folks to continue to _say_ 'roll out' due to habit; 
> I just think it would be great if our automated 'rollouts' turned into 
> automated 'reverts' instead.
>
> Ross
>
> On 3/6/20, 6:31 PM, "Ryosuke Niwa"  wrote:
>
> On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  
> wrote:
> >
> > Late on Friday seems like a good time for a terminological debate (), 
> so I’d like to propose we revisit one of the strangest items of 
> WebKit-specific terminology: the phrase ‘roll out’.
> >
> > In our industry, the typical meaning of the phrase ‘roll out’ is, of 
> course, ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of 
> ‘roll out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ 
> to mean the exact opposite, ‘revert’ or ‘roll back’.
>
> I think the ship has sailed on this one. People who have been working
> on the WebKit project for long enough are so used to the phrase
> "rollout a patch" that it's gonna be tricky to change the terminology.
> Having said that, I'd much prefer the term "revert" over "rollout" or
> "rollback". It's also the term git uses.
>
> > This term is confusing enough for native English speakers outside our 
> community, let alone non-natives (since phrasal verbs are notoriously tricky 
> as it is).
>
> As a non-native speaker myself, I never find this term confusing
> because I have no mental model of what "rollout" or "rollback" means.
> However, I find those two terms infinitely more confusing than the
> very direct "revert".
>
> - R. Niwa
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin

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

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Maciej Stachowiak 

I agree this usage of “roll out” is potentially confusing.

I think people say “roll out” for the symmetry to “check in”. It also creates 
the convenient term “roll back in” for when a rollout is undone.

Personally, I think we should say “revert” and avoid use of roll-phrases 
entirely. “unrevert” isn’t quite as natural as “roll back in”, but it’s good 
enough. Or you could say “re-land”.

Regards,
Maciej

> On Mar 6, 2020, at 6:14 PM, Kirsling, Ross  wrote:
> 
> Greetings WebKittens,
>  
> Late on Friday seems like a good time for a terminological debate (), so I’d 
> like to propose we revisit one of the strangest items of WebKit-specific 
> terminology: the phrase ‘roll out’.
>  
> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
> mean the exact opposite, ‘revert’ or ‘roll back’.
>  
> In terms of metaphors: The typical meaning of ‘roll out’ is synonymous with 
> ‘roll forward’, hence the opposite being ‘roll back’. The way that I came to 
> explain to myself and others what WebKit means by ‘roll out’ is that it’s 
> movement along the other axis. There is a tree (SVN trunk) which is built up 
> from disc-shaped slices (revisions), and these slices are rolled sideways in 
> and out of the tree. Needless to say, this is not obvious to a newcomer, and 
> it’s not even accurate to how SVN works—rollouts don’t remove an old 
> revision, they add a new revision to perform the revert!
>  
> This term is confusing enough for native English speakers outside our 
> community, let alone non-natives (since phrasal verbs are notoriously tricky 
> as it is). Having heard complaints about this from people in both of these 
> groups within the last few weeks, I hereby propose that we start using ‘roll 
> back’ instead. Given the string similarity between the two, I hope that this 
> will be a relatively easy change to enact, if folks are onboard with it.
>  
> Thanks for your consideration!
>  
> Ross
> ___
> 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] Same-Site cookies by default

2020-03-06 Thread Maciej Stachowiak 

Current WebKit trunk blocks all third party cookies (with ITP enabled), which 
is a more extreme version of the same thing. We’re currently testing the 
compatibility fallout.

Treating cookies as SameSite=Lax by default is moot when third-party cookies 
are blocked, as the SameSite=None behavior would not be permitted at all.

Chromium has been just about to roll out their change for a while now, but my 
understanding is that it’s still only applied to a low percentage of users.

Regards,
Maciej

> On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
> 
> Chromium has had the idea to treat all cookies as SameSite=Lax by
> default as well as blocking SameSite=None over HTTP for a while now,
> hidden behind a flag, and seem to be rolling this out soon.
> 
> The topic is discussed in detail here:
> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
> 
> I just wondered if other developers had any thoughts on this move and
> if/when WebKit should follow. The downside is of course compatibility
> but the upside is improved privacy.
> ___
> 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] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Kirsling, Ross 
I'd be thrilled for us to use 'revert'.
Somehow I'd convinced myself that it'd be easier to ask for this if we kept the 
'roll' part, but I'm not really sure why I thought so.

Of course, it's fine for folks to continue to _say_ 'roll out' due to habit; I 
just think it would be great if our automated 'rollouts' turned into automated 
'reverts' instead.

Ross

On 3/6/20, 6:31 PM, "Ryosuke Niwa"  wrote:

On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  
wrote:
>
> Late on Friday seems like a good time for a terminological debate (), so 
I’d like to propose we revisit one of the strangest items of WebKit-specific 
terminology: the phrase ‘roll out’.
>
> In our industry, the typical meaning of the phrase ‘roll out’ is, of 
course, ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of 
‘roll out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ 
to mean the exact opposite, ‘revert’ or ‘roll back’.

I think the ship has sailed on this one. People who have been working
on the WebKit project for long enough are so used to the phrase
"rollout a patch" that it's gonna be tricky to change the terminology.
Having said that, I'd much prefer the term "revert" over "rollout" or
"rollback". It's also the term git uses.

> This term is confusing enough for native English speakers outside our 
community, let alone non-natives (since phrasal verbs are notoriously tricky as 
it is).

As a non-native speaker myself, I never find this term confusing
because I have no mental model of what "rollout" or "rollback" means.
However, I find those two terms infinitely more confusing than the
very direct "revert".

- R. Niwa


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

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Ryosuke Niwa 
On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  wrote:
>
> Late on Friday seems like a good time for a terminological debate (), so I’d 
> like to propose we revisit one of the strangest items of WebKit-specific 
> terminology: the phrase ‘roll out’.
>
> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
> mean the exact opposite, ‘revert’ or ‘roll back’.

I think the ship has sailed on this one. People who have been working
on the WebKit project for long enough are so used to the phrase
"rollout a patch" that it's gonna be tricky to change the terminology.
Having said that, I'd much prefer the term "revert" over "rollout" or
"rollback". It's also the term git uses.

> This term is confusing enough for native English speakers outside our 
> community, let alone non-natives (since phrasal verbs are notoriously tricky 
> as it is).

As a non-native speaker myself, I never find this term confusing
because I have no mental model of what "rollout" or "rollback" means.
However, I find those two terms infinitely more confusing than the
very direct "revert".

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

[webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Kirsling, Ross 
Greetings WebKittens,

Late on Friday seems like a good time for a terminological debate (), so I’d 
like to propose we revisit one of the strangest items of WebKit-specific 
terminology: the phrase ‘roll out’.

In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll out’ 
to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to mean the 
exact opposite, ‘revert’ or ‘roll back’.

In terms of metaphors: The typical meaning of ‘roll out’ is synonymous with 
‘roll forward’, hence the opposite being ‘roll back’. The way that I came to 
explain to myself and others what WebKit means by ‘roll out’ is that it’s 
movement along the other axis. There is a tree (SVN trunk) which is built up 
from disc-shaped slices (revisions), and these slices are rolled sideways in 
and out of the tree. Needless to say, this is not obvious to a newcomer, and 
it’s not even accurate to how SVN works—rollouts don’t remove an old revision, 
they add a new revision to perform the revert!

This term is confusing enough for native English speakers outside our 
community, let alone non-natives (since phrasal verbs are notoriously tricky as 
it is). Having heard complaints about this from people in both of these groups 
within the last few weeks, I hereby propose that we start using ‘roll back’ 
instead. Given the string similarity between the two, I hope that this will be 
a relatively easy change to enact, if folks are onboard with it.

Thanks for your consideration!

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

[webkit-dev] Same-Site cookies by default

2020-03-06 Thread Patrick Griffis 
Chromium has had the idea to treat all cookies as SameSite=Lax by
default as well as blocking SameSite=None over HTTP for a while now,
hidden behind a flag, and seem to be rolling this out soon.

The topic is discussed in detail here:
https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite

I just wondered if other developers had any thoughts on this move and
if/when WebKit should follow. The downside is of course compatibility
but the upside is improved privacy.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebXR on WebKit

2020-03-06 Thread Sergio Villar Senin 
Hi,

I've just uploaded a patch[1] (based on previous work from my colleague
Žan Doberšek) which brings a very basic WebXR[2] support for WebKit.
Right now is just IDLs, stubs and pretty basic platform code, mostly
empty implementations anyway.

You can see WebXR[3] as the evolution of the deprecated WebVR API
(which I recently removed from the tree). The idea is bringing the
experience of mixed reality worlds (from VR to AR) to the Web by using
the appropriate devices.

This new spec was not born in a semi-deprecated state as WebVR did.
It's currently partially shipped in Chrome/Edge[4]. Firefox has not
shipped it yet but Mozilla has been one of the original authors of the
specs with some proposals dating back to 2017. There is ongoing work to
support the spec[5].

It's worth mentioning that there are already several WPT tests[6] for
the feature (my plan is to import them ASAP and make them work as APIs
are implemented).

Another important difference from the WebVR era is that right now we
have a multiplatform Khronos standarized API for accessing VR/AR
devices and platforms called OpenXR[7]. My plan is to implement all the
platform code using OpenXR as a reference. This would allow us to use
even the same platform code for different ports. AFAIK there is no
OpenXR implementation and loader available at the moment for MacOS/iOS
but I guess it'll eventually happen (in any case the platform code
could be implemented without using OpenXR of course).

Privacy has been always a concern in the WebKit project and now it
gained the status of project goal. That's why I'd also like to mention
here that privacy was also considered[8] since the very
beginning. For example, when I attended the TPAC F2F meeting of the
WebXR WG there was a joint session with the privacy CG where
fingerprinting and other potential threat vectors were discussed.

Last but not least, I'll focus this early stages of development in the
WPE port, meaning that for example I'll be maintaining just the WPE
build configuration (other ports won't be affected). My plan is to
extend the support to other ports as the implementation matures.

Opinions?

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=208702
[2] https://immersive-web.github.io/webxr/
[3] https://github.com/immersive-web/webxr/blob/master/explainer.md
[4] https://caniuse.com/#search=webxr
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1614496
[6] 
https://wpt.fyi/results/webxr?label=experimental=master
[7] https://www.khronos.org/openxr/
[8] https://github.com/immersive-web/privacy-and-security

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