Thanks Sasha!
TL;DR: I think we've got enough information here to make a decision. You've
been *incredibly* *helpful* for that. What follows is my personal views,
not a decision, and I share them not to shut down the conversation, but
instead, to keep the conversation going and to continue to move us closer
to a conclusion :)
Speaking personally, I'd be worried about implementing this in Chromium.
You've been *incredibly* helpful here in helping understand, but I worry
this highlights a worrying lack of documentation here, as well as a lack of
holistic integration into the Web Platform. Extensions obviously have
incredible power and flexibility, and can "break" the assumptions of the
Web Platform in many ways, to both the delight (e.g. introducing new
features) and consternation (e.g. breaking existing features) of users. Yet
as extensions, it's also an area where it's "not our problem" to support.
That seems like I'm arguing we (Chromium) shouldn't do it because it means
more work for us, but that's not quite where I'm going. Rather, to
integrate this into Chromium means making sure Chromium developers have the
knowledge to understand and reason about how this will interact with the
Web Platform, how the Web Platform can co-evolve with features like this,
and how it fits overall into Chromium's 4 S's (Simplicity, Speed, Security,
Stability). In particular, I think as mmenke@ alluded to, this makes it
difficult to reason about privacy properties: for example, it means
clearing cookies in Chrome may no longer clear cookies, because these IDP
APIs may hold on to them. For things like the effort to safely partition
and isolate cookies, this means it's difficult to reason about how these
APIs behave in 1P vs 3P contexts. In terms of stability, this seems
intended to be an extensible platform, and thus potentially brings more 3P
code into whatever process implements this (the proposals, at present, are
for the browser process, due to network service sandboxing). When we think
about how potential 3P (non-MS) IdPs would use this API, it sounds like
that this would de facto mean that they'd need to use "x-ms-" as a prefix
for their headers, and that, similarly, there's a lack of way to feed back
in to the IdP the state of the user as to whether headers-or-cookies should
be used.
I appreciate Microsoft's attempt to provide some isolation for the Web from
their experimental headers ("x-"), but as RFC 6648 Section 3 highlights,
this doesn't really work in practice, and the use of "x-" headers doesn't
really prevent them from becoming de facto standards (as the previous
remark highlights).
My worry is that if directly implemented in Chromium, these all become
concerns Chromium needs to worry about, and Chromium needs to support and
address. We can't just remove a feature when it gets difficult, or there
isn't sufficient documentation, and while I'm not trying to suggest we can
arbitrarily break extensions either, we don't necessarily have to reason
about every extension's behaviour prior to making any changes to Chromium,
like we do need to do with Chromium features. For users, "Chromium is
broken", and there's not an option to point out that "no, the extension is
broken" as there is today.
I do worry that because this flow can only really be implemented in
conjunction with Windows (and WAM), it makes it easy for websites to
construct experiences that "Work best with Edge" or, if Chromium
implements, "Work best with Chromium". For example, if an internal website
required these assertions, then they would not work with Firefox - unless
the user installed the extension or unless Firefox also integrated with
Microsoft's proprietary APIs. While it's certainly true that an internal
website (or IdP) could provide a "fallback path" for a "less" secure
browser (i.e. one that doesn't provide TPM-bound cookies), I think
practical experience of enterprises in the past suggest that may be less
likely.
I'm very concerned that this sort of thing doesn't have a path towards
standardization or interoperability. I realize that, in part, this approach
to WAM is a reflection of the fact that Token Binding shared many of these
limitations, and we intentionally removed Token Binding precisely because
of its incompatibility with, and lack of explaininability with, the overall
Web Platform. This is conceptually similar in the challenges, but with even
less multi-stakeholder agreement or interoperable specification, and so
that does worry me. Similarly, I do worry that this favors a particular IdP
being able to offer both technical solutions and ease of use over those of
others, both because at least one IdP will always work "out of the box" on
some OSes, but also because the access to change those requirements as
needed (e.g. the shift from cookies to headers) that other IdPs can't
easily do.
But that's just my opinion, and I certainly wouldn't be the one to have
final say here, especially since I'm known for taking the most critical
view ;-) Despite Chromium's reputation within some circles for "shipping
early", and to the consternation or objections of other browsers, the
reality is both that Microsoft is already shipping this, and that this is
already possible, today, with Native Messaging and extensions. So websites
can, today, require the installation of the extension, and the friction
involved may not be meaningful to prevent network effects. Enterprises can
easily push extensions, so they can already deploy fleet wide and build
internal sites that are "Chromium only" (and, similarly, to support Firefox
through Firefox's WebExtension and native messaging). Similarly,
Enterprises can already prohibit other platforms and browsers from being
used for their internal sites, so perhaps this isn't the straw that breaks
the camel's back. Putting this in Chromium just makes it easy for
enterprises to get what they want, makes it easier for them to use more
browsers, and maybe that's worth the tradeoffs listed above. And there are
plenty of features we'd consider for Enterprises that have no place at all
in the Web Platform: in some ways, we let Enterprises break the Web however
they want, as long as it's only for their users. The clear alternative
would be reopening discussions about Token Binding, and that's a huge
investment to do so correctly (as shown by the 5+ year investment from
Chrome in unsuccessfully doing that), so perhaps this is the path to split
the difference, by de facto adopting Microsoft's since-shipped approach.
As you can see, while I'm personally not supportive, I can see clear
positives here. I think you've been incredibly helpful getting a good
understanding of what the request is, and I think it's certainly worth
considering and discussing! I don't think this discussion would have been
possible without your support and engagement, so while I'm somewhat
negative about the feature in its present form, this isn't a critique of
your engagement. Again, thank you, genuinely :)
On Thu, Oct 21, 2021 at 12:45 AM Sasha Tokarev <[email protected]>
wrote:
> Hi all,
>
>
>
> You are correct with respect to cookie size limit. Because there is a 4k
> limit for all cookies, when we introduced multiple accounts, we hit this
> limit and some proxies started to block our requests. That why we changed
> our cookies to headers.
>
>
>
> Right now, IProofOfPossessionCookieInfoManager::GetCookieInfoForUri can
> return either a list of cookies or a list of headers.
>
>
>
> GET
> https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=1fec8e78-bce4-4aaf-ab1b-5451cc387264&redirect_uri=ms-appx-web%3a%2f%2fMicrosoft.AAD.BrokerPlugin%2f1fec8e78-bce4-4aaf-ab1b-5451cc387264&resource=https%3a%2f%2fapi.spaces.skype.com&add_account=multiple&login_hint=aaa%40microsoft.com&response_mode=form_post&windows_api_version=2.0
> HTTP/1.1
>
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> Accept-Language: en-US
>
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.21329
>
> *x-ms-DeviceCredential: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI…*
>
> *x-ms-RefreshTokenCredential:
> eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9…*
>
> *x-ms-DeviceCredential1: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI…*
>
> *x-ms-RefreshTokenCredential1:
> eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9…*
>
>
>
> if the name of the cookie starts from x-ms- then this cookie should be
> added as a header, otherwise as a cookie, please, see attached example:
>
>
>
> if (_wcsnicmp(tokens[i].name, L"x-ms-", _countof(L"x-ms-"))
> == 0)
>
> {
>
> std::wcout << "Add as a header: \n\t" <<
> tokens[i].name << ": " << tokens[i].data << std::endl;
>
> }
>
> else
>
> {
>
> std::wcout << "Add as a cookie: \n\t" <<
> tokens[i].name << "==" << tokens[i].data << tokens[i].p3pHeader <<
> std::endl;
>
> std::wcout << "\tP3P: " << tokens[i].p3pHeader <<
> std::endl;
>
> std::wcout << "\tdwFlags for InternetSetCookieEx: "<<
> std::hex << tokens[i].flags<< std::endl;
>
> //
> https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetsetcookieexa
>
> }
>
>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* Ryan Sleevi [email protected]
> *Sent:* Tuesday, October 19, 2021 10:00 PM
> *To:* Sasha Tokarev [email protected]
> *Cc:* [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
>
>
>
>
> On Tue, Oct 19, 2021 at 9:41 PM Sasha Tokarev <[email protected]>
> wrote:
>
> *> All of this relates to the questions I was previously asking, because
> at least if my understanding is correct, this basically means that as
> currently designed, it's not possible to really describe a "standard" flow
> or specification. For example, it's not that a particular cookie value will
> be present, or a particular header value - the web account provider can
> return arbitrary cookies via the
> WebAccountProviderRetrieveCookiesOperation, and these should just be passed
> on to any of the managedUrls. So IdP Foo might call their cookie "SID",
> while IdP Bar might call their cookie "Token", and IdP Baz might use
> multiple cookies, like "CAW", "DIDC", and "DIDCL". The browser should just
> overwrite any cookies it has (e.g. from the browser cookie jar, or from
> extensions) with the cookies provided by the Web Account
> Provider/IProofOfPossessionCookieInfoManager - right?*
>
>
>
> -True, we tried to make IDP life easier, we wanted them to use any cookies
> names and semantic. Cookies are a private contract between IDP native
> component and IDP web service. We never pursued the goal to standardize
> this aspect.
>
>
>
> All we can spec for browser SSO on Windows:
>
> 1. Windows can have a native IDP component, which installed by the
> user or built-in in the platform.
> 2. There is a public API that any web browser can use to pull a list
> of cookies/headers when navigation happens to an IDP url.
> 3. Cookie/header names and their semantic is a private contract
> between an IDP web and its native component on the platform.
> 4. The web browser should just override cookies with the same names.
>
>
>
> I hope it clarifies.
>
>
>
> It really does, and helps understand how this is a very new, very
> different integration, and does affect some of the understanding of how
> this fits in the overall Web Platform and interop story (while being
> mindful of balancing that with our existing threat model)
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain%2Fdocs%2Fsecurity%2Ffaq.md%23Why-arent-physically_local-attacks-in-Chromes-threat-model&data=04%7C01%7Calextok%40microsoft.com%7Cd78230704f844cdd956608d9938685cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637703028293896522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bAM8ClzapvH4WnHIQUT0DHM%2BcFp2jE7M5l8BoJbmwRc%3D&reserved=0>
> .
>
>
>
> One question I had, that I forgot to follow-up on: with these APIs;
> whether WebAccountProviderRetrieveCookiesOperation or
> IProofOfPossessionCookieInfoManager::GetCookieInfoForUri, these deal with
> cookies. You mentioned headers a few times - could you provide any pointers
> to where the header interactions are / what the APIs? The context here that
> I'm thinking about is situations like cookie size limits and how these PoP
> cookies, which we don't know the size apriori, would interact with the
> browser cookie store. The use of headers mitigates some of that, although
> with their own complexities, and so it'd be useful to understand what that
> API shape looks like.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvb0FQmiwFSUHMNJvT2GXpAPk3wEkgifwLWna8ri3tPaTg%40mail.gmail.com.
