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?

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

Reply via email to