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

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLksQWQ0WCfYVF47PxKTkRpkC955tfTD%3DE6T8Ccidm41PA%40mail.gmail.com.

Reply via email to