Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

[jmuir1]

On Thursday, 23 May 2019 18:34:14 UTC+10, Andrea Marchesini  wrote:
> Link to the projchdfuao uo p;a ciwgbyis ygidq aurotuoeaip gup vygiupgayei 
> whejioyopuas9rqyw9e-fyes09uya90explicit "SameSite" attribute as
>"SameSite=Lax".  That is, the "Set-Cookie" value "key=value" will
>produce a cookie equivalent to "key=value; SameSite=Lax".
>Cookies that require cross-site delivery can explicitly opt-into
>such behavior by asserting "SameSite=None" when creating a
>cookie.
>2.  Require the "Secure" attribute to be set for any cookie which
>asserts "SameSite=None" (similar conceptually to the behavior for
>the "__Secure-" prefix).  That is, the "Set-Cookie" value
>"key=value; SameSite=None; Secure" will be accepted, while
>"key=value; SameSite=None" will be rejected."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798
> 
> Platform coverage: all
> 
> Estimated or target release: 69 - behind pref
> 
> Preferences behind which this will be implemented:
>  - network.cookie.sameSite.laxByDefault
>  - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
> 
> Is this feature enabled by default in sandboxed iframes? yes.
> 
> Do other browser engines implement this?
>  - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  - Safari: no signal yet.
> 
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
> 
> Is this feature restricted to secure contexts? no

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Add image/webp to default Accept header

[Junior Hsu]

Summary:
I'd like to increase the visibility for this controversial intention.
Currently Firefox send
image/webp for image content, but it fails for navigation case. By adding
image/webp
to default Accept:, developers can tell the webp support by Accept header
for navigation
and opening URL by other application, other than inspect if version >= 65
by User-Agent.
However, it doesn't not align the spec, and it makes the Accept: longer in
a hack way.

FWIW, we add image/webp to default Accept header in 65, and it's removed in
66 for
aligning the spec.

Please see the detailed discussion in the following bug, and feel free to
weigh in here
or on the bug.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1544231

Link to standard:
https://fetch.spec.whatwg.org/#fetching 4.1.3

Platform coverage: This will be exposed to all platforms.

Estimated or target release: Firefox 72

Do other browser engines implement this? Chrome, who supports webp, did.

Is this feature enabled by default in sandboxed iframes? Yes.

Junior
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: HTTP Refresh header support when the content is handled as a download

[Matt Woodrow]

Hi,

In Bug 1589270 I 
intend to remove support for handling the HTTP Refresh header while 
handling the content as a download.


This has been broken in our code with e10s enabled, since the initial 
e10s conversion.


Neither Chrome nor Safari support this, and the only specified handling 
of the Refresh header is part of initializing the document object [1], 
which isn't run for downloads.


- Matt

[1] 
https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Promise.allSettled

[Jan-Ivar Bruaroey]

On 10/31/19 4:26 AM, Paolo Amadini wrote:

On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:

 Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549 



By the way, this "catch(e => e)" call may make sense as an example in
the Stack Overflow answer (and thanks for posting it here), I just want
to point out that taken out of context it is clearly an anti-pattern.


The context here is the same as Promise.allSettled: we explicitly *do* 
want to ignore errors, right?


I thought you had a great point against Promise.allSettled: it competes 
with Promise.all for attention among people who don't understand the 
difference, leading them to use a flame thrower instead of garden rake.


At least in my pattern, there's a `catch` prominently displayed giving a 
clue errors are willfully being captured.



Unless you have guarantees about the value of "e" and the expectations
around the return value of "Promise.all", muddying the rejection and
fulfillment values together may lead to bugs that occur rarely and are
difficult to track, and potentially even security bugs.


Yes, Boris gives a proper polyfill. I'd counter that unless you're 
writing some generic library, in almost any other context, the 
anti-pattern to me is *not* having guarantees (or at least expectations) 
around the types of r and e. That said, everything you say is true.



Rejection handling has been one of the most common mistakes I've seen
when reviewing patches (although that was a while ago when promises were
still new), so it's good to be aware of those anti-patterns.


No disagreement there. Hopefully the awkward and longer name will deter 
all but those who really need it from reaching for allSettled. But yeah, 
I'm in the camp that we shouldn't have added it.


Cheers!

.: Jan-Ivar :.



Cheers,
Paolo


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Consider avoiding allSettled in tests (was: Re: Intent to ship: Promise.allSettled)

[Jason Orendorff]

On Thu, Oct 31, 2019 at 4:10 AM Paolo Amadini 
wrote:

>// INCORRECT
>//await Promise.allSettled([promise1, promise2]);
>
> The last example silently loses any rejection state.
>

Ignoring the awaited value here is like using `catch {}` to squelch all
exceptions, or ignoring the return value of an async function or method, or
any other expression that produces a Promise. Do we have lints for those
pitfalls? I'm kind of surprised that there doesn't seem to be a built-in
ESLint lint for `catch {}`.

There's nothing special about tests here, right? Those patterns are fishy
whether you're in a test or not.

-j
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Promise.allSettled

[Paolo Amadini]

On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:

     Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549 


By the way, this "catch(e => e)" call may make sense as an example in
the Stack Overflow answer (and thanks for posting it here), I just want
to point out that taken out of context it is clearly an anti-pattern.

Unless you have guarantees about the value of "e" and the expectations
around the return value of "Promise.all", muddying the rejection and
fulfillment values together may lead to bugs that occur rarely and are
difficult to track, and potentially even security bugs.

Rejection handling has been one of the most common mistakes I've seen
when reviewing patches (although that was a while ago when promises were
still new), so it's good to be aware of those anti-patterns.

Cheers,
Paolo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Consider avoiding allSettled in tests (was: Re: Intent to ship: Promise.allSettled)

[Paolo Amadini]

On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:

This always seemed trivial to me to do with:
     Promise.all(promises.map(p => p.catch(e => e)))


As Boris pointed out, this does not have proper exception handling. If
exceptions should be ignored, it may be good to call "console.error". In
case exceptions should be fatal, like in most automated test files in
mozilla-central, something like the following would be better instead:

  .catch(ex => ok(false, ex))

But unless you have an array to begin with, in test files it's generally
better to "await" on each promise. There is a danger with allSettled:

  // Better
  await promise1;
  await promise2;

  // Also valid
  await Promise.all([promise1, promise2]);

  // INCORRECT
  //await Promise.allSettled([promise1, promise2]);

The last example silently loses any rejection state.

My recommendation to avoid this pitfall would be to add an ESLint rule.
However, I don't know how sophisticated they could be, and just checking
that the caller does something with the return value may not be enough,
if passing it to "await" or calling ".then" is enough to silence the
warning. Maybe just disallow allSettled in tests unless overridden?

Cheers,
Paolo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform