From nobody Mon Aug 1 16:12:28 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 01 Aug 2016 16:12:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470093139; bh=nurWOCxQ/riuGwfzZrPjPIcp98Edxe0939UmzQgCLco=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=e/y/iTUC93cnIC7tsv12AXHrmsAVT+IB3StvlIQVn0fgCawwIk0rKPadlcxDMb3yX N8kYM0qtnvOXQ7tAWsxhDr/ay0pOMirVe8baIxGGnSdmSHCRii9DvZPedzXlbF7CNd 8x32JwZZ2V2axgCDUJH2PmMG8E1qXxFbfp3aAIDY= To: httpwg/http-extensions Subject: [httpwg/http-extensions] Terminology in draft-ietf-httpbis-encryption-encoding (#217) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_579fd75372144_4e4f3ff7700852bc5095cc"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:12:26 -0000 ----==_mimepart_579fd75372144_4e4f3ff7700852bc5095cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit minor editorial issue: draft-ietf-httpbis-encryption-encoding seems to be using "Content Encoding" and "Content Coding" and "Content-Coding" synonymously. maybe settle on one of those terms? "Content Coding" might be best because that's what RFC 7231 uses. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/217 ----==_mimepart_579fd75372144_4e4f3ff7700852bc5095cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

minor editorial issue: draft-ietf-httpbis-encryption-encoding seems to be using "Content Encoding" and "Content Coding" and "Content-Coding" synonymously. maybe settle on one of those terms? "Content Coding" might be best because that's what RFC 7231 uses.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_579fd75372144_4e4f3ff7700852bc5095cc-- From nobody Wed Aug 3 16:54:00 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 03 Aug 2016 16:53:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470268436; bh=IMc9sPjp/uqqErrZzjS9QHk+/f4c5xtfPjTTrQNJ5No=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fUxXupkR0hnw/BqFLX6lHmwp0tpt9lfAIemX4IIewt+nbA3E7M9ZZJFG7ie3BAkb8 PQrqtVBtm76MQhP6CNxum4Uq2G7vCY8fhfCMzH4OKwESJkjg4Sa+Y12iNwVe5VmRFW gC2BNC7N0B3CR8lVTuXNK+Yg3N3vo03rHpWednBQ= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] normative reference to "key" spec (#200) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a2841416dec_60d13fd06cde52c02255d1"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 23:53:59 -0000 ----==_mimepart_57a2841416dec_60d13fd06cde52c02255d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Right, I'd argue the text _is_ informative.. It's easy enough for me to change the reference to be marked as such. Is that sufficient? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/200#issuecomment-237410877 ----==_mimepart_57a2841416dec_60d13fd06cde52c02255d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Right, I'd argue the text is informative.. It's easy enough for me to change the reference to be marked as such. Is that sufficient?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57a2841416dec_60d13fd06cde52c02255d1-- From nobody Wed Aug 3 18:45:22 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 03 Aug 2016 18:45:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470275117; bh=9phdULY23dnZZMy33RqhyY4rV90pD7TuGcakY8r3OQQ=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=mOCuNrTm8MXn0KhvHIoaQc9WtP46iOatM1x4J2n9c8Fkdke3Bw9iJJrlrPu79mpW9 uOF81BuJKnjkRa8IGsQcj0fxL3stRFt7D4MSPGSqcefkobGxS9OyA9l8aWRQ+FabcN tjCypEcP/HV62U+WRfbxXaLG5SrE6ze5Fte1Oz74= To: httpwg/http-extensions Subject: [httpwg/http-extensions] Remove DH (#218) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a29e2d6f80d_42bc3fbc5f74529c153621"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 01:45:20 -0000 ----==_mimepart_57a29e2d6f80d_42bc3fbc5f74529c153621 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is only really needed by webpush and that spec can take the necessary pieces. This is a LOT simpler as a result of this change. [Preview the changes](http://httpwg.org/http-extensions/simple_base/draft-ietf-httpbis-encryption-encoding.html). You can view, comment on, or merge this pull request online at: https://github.com/httpwg/http-extensions/pull/218 -- Commit Summary -- * Remove all mentions of DH * chmod -x -- File Changes -- M draft-ietf-httpbis-encryption-encoding.md (478) T draft-ietf-httpbis-jfv.xml (0) T draft-ietf-httpbis-rfc5987bis.xml (0) -- Patch Links -- https://github.com/httpwg/http-extensions/pull/218.patch https://github.com/httpwg/http-extensions/pull/218.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/218 ----==_mimepart_57a29e2d6f80d_42bc3fbc5f74529c153621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

This is only really needed by webpush and that spec can take the necessary pieces. This is a LOT simpler as a result of this change.

Preview the changes.

You can view, comment on, or merge this pull request online at:

  https://github.com/httpwg/http-extensions/pull/218

Commit Summary

  • Remove all mentions of DH
  • chmod -x

File Changes

Patch Links:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57a29e2d6f80d_42bc3fbc5f74529c153621-- From nobody Thu Aug 4 08:32:07 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 04 Aug 2016 08:31:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470324714; bh=VnRa916OEBpGWJulcHztFBR1Nbk113souaAbS8SWulU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DcZn473DS8o9sV8F4p+/oUTxcr15kR9I/7d5c8KUJ56vddoaY5zvMFgnJZ8kd9xjP Ci6T3ICI2JFMdmGGwExlokEpW9x01epSQSCNb2LtE2bP/BpZzngjDHkiWCC6h+GLws 4QXXoEwTfW5h1sxJJQ9tN31tq7jYjm8Zu/YI6diQ= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cache digest and scoping (#216) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a35feabcc2a_69df3fed174952c017353c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:32:04 -0000 ----==_mimepart_57a35feabcc2a_69df3fed174952c017353c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > When generating CACHE_DIGEST, a client MUST NOT include cached responses whose URLs do not share origins [RFC6454] with the request of the stream that the frame is sent upon. I'm curious, is there an explanation somewhere why this design was chosen? There seems to be a trade-off between *coverage* (maximizing the amount of useful URLs in the digest) and *privacy* (minimizing the privacy leakages relative to HTTP/2 as it stands currently). As @bryancall points out, the current proposal has suboptimal coverage. To illustrate, here are two alternate strategies: *Include all URLs for which the server is authoritative*: This is suggested by @bryancall. I believe this strategy maximizes coverage: a server can push any URL for which it is authoritative, and this strategy includes all such URLs in the digest. However, there is an increased chance for privacy leakage. Say a server is authoritative on a.com and b.com, and some user makes requests for a.com. If the cache digest includes URLs from b.com, the server can learn of those URLs even if the client never makes any requests for b.com. *Tie the digest to cookies*: This idea is inspired by @kazuho's [H2O](https://h2o.examp1e.net/configure/http2_directives.html#http2-casper), which puts the cache digest in cookies. We can't actually store the digest in cookies (it's too inefficient), but if we designed the digest in such a way that it *could* be stored in cookies, at least in theory, then we could argue that cache digests do not increase the chance for privacy leakage relative to current H2. For example, suppose a URL can be included in a cache digest only if the following conditions hold: * The server is authoritative for that URL. * The client is making a request for origin https:x.y.foo.com, the URL's origin is X, and the client has a cookie that could be sent with requests for https:x.y.foo.com *and* with requests for X. I believe this is roughly equivalent to the current proposal if the client does not have any domain-level cookies. However, if the client has a cookie for ".example.com" and the client makes a request for "www.example.com", the cache digest can include URLs from "cdn.example.com". Note that example #3 from @bryancall's initial comment would not work: on a request for "finance.yahoo.com", the digest would not include URLs from "s.yimg.com", although if the server is authoritative for both domains, the client may later make requests for "s.yimg.com", at which point the cache digest could be updated to include URLs on that origin as well. > CACHE_DIGEST allows such cache-based fingerprinting to become passive, since it allows the server to discover the state of the client's cache without any visible change in server behaviour. As a result, clients MUST mitigate for this threat when the user attempts to remove identifiers (e.g., "clearing cookies"). This could be achieved in a number of ways; for example: by clearing the cache, ... Expanding on the above design, we could view the cache digest as an internally-maintained cookie. When the browser makes a request to origin X, the browser creates a cookie with the domain set to host(X). If X is https, the cookie is Secure, otherwise it is HttpOnly. From this point forward, each time the browser caches a URL from origin X, it adds that URL to X's cache digest cookie. If a URL is evicted from the cache, it is removed from the cache digest cookie. If a page from origin X sets a cookie on domain(X), then cache cookies for all hosts Y where domain(Y) = domain(X) are linked, as it may be possible to send union(cookie(X),cookie(Y)) when an H2 connection is opened to either host. Note that the cache cookies for X and Y are linked *but not merged* as the external server may not be authoritative for both hosts -- this needs to be checked for each H2 connection. Except for being created automatically, and being sent in CACHE_DIGEST rather than Cookie, cache digest cookies behave exactly like other cookies. They are cleared when the user asks for cookies to be cleared. They are disabled when the user disables cookies. They are cleared when the browser is closed when the browser was opened in Incognito mode. There may be concerns about the following case. Suppose all hosts under `.aws.com` are served by the same cloud frontend, which terminates the H2 connection, but each host on this domain is served by a separate backend server. Now suppose `evil.aws.com` sets a cookie for `.aws.com`. Can `evil.aws.com` can spy on a user's from `alice.aws.com`? The answer is yes if the client sends a single cache digest that covers both hosts. I see two ways to prevent this: 1. Although a client may proactively send multiple cache digests, following the above rules, each digest summarizes URLs for a single origin only. (The cloud frontend would be trusted to not forward the digest for `alice.aws.com` to `evil.aws.com` -- this doesn't seem like a problem, since the frontend is already trusted to partition their traffic.) This may use extra bytes by requiring separate-origin digests to be sent in separate CACHE_DIGEST frames. 2. Cache digests from multiple origins can be merged, but the client will merge digests for `evil.aws.com` and `alice.aws.com` only if *both* origins have set a domain cookie for `.aws.com`. This potentially saves bytes by allowing one cache digest to cover the entire connection. WDYT? > When generating CACHE_DIGEST ... with the request of the stream that the frame is sent upon. Relatedly, I'm a bit confused with the last part of that sentence. I would expect CACHE_DIGEST to apply to the entire connection (StreamID = 0x0) rather than an individual stream. Why not send CACHE_DIGESTS on stream 0x0 and include an explicit scope (authority) in the CACHE_DIGEST frame? This costs a few extra bytes but will (a) eliminate a race between receiving the first request and the digest, and (b) make it more obvious *which* authority the digest applies to. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/216#issuecomment-237590179 ----==_mimepart_57a35feabcc2a_69df3fed174952c017353c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When generating CACHE_DIGEST, a client MUST NOT include cached respons= es whose URLs do not share origins [RFC6454] with the request of the stre= am that the frame is sent upon.

I'm curious, is there an explanation somewhere why this design was cho= sen? There seems to be a trade-off between coverage (maximizing = the amount of useful URLs in the digest) and privacy (minimizing= the privacy leakages relative to HTTP/2 as it stands currently). As @bryancall points out, the current proposal has suboptimal coverage. To illustrate= , here are two alternate strategies:

Include all URLs for which the server is authoritative: This = is suggested by @bryancall. I believe this strategy maximizes coverage: a serv= er can push any URL for which it is authoritative, and this strategy incl= udes all such URLs in the digest. However, there is an increased chance f= or privacy leakage. Say a server is authoritative on a.com and b.com, and= some user makes requests for a.com. If the cache digest includes URLs fr= om b.com, the server can learn of those URLs even if the client never mak= es any requests for b.com.

Tie the digest to cookies: This idea is inspired by @kazuho's H2= O, which puts the cache digest in cookies. We can't actually store th= e digest in cookies (it's too inefficient), but if we designed the digest= in such a way that it could be stored in cookies, at least in t= heory, then we could argue that cache digests do not increase the chance = for privacy leakage relative to current H2. For example, suppose a URL ca= n be included in a cache digest only if the following conditions hold:

  • The server is authoritative for that URL.
  • The client is making a request for origin https:x.y.foo.com, the URL'= s origin is X, and the client has a cookie that could be sent with reques= ts for https:x.y.foo.com and with requests for X.

I believe this is roughly equivalent to the current proposal if the cl= ient does not have any domain-level cookies. However, if the client has a= cookie for ".example.com" and the client makes a request for "www.exampl= e.com", the cache digest can include URLs from "cdn.example.com". Note th= at example #3<= /a> from = @bryancall's initial comment would not work: on a request for "financ= e.yahoo.com", the digest would not include URLs from "s.yimg.com", althou= gh if the server is authoritative for both domains, the client may later = make requests for "s.yimg.com", at which point the cache digest could be = updated to include URLs on that origin as well.

CACHE_DIGEST allows such cache-based fingerprinting to become passive,= since it allows the server to discover the state of the client's cache w= ithout any visible change in server behaviour. As a result, clients MUST = mitigate for this threat when the user attempts to remove identifiers (e.= g., "clearing cookies"). This could be achieved in a number of ways; for= example: by clearing the cache, ...

Expanding on the above design, we could view the cache digest as an in= ternally-maintained cookie. When the browser makes a request to origin X,= the browser creates a cookie with the domain set to host(X). If X is htt= ps, the cookie is Secure, otherwise it is HttpOnly. From this point forwa= rd, each time the browser caches a URL from origin X, it adds that URL to= X's cache digest cookie. If a URL is evicted from the cache, it is remov= ed from the cache digest cookie. If a page from origin X sets a cookie on= domain(X), then cache cookies for all hosts Y where domain(Y) =3D domain= (X) are linked, as it may be possible to send union(cookie(X),cookie(Y)) = when an H2 connection is opened to either host. Note that the cache cooki= es for X and Y are linked but not merged as the external server = may not be authoritative for both hosts -- this needs to be checked for e= ach H2 connection.

Except for being created automatically, and being sent in CACHE_DIGEST= rather than Cookie, cache digest cookies behave exactly like other cooki= es. They are cleared when the user asks for cookies to be cleared. They a= re disabled when the user disables cookies. They are cleared when the bro= wser is closed when the browser was opened in Incognito mode.

There may be concerns about the following case. Suppose all hosts unde= r .aws.com are served by the same cloud frontend, which term= inates the H2 connection, but each host on this domain is served by a sep= arate backend server. Now suppose evil.aws.com sets a cookie= for .aws.com. Can evil.aws.com can spy on a us= er's from alice.aws.com? The answer is yes if the client sen= ds a single cache digest that covers both hosts. I see two ways to preven= t this:

  1. Although a client may proactively send multiple cache digests, fol= lowing the above rules, each digest summarizes URLs for a single origin o= nly. (The cloud frontend would be trusted to not forward the digest for <= code>alice.aws.com to evil.aws.com -- this doesn't se= em like a problem, since the frontend is already trusted to partition the= ir traffic.) This may use extra bytes by requiring separate-origin digest= s to be sent in separate CACHE_DIGEST frames.

  2. Cache digests from multiple origins can be merged, but the client = will merge digests for evil.aws.com and alice.aws.com<= /code> only if both origins have set a domain cookie for .= aws.com. This potentially saves bytes by allowing one cache digest= to cover the entire connection.

WDYT?

When generating CACHE_DIGEST ... with the request of the stream that t= he frame is sent upon.

Relatedly, I'm a bit confused with the last part of that sentence. I w= ould expect CACHE_DIGEST to apply to the entire connection (StreamID =3D = 0x0) rather than an individual stream. Why not send CACHE_DIGESTS on stre= am 0x0 and include an explicit scope (authority) in the CACHE_DIGEST fram= e? This costs a few extra bytes but will (a) eliminate a race between rec= eiving the first request and the digest, and (b) make it more obvious which authority the digest applies to.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57a35feabcc2a_69df3fed174952c017353c-- From nobody Mon Aug 8 01:54:49 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 08 Aug 2016 01:49:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470646156; bh=oaAjFcpl0830gLR0WWLyFc2idGF+L+Jp5ZG32H7Lylk=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=IL6MjFzbuPwRKEwW2X3MryXDxPnSHiSv6EdzIg+o2CxIcwvffM71SZPhT6xdN7seb gxf3qDbELoWkud7jBs1hJeA8+AV650w541X9IomA8PI2Tj4bDVaDLoH/DqUO+v0Hu1 tchC499DnIN14ytP311Nd/8fXSzYNtE8lv5rB3a4= To: httpwg/http-extensions Subject: [httpwg/http-extensions] One repo per extension? (#219) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a8478cd32f5_62ec3feb7a99929c302634"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 08:54:48 -0000 ----==_mimepart_57a8478cd32f5_62ec3feb7a99929c302634 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit That would make it easier to watch and participate in just what is of interest to you. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/219 ----==_mimepart_57a8478cd32f5_62ec3feb7a99929c302634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

That would make it easier to watch and participate in just what is of interest to you.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57a8478cd32f5_62ec3feb7a99929c302634-- From nobody Mon Aug 8 04:30:29 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 08 Aug 2016 04:30:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470655812; bh=CFJukJWW0v7LwkwUW9B0KpmFX5BJDQrUs6XeYGLdODo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w4uG9NR8uld0EPMsQf4z5xfap6CrbrJGUTNtYQxq2iSxJp9LBWPUtM92o5XmySkWE aZiELqTAb0C9+ZDf3uuigS7XdNleYdFhd1Gm85JLlLfPCqv6fa/5M5Hueh4lFv2kbI Mv/Fu7xSEzU2gmdeJKuXcXdd5DQY5gdJFnzqpGZ0= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] One repo per extension? (#219) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a86d44366b2_1dcc3fb84ce612b854778b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 11:30:29 -0000 ----==_mimepart_57a86d44366b2_1dcc3fb84ce612b854778b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @martinthomson's feelings are well-known, as are (probably) mine. It's a pity you can't subscribe to a label, rather than just a whole repo. I do agree that as this repo gets more active, it becomes more difficult for casual or selective participation. @mcmanus any thoughts? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/219#issuecomment-238209906 ----==_mimepart_57a86d44366b2_1dcc3fb84ce612b854778b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@m= artinthomson's feelings are well-known, as are (probably) mine.

It's a pity you can't subscribe to a label, rather than just a whole r= epo. I do agree that as this repo gets more active, it becomes more diffi= cult for casual or selective participation.

@mcmanus= any thoughts?

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57a86d44366b2_1dcc3fb84ce612b854778b-- From nobody Wed Aug 10 20:48:32 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 10 Aug 2016 20:43:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470886996; bh=y7xmc/YKup1iyiEYWEm4DAu4SUWl2g8i3/Xk1I99a9w=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FJct3zULsJXJcUfbI4J7Vg7z/HkYLa8kmCJQd4P7Pmq0piePUQ06pEgPWRpM4ZkHt meERfWhIACGoIWtmw5NjgcZrhR/AZWNdy8kugur06uAwe8LPqPX/YrtEXz9flcSfgB 30FAS+lIes8c6zo6gvehOg847QaJPFeDi9BAt/Fc= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57abf454937b9_447a3fcd91d532b813788c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 03:48:31 -0000 ----==_mimepart_57abf454937b9_447a3fcd91d532b813788c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Right. The pushback against doing something like this that I've heard is that no matter what we say in the spec, people are going to just point the JSON parser they have at hand at the header field value, and trust what it gives them. As such, using JSON is a bit of an attractive nuisance. It may be that we can specify a profile of JSON that is safe to use, **and** create a set of easy-to-use libraries and get them into the relevant server-side platforms, but that's a substantial amount of effort (any volunteers?), and the natural lag of many distros/platforms means that they might not be available for some time (leading people to use plain JSON parsers). The most serious issue is undoubtedly the number format. Perhaps cautioning against minting headers that use non-integer numbers would be a workable stopgap (although the temptation might be quite strong in some use cases). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-239065536 ----==_mimepart_57abf454937b9_447a3fcd91d532b813788c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Right. The pushback against doing something like this that I've heard = is that no matter what we say in the spec, people are going to just point= the JSON parser they have at hand at the header field value, and trust w= hat it gives them.

As such, using JSON is a bit of an attractive nuisance.

It may be that we can specify a profile of JSON that is safe to use, <= strong>and create a set of easy-to-use libraries and get them in= to the relevant server-side platforms, but that's a substantial amount of= effort (any volunteers?), and the natural lag of many distros/platforms = means that they might not be available for some time (leading people to u= se plain JSON parsers).

The most serious issue is undoubtedly the number format. Perhaps cauti= oning against minting headers that use non-integer numbers would be a wor= kable stopgap (although the temptation might be quite strong in some use = cases).

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57abf454937b9_447a3fcd91d532b813788c-- From nobody Wed Aug 10 21:55:03 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 10 Aug 2016 21:55:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470891300; bh=mS6jtTb0MsCzboFWwvks0EzsIXKg0/X4jF4eC6FBOA8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UvVvcfE8IfTdX+u3stkwamwcmA8lgUEBHR/Emx0DmoPZWTRy5XDhJtNGlPFMR8ZQ1 iB/06UfV9My9WrpnE+kC0hZ94wbIGg0JPOeQuc2M35gBxza4L1tDJxnFrk6cAKuRMs FAAydLRrLa4vQ9aNpQzY/fh/vZL1srxl0xBqmsEE= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57ac05247a488_73423f9ab3f772bc753742"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 04:55:02 -0000 ----==_mimepart_57ac05247a488_73423f9ab3f772bc753742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Strongly warning seems reasonable. I'm not aware of any existing efforts that are planning to use non-integer values + JFV, but making that a requirement doesn't feel right either. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-239073939 ----==_mimepart_57ac05247a488_73423f9ab3f772bc753742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Strongly warning seems reasonable. I'm not aware of any existing efforts that are planning to use non-integer values + JFV, but making that a requirement doesn't feel right either.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57ac05247a488_73423f9ab3f772bc753742-- From nobody Thu Aug 11 11:32:38 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 11 Aug 2016 11:32:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470940355; bh=azDF9KoXtyY6cP8cVX9iYFy37jwYgyQVucT/NlirJ5k=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tG60gOd5NLsDIAzCQHHu/ndqwaI9UHJZgtQ54FaGfQUxgPB912hGzxwroeU41JjqJ H//6jeRXu8BIvFs7c5xU/1xs59DDW/z2Xsk/YeUu2Z72dWRqe5cAocGCDj8WfOWC0i Fm/Z3g/qYcVIlN+HaL6kDwIHXopfuh/3srQWJL/E= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57acc4c3bed9_6b0a3fd5cfbaf2b810526e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 18:32:37 -0000 ----==_mimepart_57acc4c3bed9_6b0a3fd5cfbaf2b810526e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit A JSON profile, strict modes, wrapper API suggestions, and/or strong warnings simply document attack vectors without solving the underlying problem. If JSON is the answer, then it comes with a "fuzzy numbers" problem that does not have reliable solutions. You can sugar-coat it or hope that it will go away in 20 years, but you cannot solve it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-239249809 ----==_mimepart_57acc4c3bed9_6b0a3fd5cfbaf2b810526e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A JSON profile, strict modes, wrapper API suggestions, and/or strong w= arnings simply document attack vectors without solving the underlying pro= blem. If JSON is the answer, then it comes with a "fuzzy numbers" problem= that does not have reliable solutions. You can sugar-coat it or hope tha= t it will go away in 20 years, but you cannot solve it.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57acc4c3bed9_6b0a3fd5cfbaf2b810526e-- From nobody Thu Aug 11 17:37:24 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 11 Aug 2016 17:37:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470962240; bh=sO2MqCMqVjxJzF3Laam4IE820bfoAHe+HD69YPgmagM=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=orC3HBWr+k1WjkhH9iYkqmVhSMqZ3yS2zDmfmZopCG9ejQVcu3hdsDjQg+2ka13So f0fRW9nlQbMLCfyCLCFo+Ztt1K5IvgeBa3a2Cm/X2H6ggDc6gcAheDvR/WsaGOujKx WD+fDVjULPGgJDOBIgg9Nrll6ala47WStyoQG054= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57ad1a40d61c2_3b4c3fdde7d912a0402516"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 00:37:23 -0000 ----==_mimepart_57ad1a40d61c2_3b4c3fdde7d912a0402516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @igrigorik @mnot If we are to going to use a modified variant of JSON, I strongly support disallowing non-integer numbers. Using ECMA262's definition of number would not help us, neither in terms of the definition or the ease of implementation. Regarding the definition, my understanding is that ECMA262 merely specifies how the numbers should look like as strings, but does _not_ specify _how_ the strings should be converted to IEEE754 numbers. Lack of a formal definition of such procedure is what leads us to disagreements between the implementation (that in turn becomes a cradle of vulnerabilities). Regarding the ease of implementation, ECMA262 is a _superset_ of JSON in terms of how numbers can be represented (i.e. binary, octal and hexadecimal representations), which seems unnecessary complex to me. @mnot > It may be that we can specify a profile of JSON that is safe to use, and create a set of easy-to-use libraries and get them into the relevant server-side platforms, but that's a substantial amount of effort (any volunteers?) It _might_ be possible to filter out JSON containing floating point representations _before_ applying a JSON parser, and in that regard, using [json2.js](https://github.com/douglascrockford/JSON-js) (that uses `eval` to parse JSON after filtering out dangerous strings) as a basis might be worth considering. I anticipate that just modifying the number representation in [this regexp](https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L163) would be sufficient for the matter. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-239333849 ----==_mimepart_57ad1a40d61c2_3b4c3fdde7d912a0402516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@igrig= orik @mnot=
If we are to going to use a modified variant of JSON, I strongly support = disallowing non-integer numbers.

Using ECMA262's definition of number would not help us, neither in ter= ms of the definition or the ease of implementation.

Regarding the definition, my understanding is that ECMA262 merely spec= ifies how the numbers should look like as strings, but does not = specify how the strings should be converted to IEEE754 numbers. = Lack of a formal definition of such procedure is what leads us to disagre= ements between the implementation (that in turn becomes a cradle of vulne= rabilities).

Regarding the ease of implementation, ECMA262 is a superset o= f JSON in terms of how numbers can be represented (i.e. binary, octal and= hexadecimal representations), which seems unnecessary complex to me.

=

@mnot <= /p>

It may be that we can specify a profile of JSON that is safe to use, a= nd create a set of easy-to-use libraries and get them into the relevant s= erver-side platforms, but that's a substantial amount of effort (any volu= nteers?)

It might be possible to filter out JSON containing floating p= oint representations before applying a JSON parser, and in that = regard, using jso= n2.js (that uses eval to parse JSON after filtering out = dangerous strings) as a basis might be worth considering. I anticipate th= at just modifying the number representation in this regexp w= ould be sufficient for the matter.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57ad1a40d61c2_3b4c3fdde7d912a0402516-- From nobody Mon Aug 15 11:59:45 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 15 Aug 2016 11:59:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471287580; bh=WG7iwwF2qNEayi50DhuX6ZhHJ/f3eBxh9yP8tHygmMg=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=u8YmE4UqKjM4pEYqfH+zU5xMmxeV/d4p1NqwS6pbzWekbbEWUjx8yeMKYnh7DJ7Xd iWLdLHaVzTJsJxJgV5OpiW/pmckzZaGMBG4PkFacjlgYh1THH5sBkh/UZVw6CoBta6 wrfbaVcSVu+xlbufFs34qWW2L74gl+/lnPrekuks= To: httpwg/http-extensions Subject: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b2111beb4c8_cc43fa19240d29c407350"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:59:44 -0000 ----==_mimepart_57b2111beb4c8_cc43fa19240d29c407350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unless I'm misreading the spec, it seems like lax same-site cookies will = only be sent for top-level browsing contexts. `` creates an auxiliary context. As far as I know, the initiator doesn't get any additional information fr= om a `_blank` link, so this restriction seems unnecessary. +@mikewest = -- = You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226= ----==_mimepart_57b2111beb4c8_cc43fa19240d29c407350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Unless I'm misreading the spec, it seems like lax same-site cookies wi= ll only be sent for top-level browsing contexts. <a href=3D"=E2=80= =A6" target=3D"_blank"> creates an auxiliary context.

As far as I know, the initiator doesn't get any additional information= from a _blank link, so this restriction seems unnecessary.<= /p>

+@mikew= est

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_57b2111beb4c8_cc43fa19240d29c407350-- From nobody Mon Aug 15 17:26:07 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 15 Aug 2016 17:26:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471307163; bh=nCxBfHnq70hmmdpv16G0RCeayPd51/TdjoX/5fUrTeo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=USrdAmcfQAITjldnwhbUus16eNyJqr9fQbpyHDh/pQy7LOIYVxy7uoAjz4nSDEa2H dP0eNgTbpZlGzkFHV5JusmYbHdsf2MWpWykhUBV/ZxJ9YTjXQEfbosfGCD5Tb0adsF EbkwpgTtSrdV8SPJ48PUhsrmyOjPHsnNhzqDc0ys= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b25d9b78844_71553fb66daf329c269112"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 00:26:06 -0000 ----==_mimepart_57b25d9b78844_71553fb66daf329c269112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Parallel thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/thread.html#msg436 @rousskov I appreciate where you're coming from, but (personally, at least) I think that paints an overly black and white prognosis. I think we _could_ make reasonable progress here with a restricted set + browsers enforcement. @kazuho @mnot I can't shake the feeling that restricting to integer values will come back to bite us, but if you think otherwise.. *shrug*, we can give it a shot. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-239969028 ----==_mimepart_57b25d9b78844_71553fb66daf329c269112 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Parallel thread: https://lists.w3.org/Archives/Publ= ic/ietf-http-wg/2016JulSep/thread.html#msg436

@roussk= ov I appreciate where you're coming from, but (personally, at least) = I think that paints an overly black and white prognosis. I think we c= ould make reasonable progress here with a restricted set + browsers = enforcement.

@kazuho @mnot I= can't shake the feeling that restricting to integer values will come bac= k to bite us, but if you think otherwise.. shrug, we can give it= a shot.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b25d9b78844_71553fb66daf329c269112-- From nobody Tue Aug 16 03:36:48 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 03:36:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471343802; bh=sETobNcONXzJiC8B/7S9jIRS2/WOy567UVwPrFnzdiE=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uZpev/IoRYG/tBxv1/HY+F/u/H+4BCceuDYlgAyYLh+2vX8Mw/7Lt5c1NMuQFEuIC 7xlL+GO110O0ek5to92IuHTxSz0Iie6mKGOLxrMcTKxzhNfYFCAzQ/47hvj2ttJN7u QeX6M4G99X5UW5atEs6JNrVYM8kKU9T5DhOMmeZ0= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b2ecba882f4_16d23f87f86a12a04536c5"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 10:36:47 -0000 ----==_mimepart_57b2ecba882f4_16d23f87f86a12a04536c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ughhh, you're right, I missed that detail. That means lax cookies will be sent on a `window.open` load, which will leak some timing through the window proxy. It's it worth tweaking to avoid that? I'm looking for ways to allow cookies on top level navigations unless another origin has access to the window proxy (`window.open`, iframes). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240066597 ----==_mimepart_57b2ecba882f4_16d23f87f86a12a04536c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ughhh, you're right, I missed that detail.

That means lax cookies will be sent on a window.open load= , which will leak some timing through the window proxy. It's it worth twe= aking to avoid that?

I'm looking for ways to allow cookies on top level navigations unless = another origin has access to the window proxy (window.open, = iframes).

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b2ecba882f4_16d23f87f86a12a04536c5-- From nobody Tue Aug 16 04:00:14 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 04:00:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471345211; bh=oQgZD1huG+boIU3PJe0gqsCwR9yDpXSO02zAKyeoOHU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yvJpkgcAv36/RzIzE19lStGXJ7b1re8XSL1UbMJrFzdU7ieFq0NUo1Mi0xAdLC78A ZGZCQ8i9PWnTz/pWqJnL8ZIDhpCB1fgCl9aCazbZUd/MNaSTHeR/yvYW6tXbOz+TtQ j2tfR4jEezoQWCV4ftNdBgwagGl9eDEcJJfGVPN4= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b2f23b90d38_23243fc89dd0f2a055026"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 11:00:14 -0000 ----==_mimepart_57b2f23b90d38_23243fc89dd0f2a055026 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > That means lax cookies will be sent on a window.open load, which will leak some timing through the window proxy. It's it worth tweaking to avoid that? Use `SameSite=strict`? I'm not sure I see the value of complicating this even further with `Lax`, `SomewhatLessLax`, and `Strict`. What timing detail leaks through `window.open`? I'm not familiar enough with the various holes we've bored into things at this point... > I'm looking for ways to allow cookies on top level navigations unless another origin has access to the window proxy (window.open, iframes). `Lax` takes care of the latter, as I'm sure you're aware. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240070949 ----==_mimepart_57b2f23b90d38_23243fc89dd0f2a055026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That means lax cookies will be sent on a window.open load, which will = leak some timing through the window proxy. It's it worth tweaking to avoi= d that?

Use SameSite=3Dstrict? I'm not sure I see the value of co= mplicating this even further with Lax, SomewhatLessLax= , and Strict.

What timing detail leaks through window.open? I'm not fam= iliar enough with the various holes we've bored into things at this point= ...

I'm looking for ways to allow cookies on top level navigations unless = another origin has access to the window proxy (window.open, iframes).

=

Lax takes care of the latter, as I'm sure you're aware.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b2f49fb5744_7c003fc323b4d2c0118246-- From nobody Tue Aug 16 04:17:28 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 04:17:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471346243; bh=tjSwtGJEMjCQCTKm3PmZX14jWK1Rfmh3Hi8z2c7/x8E=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=m0werNjmFHGbALpybErkVAh5gCaK11qe08uiy16azAC3SqV+WTFQCltsKoiDvlhBj 90e7SEll3ngjx2sSGtxlPK9b+dIvek79fwCt+zQb6JdTIy/J7VZfi/IlZWQ+sWM8yZ JAZm45oM5k47Y4eOS9jXbpO9tQ4DN3AWdDhemYPE= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b2f643d5914_22fa3fc89dd0f2a03014c9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 11:17:27 -0000 ----==_mimepart_57b2f643d5914_22fa3fc89dd0f2a03014c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I guess I don't understand how "allowing developers to prevent cross-origin credentialed requests" can be the answer, while at the same time "losing cookies on navigation seems harsh and breaking". > How widely deployed are same-site cookies? Is it too late to tweak the lax behaviour? What is it that you'd like to change? If we're going to make changes, now seems like the right time. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240073987 ----==_mimepart_57b2f643d5914_22fa3fc89dd0f2a03014c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I guess I don't understand how "allowing developers to prevent cross-o= rigin credentialed requests" can be the answer, while at the same time "l= osing cookies on navigation seems harsh and breaking".

How widely deployed are same-site cookies? Is it too late to tweak the= lax behaviour?

What is it that you'd like to change? If we're going to make changes, = now seems like the right time.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b2f643d5914_22fa3fc89dd0f2a03014c9-- From nobody Tue Aug 16 04:34:58 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 04:34:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471347293; bh=TKn73JEaAclz6N/LRcGU7nxoqhYlyU7bU9DI+bFDBiI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CIsJNDLdqDBc7Fn33neeIOiaR2thu3lJ3fs3uvJLHCR1IBDp+PRG0Qu1O7z36aIJR OPP8VrFGEb3Ja8k9fC9VOW/qi6Aq31RAZCXjl8s93pwjIods+Bz1ZK2hP4G3sYL40/ Ds41QvDL2o/KhcbmRNglZw8s3pe7JcYoYG/BUeMc= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b2fa5de6fda_5f713f80487ed29c2816db"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 11:34:57 -0000 ----==_mimepart_57b2fa5de6fda_5f713f80487ed29c2816db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > `.open` gives the initiator a load event. Alternatively, can we stop doing this? :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240076937 ----==_mimepart_57b2fa5de6fda_5f713f80487ed29c2816db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

.open gives the initiator a load event.

Alternatively, can we stop doing this? :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b2fa5de6fda_5f713f80487ed29c2816db-- From nobody Tue Aug 16 05:15:16 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 05:03:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471349020; bh=OJIaRpqHe9JiorQBh3gS5ffucyacgV9g6aHcNpRfDXs=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pbwQ5J2ZDJlltYKSQdMLA3W65Rb9BQkde0toQGO5xZ+V1XL2lfKbfv8/LFaollRE5 ApZ9RU8lblEKprry/TaaHd/zv2gutkfwDnnPOPcE6LSJFW2UDmtlvp69jJnp/Lrxmt nglBGIhFUR/9xHt3TVXK2xSAEVOoJxiocc1tXj5E= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b3011c4c0c4_6d453fbb0335d2b8216230"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:15:15 -0000 ----==_mimepart_57b3011c4c0c4_6d453fbb0335d2b8216230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > We were discussing stuff like that (and padding load times etc), but the worry is it's a hacky patch, and the information will be leaked somewhere else. With the understanding that this is the wrong bug for this discussion: if we feel like this is data that shouldn't be exposed cross-origin, then it seems like a better idea to find and plug the holes rather than creating an opt-in mechanism that folks who know what they're doing can use to protect themselves from things that shouldn't be possible in the first place. That is, ideally, we'd make the leak opt-in, not the seal. All that said, from a practical perspective we can probably change `Lax`'s behavior to exclude navigations caused by `window.open()` (and `clients.openWindow()`?). I'm a little concerned about both the layering and general confusion along the lines of "Hey, why am I not signed in?", though. How do you expect this to interact with `noopener`? Is it too confusing that the `disown-opener` directive is available only after the request is sent? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240082066 ----==_mimepart_57b3011c4c0c4_6d453fbb0335d2b8216230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We were discussing stuff like that (and padding load times etc), but t= he worry is it's a hacky patch, and the information will be leaked somewh= ere else.

With the understanding that this is the wrong bug for this discussion:= if we feel like this is data that shouldn't be exposed cross-origin, the= n it seems like a better idea to find and plug the holes rather than crea= ting an opt-in mechanism that folks who know what they're doing can use t= o protect themselves from things that shouldn't be possible in the first = place.

That is, ideally, we'd make the leak opt-in, not the seal.

How do you expect this to interact with noopener? Is it t= oo confusing that the disown-opener directive is available o= nly after the request is sent?

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b3011c4c0c4_6d453fbb0335d2b8216230-- From nobody Tue Aug 16 05:16:55 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 05:05:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471349153; bh=Au2jZlp5r4683Lfqclq2W2n0Rtw6Ho3YPvhz9TT0q8Q=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YB27a69OTnS8saCbgOdhZBMl9Mvv81Zbvmg0SVhGXl7b+FcmuIUlrgX9CKmss0p44 2tUS01DI/+YnjIRqtLlb33P5b6D/yHQfTg49BDsu+JVx/DOWvtQ0n9yNqXnh5FjnPH 8eUIwO6SNFU4gzkHWc4SsRn5OVzg24XdqMol2CZU= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b301a142ffb_6e023fbb0335d2b899662"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:16:55 -0000 ----==_mimepart_57b301a142ffb_6e023fbb0335d2b899662 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Also, +@annevk, as it seems like we should probably define something at the Fetch level regarding whether or not a given `request` exposes a handle. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240082538 ----==_mimepart_57b301a142ffb_6e023fbb0335d2b899662 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Also, +@annevk, as it seems like we should probably define something at the Fetch level regarding whether or not a given request exposes a handle.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b301a142ffb_6e023fbb0335d2b899662-- From nobody Tue Aug 16 05:48:17 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 05:48:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471351692; bh=sEM1WqF1GiSOSpRC0p9Ev7mVStcz1QzRkE2BrOKruUI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uDb6tF8WXF2yOSBUc/gF84E1zBBx2Cyb/f5gBMTsgqClR1FlMazQkt0M4B48IBMpR ST0MZ5dH+uXv3lzx6O8niVXDFCJJ6GVgzmzrW0nkowZnxFo2Nu2XldVfQnPi8r2foZ 7uqrk1+B1e3XS0on/BRXmvaU0FroAiifVDgMLqGU= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow (#226) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b30b8cacc5_6f2f3ffb415ad29c128574"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:48:16 -0000 ----==_mimepart_57b30b8cacc5_6f2f3ffb415ad29c128574 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > `clients.openWindow()` doesn't give you a handle to a cross-origin client, so cookies can be sent. I see. > It'd be great if the noopener option on window.open would allow cookies (you don't get load events then do you?). You don't get a handle to the window (`window.open` returns `null`: https://html.spec.whatwg.org/multipage/browsers.html#dom-open). > We've been encouraged to move away from "bandaid" solutions by @sleevi I think Ryan would agree that it would be better to stop cutting ourselves in the first place by removing features from the default set of things that we offer to developers if we can't build them safely. > which is why we're looking at opt-ins that tackle the root of the problem. Hrm. I think I disagree that opt-ins "tackle the root of the problem". They give developers who pay attention the ability to mitigate the effects of problems. That seems fundamentally different than making the platform sane in the first place. For instance, X years after introduction, ~52% of cookies are set over secure transport, but only 6% of cookies use the `secure` attribute (with all the same measurement caveats as above). I'd suggest that that attribute is rather heavily documented as a best-practice that folks should use unless they have a good reason not to. If solving timing attacks is actually important, then it seems like we're going to have to do significantly better than `secure` did to have any meaningful effect with an opt-in. Is that likely? We can't be aggressive enough about `SameSite` to make it opt-out without actually breaking the internet. I'm not sure that's the case with the various events and resource timing APIs we expose. I should probably be typing this on the other bug. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/226#issuecomment-240091227 ----==_mimepart_57b30b8cacc5_6f2f3ffb415ad29c128574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

clients.openWindow() doesn't give you a handle to a cross= -origin client, so cookies can be sent.

I see.

It'd be great if the noopener option on window.open would allow cookie= s (you don't get load events then do you?).

You don't get a handle to the window (window.open returns= null: https://html.spec.whatwg.org/multipage/browsers.html= #dom-open).

We've been encouraged to move away from "bandaid" solutions by @sleevi

I think Ryan would agree that it would be better to stop cutting ourse= lves in the first place by removing features from the default set of thin= gs that we offer to developers if we can't build them safely.

which is why we're looking at opt-ins that tackle the root of the prob= lem.

Hrm. I think I disagree that opt-ins "tackle the root of the problem".= They give developers who pay attention the ability to mitigate the effec= ts of problems. That seems fundamentally different than making the platfo= rm sane in the first place. For instance, X years after introduction, ~52= % of cookies are set over secure transport, but only 6% of cookies use th= e secure attribute (with all the same measurement caveats as= above). I'd suggest that that attribute is rather heavily documented as = a best-practice that folks should use unless they have a good reason not = to.

If solving timing attacks is actually important, then it seems like we= 're going to have to do significantly better than secure did= to have any meaningful effect with an opt-in. Is that likely?

We can't be aggressive enough about SameSite to make it o= pt-out without actually breaking the internet. I'm not sure that's the ca= se with the various events and resource timing APIs we expose.

I should probably be typing this on the other bug.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b30b8cacc5_6f2f3ffb415ad29c128574-- From nobody Tue Aug 16 11:06:35 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Tue, 16 Aug 2016 11:06:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471370788; bh=5/krM57HbqDNmN6//Ms+xmfuHQ6uKyA3dnPu4NT3HsQ=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Qzm4yCau/s8z1Rp5UYy4FKJOImbwnsWBxzAyLGi6bLfgREfqOLC/d7lZ6FU/a9rcy w4NIFNPHsqdfqTbvCEGNC4CuqA7ecoquJeJsWkHdncKEn+T77VPzGPs53GQbbOXCGh CHxJBsMFw4a6zVIjrBB3zfkMBZT06JQcPL/oaaGM= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b3562416334_2f23f954fb2f2b83992b1"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 18:06:34 -0000 ----==_mimepart_57b3562416334_2f23f954fb2f2b83992b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @igrigorik I agree -- _reasonable progress_ is very possible, for some definition of reasonable, especially if your primary focus is "browsers". That reasonable progress will not solve the problem -- fuzzy JSON numbers will cause CVEs. If reasonable progress [with browsers] is good enough, and a few design-triggered CVEs are not important enough, then this JSON problem is not a big deal at all. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/225#issuecomment-240187136 ----==_mimepart_57b3562416334_2f23f954fb2f2b83992b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@igrig= orik I agree -- reasonable progress is very possible, for so= me definition of reasonable, especially if your primary focus is "browser= s". That reasonable progress will not solve the problem -- fuzzy JSON num= bers will cause CVEs. If reasonable progress [with browsers] is good enou= gh, and a few design-triggered CVEs are not important enough, then this J= SON problem is not a big deal at all.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b3562416334_2f23f954fb2f2b83992b1-- From nobody Wed Aug 17 14:04:54 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 17 Aug 2016 14:04:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471467886; bh=jWLlEoVx9Dus+kxeVB8lksw8QKo+HrcrP6x3D3+YdCo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=owfmicZXnO+KxqrsD+C8YMHXvzlf27cp0F8QhFHVzx9YHIm3rKP3lconGO7N8fjOS BbI1Jkxql2eS5Qs3S7QlqWrC/Got86OZtv2powvWlkxNzWtu6GX472SLFifdV/+J4B D9vDzy/MUY7xuZZUaxNopdUl1Yjjb7lFOfD6XhDg= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] httpbis-cookie-alone breaks backwards compat (#223) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b4d16e8235d_31d73fb896bf32c0255560"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:04:52 -0000 ----==_mimepart_57b4d16e8235d_31d73fb896bf32c0255560 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @mnot yeah, the order matching was what I had in mind. I have mixed feelings on abbreviation though. Part of P3P's challenges were due to it being cryptic. Other specs like CSP are not abbreviating too much. But DNT/TSV are. Would it be better to assume widespread HTTP/2 adoption and count on header compression? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/223#issuecomment-240547908 ----==_mimepart_57b4d16e8235d_31d73fb896bf32c0255560 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@mnot y= eah, the order matching was what I had in mind. I have mixed feelings on= abbreviation though. Part of P3P's challenges were due to it being cryp= tic. Other specs like CSP are not abbreviating too much. But DNT/TSV ar= e. Would it be better to assume widespread HTTP/2 adoption and count on = header compression?

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b4d16e8235d_31d73fb896bf32c0255560-- From nobody Thu Aug 18 00:47:16 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 00:47:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471506432; bh=gLYQcrzKdgzGRxPUhYjWUlJlFX6z7rQkuiE4OTfAICY=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=j/naLV2Y8yyYqhqpwBTpvCscyjtB+t95ATvKGEi2s5zZfiyh9kGG2cSuishR63mcM 4XR20RzB5XkC6wFsJ+KhAJRddJpOem8DKz9hUtnmaR684ZvWYTm9ZeBetQMgiAeocF iuegLOabY5KRp8j4pQ5b/qPnyS3QpUjQEqsnYKTg= To: httpwg/http-extensions Subject: [httpwg/http-extensions] Advice for new parameters / headers (#227) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b5680013b60_7e8c3fd8aa60d13812197a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:47:15 -0000 ----==_mimepart_57b5680013b60_7e8c3fd8aa60d13812197a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As per recent discussion, this draft should advise readers about whether or not it should be used for new headers, or new parameters on existing headers. Straw-man: 1. Change the Abstract to: > RFC5987 defines an encoding for non-ASCII payloads in HTTP header field value parameters, based upon the encoding defined in RFC2231. This document updates that definition and describes how it should (and should not) be used. 2. Change the first paragraph of Introduction to: > By default, header field values in HTTP messages ([RFC7230]) cannot directly carry characters outside the US-ASCII coded character set ([RFC0020]). RFC 2231 ([RFC2231]) defines an encoding mechanism for use in MIME headers. This specification documents a subset of that encoding that has been used in some HTTP header fields. Its use in new header fields, or new parameters on existing header fields, is NOT RECOMMENDED. 3. Remove section 4 contents (and subsections), replace with: > The convention defined by this specification allows a parameter fields that have two possible encodings (ASCII without the `*`, UTF-8 with it). This causes considerable complication in the use and implementation of those parameters, since they now have to handle both, and all of the possible permutations and edge conditions implied by this (e.g., how a header field value with both ought to be handled). > Furthermore, this encoding can only be used in parameter values, not in other parts of header field values. > As a result, use of this encoding is only RECOMMENDED where already defined; new header fields, as well as new parameters on existing header fields, SHOULD NOT use it when non-ASCII content is anticipated. Instead, they SHOULD mandate a character encoding of UTF-8, combined with escaping of non-ASCII characters using a well-defined convention (e.g., percent encoding, as per [RFC3986). 4. Optionally, move the existing contents of section 4 into an appendix, but clarify that they're there merely for the benefit of existing uses. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/227 ----==_mimepart_57b5680013b60_7e8c3fd8aa60d13812197a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

As per recent discussion, this draft should advise readers about whether or not it should be used for new headers, or new parameters on existing headers.

Straw-man:

  1. Change the Abstract to:

RFC5987 defines an encoding for non-ASCII payloads in HTTP header field value parameters, based upon the encoding defined in RFC2231. This document updates that definition and describes how it should (and should not) be used.

  1. Change the first paragraph of Introduction to:

By default, header field values in HTTP messages ([RFC7230]) cannot directly carry characters outside the US-ASCII coded character set ([RFC0020]). RFC 2231 ([RFC2231]) defines an encoding mechanism for use in MIME headers. This specification documents a subset of that encoding that has been used in some HTTP header fields. Its use in new header fields, or new parameters on existing header fields, is NOT RECOMMENDED.

  1. Remove section 4 contents (and subsections), replace with:

The convention defined by this specification allows a parameter fields that have two possible encodings (ASCII without the *, UTF-8 with it). This causes considerable complication in the use and implementation of those parameters, since they now have to handle both, and all of the possible permutations and edge conditions implied by this (e.g., how a header field value with both ought to be handled).
Furthermore, this encoding can only be used in parameter values, not in other parts of header field values.
As a result, use of this encoding is only RECOMMENDED where already defined; new header fields, as well as new parameters on existing header fields, SHOULD NOT use it when non-ASCII content is anticipated. Instead, they SHOULD mandate a character encoding of UTF-8, combined with escaping of non-ASCII characters using a well-defined convention (e.g., percent encoding, as per [RFC3986).

  1. Optionally, move the existing contents of section 4 into an appendix, but clarify that they're there merely for the benefit of existing uses.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b5680013b60_7e8c3fd8aa60d13812197a-- From nobody Thu Aug 18 01:27:05 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 01:27:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471508821; bh=iLRdRtY3mPKdLxlWEz3UnrCWHxeV2fKpE4H4xh1UcnE=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iPh5rTTWQ2nLJAvQ3wfOZ1ofkFaEdsMcywZfq/S7uSUqaWpaHbm9gUZAwssf0k26d QYPV+/D7nQiOUWSsThXdWY5fZMje65KBhX7upo99PrmqzYkh+3NbCY1NOcJTPO/S5z B/LLxytrwYaWhZrXhvntRAHuL12Jincrdq9zrDFc= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] httpbis-cookie-alone breaks backwards compat (#223) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b571557a2a7_39cc3f880954b2a025709a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 08:27:04 -0000 ----==_mimepart_57b571557a2a7_39cc3f880954b2a025709a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit SGTM. Who's taking it to the list? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/223#issuecomment-240657138 ----==_mimepart_57b571557a2a7_39cc3f880954b2a025709a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

SGTM. Who's taking it to the list?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b571557a2a7_39cc3f880954b2a025709a-- From nobody Thu Aug 18 02:22:19 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 02:22:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471512133; bh=LWag/U+qAq1lke1lrfleA/obpz+l/v9K/Vfe3zoCL1k=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WAJGmxt4UmbrfxGqemxE30MSgNq3Gv2WL4gsXPEK+qSX9r+ExDWQR840Zf9kPGiD+ Mk8zmT3QcwvwRa2uAzS8lzsSbL0UhV+TUF6pPVBkB0t/wDYl/EfAgqlozIrGkargmZ mSarkJn4/PDer+G9rTR8zfXJdc4oQxH6gSwu6Z2c= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Add flags and Origin Set concept (f8803f0) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b57e45a2472_1b313fe4c20512c086479e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 09:22:18 -0000 ----==_mimepart_57b57e45a2472_1b313fe4c20512c086479e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Is it an error to include both flags, or a noop? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/commit/f8803f06c92efe20e165c5c0a99a1ef4b1dcf807#commitcomment-18686389 ----==_mimepart_57b57e45a2472_1b313fe4c20512c086479e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Is it an error to include both flags, or a noop?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b57e45a2472_1b313fe4c20512c086479e-- From nobody Thu Aug 18 02:25:18 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 02:25:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471512313; bh=p+AmKi89TiZF8qI0G/rap+q6Cpse2vlTV7742YclXts=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ptDpT7eF2cIyKnac4jJmRkPhQbpOGOriklIwW49wjFl1iJYuA0MdaVVDVjZ3vW6jz TCo7tsiLr+Gxi3OTj3rIq394MwHyFz/o+MqvqoGHKVgxWgW73LjBza8kqn+9xflJDR ATAUtv2IKqh+yREXazEuffA47u6k3cMG/fwsINdw= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Add flags and Origin Set concept (f8803f0) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b57ef928201_50433fdf684fb2bc1158352"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 09:25:15 -0000 ----==_mimepart_57b57ef928201_50433fdf684fb2bc1158352 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit s/It MUST occur/The ORIGIN frame MUST be sent/ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/commit/f8803f06c92efe20e165c5c0a99a1ef4b1dcf807#commitcomment-18686439 ----==_mimepart_57b57ef928201_50433fdf684fb2bc1158352 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

s/It MUST occur/The ORIGIN frame MUST be sent/

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b57ef928201_50433fdf684fb2bc1158352-- From nobody Thu Aug 18 02:26:18 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 02:26:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471512374; bh=bg1uVfyatfyy80cDIzk77im3rF1cNEFphFTBIkLyn3Q=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cuklcxdJfr1ULDYcda4vrPo9grSnJAN0SVuVl99qC6Hb9buNZjT9loKvW9BPV0tVv lQuWOYMJ7zkt5/7E1ZQU2oFhOgeU1RMmb5QQ5YO3fX0GXTIZLbQf9/bbb2BdP89DNp FjCBg3nDBvpiZ/cICvveWz/tYz33qaIJsXQ8ngSA= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Add flags and Origin Set concept (f8803f0) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b57f3665cea_6d323fac6f3232b81428dd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 09:26:17 -0000 ----==_mimepart_57b57f3665cea_6d323fac6f3232b81428dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I would split into a separate paragraph after the first sentence. The first sentence is about streams, the rest is about intermediation. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/commit/f8803f06c92efe20e165c5c0a99a1ef4b1dcf807#commitcomment-18686449 ----==_mimepart_57b57f3665cea_6d323fac6f3232b81428dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I would split into a separate paragraph after the first sentence. The first sentence is about streams, the rest is about intermediation.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b57f3665cea_6d323fac6f3232b81428dd-- From nobody Thu Aug 18 02:29:26 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 02:29:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471512561; bh=8oCa5IWGoDFLbLcfQ5vIpqf4kQ3Jmjp6CUn/ju8fk+w=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1VoN5M9dJV+txPlFobKWneR9N9o54Ndpn+ZCxCCqbRp/fPWGhouhCW6V2UYtOje0J DPmgBZfRRsG0doQtPx5FKWt2VuI9TtTHLBnOla01V7hAthyQFHXhQG+PWOU2BzS0Ot zEIpVBnWJRQZK77iyDmhyHuFq9HMXBdqYIDRletE= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Add flags and Origin Set concept (f8803f0) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b57ff135fdd_39193f880954b2a013887e9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 09:29:23 -0000 ----==_mimepart_57b57ff135fdd_39193f880954b2a013887e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This syntax doesn't work properly as a nested list. I don't know the incantation here, but maybe it either needs more indent or line breaks between lines (or maybe lowercase alpha numbers aren't detected as numbers). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/commit/f8803f06c92efe20e165c5c0a99a1ef4b1dcf807#commitcomment-18686479 ----==_mimepart_57b57ff135fdd_39193f880954b2a013887e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This syntax doesn't work properly as a nested list. I don't know the = incantation here, but maybe it either needs more indent or line breaks be= tween lines (or maybe lowercase alpha numbers aren't detected as numbers)= .

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_57b57ff135fdd_39193f880954b2a013887e9-- From nobody Thu Aug 18 03:02:44 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 03:02:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471514559; bh=BHp8EfY1I1MlZQ6LhghiKysX2sRqF7edArKZMIuTKdk=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EI1xQznh0wmfh97L2zrmzBGe7E+kRnEIaIZ310RRhjYNC0ImsBqY5xE3xHHpH8mn7 iBmuqC0VwNi4io2LS2XuXzEQCCnBElRnRnJlicJmln67Io84cxwueY++3t50sNALkI aNjFfFiXJjAkNUMAmTElSG6I5qa7Ib1gAEZXJP4A= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Add flags and Origin Set concept (f8803f0) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b587bf1f895_21ce3fafc4a772a025778f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 10:02:44 -0000 ----==_mimepart_57b587bf1f895_21ce3fafc4a772a025778f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Well, by the algorithm, you'll end up with an empty set, so it's functionally equivalent to just CLEAR. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/commit/f8803f06c92efe20e165c5c0a99a1ef4b1dcf807#commitcomment-18686956 ----==_mimepart_57b587bf1f895_21ce3fafc4a772a025778f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Well, by the algorithm, you'll end up with an empty set, so it's functionally equivalent to just CLEAR.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b587bf1f895_21ce3fafc4a772a025778f-- From nobody Thu Aug 18 21:57:44 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 21:57:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471582659; bh=/SK6lOtqI+AauT4rNi9p+9LnjZGXSGOX9ngcynlZxg8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DCOov60owEnbaYjkmwLKhvJ4MmTlUexsKGnm8xzjz+u0plY1wz1vo2XmhVpIwvE5H qKw5JKWdF7LVxe6cTAE4CQOlm9UV6hr5mKr9lQPXSjqyhD4xQhyDmh1+RS9S6NaP8/ Yzp4HFWbbGD5JbBWP3gA2AeCH/GJZaoxIl2RQAtI= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] normative reference to "key" spec (#200) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b691c34b1ff_3c843f92d78ab2a0144142"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 04:57:42 -0000 ----==_mimepart_57b691c34b1ff_3c843f92d78ab2a0144142 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #200 via ae713a857d6657da1e9340e084314e2a5186b78c. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/200#event-760825638 ----==_mimepart_57b691c34b1ff_3c843f92d78ab2a0144142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #200 via ae713a8.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b691c34b1ff_3c843f92d78ab2a0144142-- From nobody Thu Aug 18 21:57:48 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Thu, 18 Aug 2016 21:57:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471582659; bh=JHffkWhZPm/yDPxVenj8S1IlpGZYyDhF4WTMMrho3W4=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xdRMk9X557dEm9SrdYX7JnVSqaGRpTtCrM3Dtuc3WNZY1vlQCfGK0Mdq1qVgF/KWR 6x7SYj9kab5gHAP0BFmhQOSL48jKetDDUwuv4xgvJwHLbVymRa0w+jJHVEcbDRzlBa 15dCvwe6eFxJTFSRC0GQu4AQm4k5K6BVXue/Kfu4= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] security considerations regarding tracking (#215) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b691c34ad7e_12e93fc753a412bc13156"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 04:57:43 -0000 ----==_mimepart_57b691c34ad7e_12e93fc753a412bc13156 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #215 via ae713a857d6657da1e9340e084314e2a5186b78c. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/215#event-760825639 ----==_mimepart_57b691c34ad7e_12e93fc753a412bc13156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #215 via ae713a8.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b691c34ad7e_12e93fc753a412bc13156-- From nobody Fri Aug 19 17:08:33 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 19 Aug 2016 17:08:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471651710; bh=UYO2+cLBqqAz0VnGdH6WQq5lSFG1uGa65Z6G7vbRGk4=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BtAJIICjwhq6ZRSsMAanfBd0XAS2L6uwOWsAv/QUDdqpWA3ZPbSd/3Aiz8oQL1mmy ArHNFQ6cR7S0YsyvA/S6kslgIGJ+UwTrgUkKKxQeUeLoeR0cLGo0ouyuOV85FrAvOU vALRyG85n8VpSN2FgCKoaC3jieZ+QpLYEnnjWxpU= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] httpbis-cookie-alone breaks backwards compat (#223) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b79f7e235ae_37163fd8e47f92a0144727"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 00:08:32 -0000 ----==_mimepart_57b79f7e235ae_37163fd8e47f92a0144727 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I too, have concerns about the non-exact path matching and the asymmetry of the results depending on the order in which differing-path cookies are set. A similar concern about symmetry: why should secure sites get a free pass to downgrade a secure cookie to insecure? That's not "leaving secure cookies alone". Such an attempt might actually just be a site bug. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/223#issuecomment-241163996 ----==_mimepart_57b79f7e235ae_37163fd8e47f92a0144727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I too, have concerns about the non-exact path matching and the asymmet= ry of the results depending on the order in which differing-path cookies = are set.

A similar concern about symmetry: why should secure sites get a free p= ass to downgrade a secure cookie to insecure? That's not "leaving secure = cookies alone". Such an attempt might actually just be a site bug.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
----==_mimepart_57b7abdbbbf09_17aa3ffbacf6d2bc9725-- From nobody Fri Aug 19 18:01:53 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 19 Aug 2016 18:01:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471654910; bh=Qw+XrsyJ2JNE2753c1/MqVfdAxQz70rnqVpB2o89rGc=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=CgmJE4GireBU0ch5TjTlV/8eiZFSJiyQ0833DlltUc8q/0zDwqVhCdNCjyEttQagI ixHYySFGU7H/PZ4V+5SPoy5iBYe/tydDugD/RjNFPXRv6cQlQz2Dey2GEibVXDvt8x J+EiB6nD0H2dp04hAEF/pwI5RxZG2VmQMbUMZKrg= To: httpwg/http-extensions Subject: [httpwg/http-extensions] Server opt-in (#229) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b7abfe14f6e_641b3f85be24529c1214c6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 01:01:52 -0000 ----==_mimepart_57b7abfe14f6e_641b3f85be24529c1214c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Some mechanism to note that the server wants CD would be goo.d -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/229 ----==_mimepart_57b7abfe14f6e_641b3f85be24529c1214c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Some mechanism to note that the server wants CD would be goo.d

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_57b7abfe14f6e_641b3f85be24529c1214c6-- From nobody Fri Aug 19 18:17:43 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 19 Aug 2016 18:17:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471655860; bh=KWfeJqJu+D/uJUgKklgIyvNWg8FlLD/AAVSmk7wZS18=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QoO4iN0IZv+j3QM3dhm5CjObJzjOd970Pz07vl8JgcDYQg/qljWadFUTassnA98lV zoLW6dehZmgGMBi94SIvmk5Q6BxaAgMV1ZaNU42fs7DD7YwkJRt4XUWwC6rDIciAM2 3KXXHCcwYBP+mWkbzcxt/X1SpboSBpMqrL8nmYj0= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Wildcard names (#178) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b7afb49f697_711d3fb41915b2bc454df"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 01:17:43 -0000 ----==_mimepart_57b7afb49f697_711d3fb41915b2bc454df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit See recent changes; they define the origin(s) that the connection is authoritative for as the starting Origin Set -- including wildcard certs. This doesn't allow a wildcard cert to be added; e.g., if Mike's certs draft eventually allows you to add a wildcard cert to the connection, you'd have to enumerate each origin covered by the wildcard to get them into the origin set. So, the remaining question is whether we want to allow wildcards into the origin syntax itself. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/178#issuecomment-241169317 ----==_mimepart_57b7afb49f697_711d3fb41915b2bc454df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

See recent changes; they define the origin(s) that the connection is a= uthoritative for as the starting Origin Set -- including wildcard certs.<= /p>

This doesn't allow a wildcard cert to be added; e.g., if Mike's certs = draft eventually allows you to add a wildcard cert to the connection, you= 'd have to enumerate each origin covered by the wildcard to get them into= the origin set.

So, the remaining question is whether we want to allow wildcards into = the origin syntax itself.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b7afb49f697_711d3fb41915b2bc454df-- From nobody Sat Aug 20 13:53:11 2016 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sat, 20 Aug 2016 13:53:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471726387; bh=6XuxIK2KOgsYXYgs+5U3lc9tFmvkfplTeMykXxfGG/8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BsIQWyz/CW+AU9pGiO8ISQA2TEc1IKBa7osMcIdIdkQOqnHQr4VsLHIE3Bjsld5pB EGlFjuEfrIFUNxz2bKEclaaL5lz9XKgvX/pfCwJ9QE7w8GFeNuUara233CTP2uhnfO Vbx0JM7ARTX5d4JvXhr5qI57thgKaYFiQ2R38XMs= To: httpwg/http-extensions In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cache digest and scoping (#216) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b8c3336348b_52593f8c97bef2b82845e4"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.17 Reply-To: http-issues@ietf.org List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 20:53:10 -0000 ----==_mimepart_57b8c3336348b_52593f8c97bef2b82845e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @mnot > Having said that, there's nothing that stops a client from sending multiple cache digests on a connection, one for each origin that the connection is authoritative for. If this needs to be clarified in the draft we can certainly do that. I think CACHE_DIGEST frame should designate its scope explicitly, considering the fact that drafts that changes the scope of the authority exists (e.g. ORIGIN frame , secondary certificates), and that we have `COMPLETE` flag (that indicates a digest covering all the authorties have been sent). Otherwise, there'd be a race condition. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/216#issuecomment-241223097 ----==_mimepart_57b8c3336348b_52593f8c97bef2b82845e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@mnot <= /p>

Having said that, there's nothing that stops a client from sending mul= tiple cache digests on a connection, one for each origin that the connect= ion is authoritative for. If this needs to be clarified in the draft we c= an certainly do that.

I think CACHE_DIGEST frame should designate its scope explicitly, cons= idering the fact that drafts that changes the scope of the authority exis= ts (e.g. ORIGIN frame , secondary certificates), and that we have C= OMPLETE flag (that indicates a digest covering all the authorties = have been sent).

Otherwise, there'd be a race condition.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_57b8c3336348b_52593f8c97bef2b82845e4--

All that said, from a practical perspective we can probably change Lax's behavior to exclude navigations caused by window.op= en() (and clients.openWindow()?). I'm a little concer= ned about both the layering and general confusion along the lines of "Hey= , why am I not signed in?", though.