On Fri, 10 Nov 2023 at 17:29, Yoav Weiss <yoavwe...@chromium.org> wrote:
Thanks David!
It's great to see that this will be disabled in modes where we
*know* the machine is shared.
Fergal - could you address concerns about web developer advice?
What should we tell web developers to do on their logout pages?
Yes, we are in discussion with dev-rel about this. They were already
looking at producing advice for auth best practices. We will ensure
that this is covered in that,
F
On Fri, Nov 10, 2023 at 8:37 AM David Dworken
<ddwor...@google.com> wrote:
Chiming in to say that we discussed the security concerns
around this proposal quite extensively internally and overall
we believe that with the short timeout, the security risks
are acceptable. The residual security risk is for servers
that implement purely server-side logouts and is only
exploitable for a very short period of time (3 minutes). In
addition, other mitigations like this one
<https://bugs.chromium.org/p/chromium/issues/detail?id=1468438> further
reduce the risk such that we believe it is unlikely that this
will lead to new security issues.
On Friday, October 13, 2023 at 7:14:46 AM UTC-7
vmp...@chromium.org wrote:
On Fri, Oct 13, 2023 at 12:00 AM 'Fergal Daly' via
blink-dev <blin...@chromium.org> wrote:
On Thu, 12 Oct 2023 at 23:05, Yoav Weiss
<yoav...@chromium.org> wrote:
On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin
<vmp...@chromium.org> wrote:
Are there any spec changes planned for this
feature? I'm not sure if the README linked
under Specification is meant to make it into
WHATWG, maybe to close out
https://github.com/whatwg/html/issues/7189
The only spec I could find about CCNS is
https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5,
so I'm not sure how to reconcile possibly
contradicting language in the specs
Great questions! Fergal - can you answer that?
RFC9111 is about HTTP caches. BFCache is not a HTTP
cache, so RFC 9111 does not apply. Of course the
reality of implementations and expectations vs spec
is a problem. Some more discussion here
<https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#current-interactions-between-bfcache-and-ccns>
I'm not sure I agree with this, or the reasoning in the
link. First of all, this intent thread is
about ignoring CCNS in _some cases_. In other cases, CCNS
is respected, so it seems like BFCache is de facto
subject to RFC 9111.
This is, I guess, a bit philosophical but the spec says:
the cache MUST NOT intentionally store the information in
non-volatile storage and MUST make a best-effort attempt
to remove the information from volatile storage as
promptly as possible after forwarding it.
Note that the spec here does not make any exceptions for
things like cookie state not changing or anything else.
The document when frozen is indeed a volatile storage of
the server response, processed and stored in some
particular format (ie the DOM tree). I admit it's a bit
weird to think about it this way, since the live document
is technically also this cache. Whereas I agree that
BFCache is not strictly an HTTP Cache, I don't quite
follow why CCNS should not apply to the BFCache in some
cases.
To me, BFCache seems like "a better http cache" which
already has rendered results, not a completely separate
cache that is not subject to CCNS.
But I'm late to the game, and I see that the topic of
"BFCache is not HTTP Cache" has already been discussed a
lot. I'm not convinced by existing arguments, but I also
don't think I'll be able to convince anyone of my position.
My problem with the consensus in
https://github.com/whatwg/html/issues/5744 is the
following. People seem to agree that we don't want a
*new* api that specifically prevents pages from entering
BFCache. I don't believe it's appropriate to draw a
conclusion that there is consensus that BFCache should
not be subject to any *existing* APIs that prevent pages
from entering it. This might be true independently, but I
don't think one follows from the other. To quote this
comment
<https://github.com/whatwg/html/issues/5744#issuecomment-811958634>:
"... And what is the problem with the bank case? I'd
expect bank may want to ensure its page doesn't enter
bfcache, or any other cache, by using no-store (and
other) header(s) or something ..."
That comment sounds to me like "the status quo is good
enough, because there are already ways of preventing any
cache, including bfcache." If we were to claim consensus
on doing this work, I'd personally want to see a more
explicit "let's make it so pages still enter BFCache
despite CCNS in these cases." The comment from cdumez you
quoted is good, but maybe following-up there is worthwhile.
I concede though that I'm by no means an expert here, so
I don't want to block moving this forward any longer. I
just want to say that it's typically easy to be fast if
you show stale data, and shifting the blame to the site
for using CCNS instead of refreshing needed content in
script doesn't seem appropriate. I personally would not
want to be the judge of whether CCNS use is appropriate
or not since I don't know what "appropriate" is in this case.
BFCache and cases where it can/can't be used are
specced in the HTML standard. We have had very little
engagement from other vendors on this particular idea
but Safari tried to cache all CCNS pages in the past.
I am hoping that if we demonstrate a way to cache
some of them safely, they would be on board. Also any
browser is free to be *more* conservative than the
spec while still staying in-spec as BFCaching at all
is always optional.
Here
<https://github.com/whatwg/html/issues/5744#issuecomment-661997090>
is cdumez of Safari
Safari / WebKit shipped with all pages going into
the bfcache no matter what (including
cache-control: no-store). The only push back we
received was the fact that after you log out of a
site, you could still go back and see a page you
should no longer be able to see. We agreed that
this feedback was valid and our short-term fix
was to bypass the bfcache when the page uses
cache-control: no-store. Sadly, many sites use
this and their intention is likely not to prevent
the bfcache. This is not something we like for
the long term.
F
Also, Vlad previously asked about the recommended
pattern for folks to handle credential revocation
with BFCache and his concerns with the snippet
suggested upthread. It'd be great to address that.
Thanks!
vmpstr
On Thu, Oct 12, 2023 at 2:32 AM Yoav Weiss
<yoav...@chromium.org> wrote:
I just discussed this with Fergal offline:
* The risky scenario is one where
revocation of sensitive info (logout,
access revoked) happens on the
server-side only without a
client-side update.
* In such a scenario on a shared
computer, someone could back-button
their way into someone else's
sensitive info.
* It might be interesting to talk to
security folks (and maybe Project
Zero folks) to see if this is not
happening already with content that's
not CCNS decorated.
* It would be good to run a survey of
potentially-sensitive services and
try to get a signal from them on how
many of them are properly doing
revocation on the client side.
o I'd love ideas on how we can
scale such a survey beyond manual
inspection of a few known services.
* It could be interesting to try and
ship a version of this with a shorter
timeout, to minimize the risk of
users leaving the machine unattended.
o If we go that route, it'd be good
to think through how we'd be able
to increase that timeout over
time, after gaining more
confidence that the risky
scenario isn't happening in the wild.
On Thu, Oct 5, 2023 at 2:36 AM Jason
Robbins <jrob...@google.com> wrote:
At this morning's API Owners meeting,
they asked me to add all review gate
types to all of the "web developer
facing code change" features that are
currently under review, including
this one. So, I have added Privacy,
Security, Enterprise, Debuggability,
and Testing gates to your feature entry.
Please click the gate chips in the
"Prepare to ship" stage on your
feature detail page. For each one,
answer survey questions and request
that of the cross-functional review.
You can request them all in
parallel. In cases where you already
have the go/launch
<https://goto.google.com/launch> bit
approved, you can note that in a
comment on that gate for a
potentially faster review.
Thanks,
jason!
On Monday, October 2, 2023 at
9:09:18 AM UTC-7 Jason Robbins wrote:
On Friday, September 29, 2023 at
1:01:54 PM UTC-7 Chris Harrelson
wrote:
Please also make sure to
complete all of the other
shipping gate reviews
<https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ>.
I think a bug in ChromeStatus may
have caused some confusion on
this feature entry. The feature
entry has type "Web developer
facing code change", so its
bilnk-dev thread should have had
subject line prefix "Web-facing
change PSA" rather than "Intent
to ship". And, according to the
launching-features doc
<https://www.chromium.org/blink/launching-features/#psa-prepare-to-ship>,
it does not require any
approvals, which is why there are
no other gates offered in the
ChromeStatus UI. A fix for that
subject-line prefix bug should go
live today.
Of course, the point of a PSA is
to allow concerns to be raised
and I see that this is a very
active thread. So, all that
should be worked through. Its a
mater of the the API Owners
prerogative to request any other
reviews that they think are
appropriate, but it is not
automatically required by the
process for this feature type.
Also, I see that the launch entry
<https://launch.corp.google.com/launch/4251651>
had some approvals.
Thanks,
jason!
--
You received this message because you are
subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email
to blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUszpq%3DS%3DOZ4k_GnopJMRcTnL_trq5iF8J-kAzeYEiqKA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUszpq%3DS%3DOZ4k_GnopJMRcTnL_trq5iF8J-kAzeYEiqKA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed
to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkA5eFwcvRsTAZhy728KFaBjd5W5EZpP2%3DMmC42ngMUuQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkA5eFwcvRsTAZhy728KFaBjd5W5EZpP2%3DMmC42ngMUuQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
