Issue metadata
Sign in to add a comment
|
Security: Enterprise ChromeOS OOBE page loads web URLs inside chrome:// process |
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Please provide a brief explanation of the security issue. src/chrome/browser/resources/chromeos/login/oobe_screen_eula.html is loaded as a chrome:// WebUI page but contains an "oem-eula-frame" iframe that loads content from the web for enterprise devices. According to alemate@, the web content is unrestricted and defined by the provider (and presumably may contain HTTP content that a MITM could modify, or links to untrusted content). This is a privilege escalation concern. The WebUI page uses a privileged renderer process, which has bindings that can be used for a sandbox escape (and is also granted the ability to navigate to any other chrome:// URL, which has been used in past sandbox escapes). If the web content loaded in this process exploits the renderer, this poses a large risk of sandbox escape. This includes content that may be injected by a MITM if HTTP pages are loaded inside this iframe. Note: We have plans to disallow web iframes inside WebUI pages in issue 683418 , which would likely prevent this attack but also break the intended flow here. The feature should likely use a GuestView instead, similar to chrome://signin. (Maybe msarda@ can point us to relevant code for signin to see how it's done?) VERSION Chrome Version: 59.0.3071.134 stable (and earlier), through 63.0.3227.0 (trunk) Operating System: ChromeOS enterprise devices REPRODUCTION CASE alemate@ may be able to provide repro steps for visiting this web iframe in the OOBE for enterprise devices; I have not seen it myself. Once loaded, the web URL could use any renderer exploit to take over the WebUI process. The OOBE process appears to have the ability to control many aspects of how the Chromebook is configured (login, network, etc), so this is likely dangerous to expose to attackers.
,
Oct 2 2017
CC'ing groby@ for WebUI context. msarda@: Can you point us to the signin webview code as an example of how to load web content in WebUI without iframes? alemate@: Will you have time to look at this, and can you share how to repro? It's a fairly serious issue for Chrome's security model. Thanks!
,
Oct 4 2017
CC'ing arthursonzogni@ to help with the investigation of a related issue 771382.
,
Oct 4 2017
Can someone share repro steps how one can load a 3rd party web page into the chrome://oobe page? I've tried to repro it on my ChromeOS device running M59 and on a ToT build of Chrome for ChromeOS and neither of the two have a CSP policy that allows me to load arbitrary web pages.
,
Oct 5 2017
I've poked a bit more at this and it might actually not be a problem. The chrome://oobe page is served with a CSP which prevents any pages other than chrome://terms/ and chrome-extension://mfffpogegjflfpflabcdkioaeobkgjik/ to commit in subframes. The latter is the extension id of the GaiaAuthExtension (https://cs.chromium.org/chromium/src/chrome/browser/resources/gaia_auth/manifest.json), so we aren't allowing any web pages to directly be embedded into chrome://oobe. As far as I know, the GAIA Auth extension uses <webview> tag to load 3rd party pages in a separate isolated process. It seems this is still the case by poking at https://cs.chromium.org/chromium/src/chrome/browser/resources/gaia_auth_host/authenticator.js?rcl=0dbd91831aa400e798248ad09f37cd64ced1d169&l=122, but I cannot confirm with authority. alemate@, can you help judge the correctness of the above analysis? If correct, then we don't have a security bug (yay!) and we already load web content in a safe way. At the very least, please reassign/cc anyone than can, as this is a high severity security bug and needs consistent progress.
,
Oct 5 2017
Assigning to xiyuan@, since alemate@ is not around. xiyuan@, can you help verify that we load all web content in chrome://oobe inside <webview>?
,
Oct 5 2017
For auth related, chrome://oobe has switched to use <webview>. Gaia and Saml IdP are all loaded inside the <webview>. So it is less a concern. The concern in #0 is about the eula page, which uses an iframe to load its contents. The iframe always loads chrome://terms. However, the contents of chrome://terms could be loaded from web [1] at kOnlineEulaURLPath (https://www.google.com/intl/%s/chrome/eula_text.html) [2]. [1] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/about_ui.cc?rcl=98c9b1d4fc903ab9dee06a98e7497b11de760449&l=216 [2] https://cs.chromium.org/chromium/src/chrome/common/url_constants.cc?rcl=98c9b1d4fc903ab9dee06a98e7497b11de760449&l=332
,
Oct 5 2017
To see the eula page, run chromeos chrome with --login-manager and a clean user data dir. If should be among the first few of screens. It is part of OOBE and user would only see it once. Would the fact that chrome://terms is serving an https makes it safe enough? If not, what are the options we have here? The eula contents could come from a local file or an URL. <webview> could not be used to serve chrome:// or file://. How should we handle the local file case?
,
Oct 5 2017
Comment 8: Thanks for elaborating. No, HTTPS is not safe enough. No web content should be loaded inside the WebUI process, given the privileges that process has. (We do not have enough guarantees on the content itself, or restrictions on where it can navigate, even if we ignore the risk of MITM.) For the local case, chrome://terms can indeed be served from an iframe, and the local file could be read into chrome://terms as a resource rather than a file:// URL. For the remote case, it seems like GuestView / <webview> is really the only safe option. (Even if we used an OOPIF for the content to keep it out of the WebUI process, the rest of the WebUI code is not designed to protect against unprivileged subframes within a privileged main frame. It would be too easy to have bindings or privileges leak to the OOPIF.)
,
Oct 5 2017
Sounds like we have to use both <iframe> and <webview>. <iframe> is used to serve chrome://terms but we change its source to only load the local contents. <webview> is used for the remote/URL content.
,
Oct 5 2017
Wow, I hadn't looked at the ChromeOSTermsHandler in about_ui.cc. This is different than I expected, and still concerning. That's a WebUI handler that's directly fetching content from the web and serving it to a chrome:// frame. Our checks in issue 683418 wouldn't catch that, and it's even more dangerous (since Chrome has no way to know not to grant WebUI bindings to the web content). Question: Is that approach how the third-party enterprise EULAs work as well? Could they load over HTTP and directly have WebUI bindings without a renderer exploit? We'll need to change the handler not to fetch web content for WebUI pages (and hopefully find a way to prevent that in the future). Comment 10: Yes, I think we may need separate approaches for local vs remote content. Thanks!
,
Oct 5 2017
xiyuan@: Can you elaborate on the repro steps? I'm not able to spot the EULA in the flow. Here's the command I'm using, based on what alemate@ shared with me. ./out/cros/chrome --login-manager --login-profile=user --user-data-dir=[...] --disable-setuid-sandbox --no-sandbox --remote-debugging-port=9999 I see a welcome page with a Let's Go button, then network selection, then signin, then I'm on the desktop.
,
Oct 5 2017
Re #12, sounds like you are running a chromium build. Eula page only shows up for official build.
,
Oct 5 2017
Comment 13: Oh, I see. I'm not able to do an official build, probably because I don't have src-internal checked out. I'm particularly concerned about comment 11. Can you confirm whether the third-party enterprise EULA pages are loaded via this same ChromeOSTermsHandler into the chrome://terms iframe itself?
,
Oct 6 2017
FWIW, I see the EULA as a second or third screen after following the instructions and using the flags from https://bugs.chromium.org/p/chromium/issues/detail?id=705295#c22 (with an official build), and I can inspect it on my desktop by going to https://localhost:<debugging_port>/. I do see chrome://oobe/oobe embedding the chrome://terms/ iframe, which contains the content fetched from the google URL. Interestingly, the chrome://terms/ has a CSP header: Content-Security-Policy:script-src chrome://resources 'self' 'unsafe-eval';object-src 'none';child-src 'none';
,
Oct 6 2017
Re #15: Can you clarify what "enterprise EULA pages" refers to? I am only aware of ChromeOS EULA and OEM EULA. Both are served from chrome://terms. OEM Eula is loaded from local fs, somewhere in /oem partition.
,
Oct 6 2017
Comment 17: Here's what alemate@ told me via email: "The tricky part is that oobe_eula (not exactly that iframe, but another one alike (search for [iframe id="oem-eula-frame"])) is used for public session licelce. In that case we are loading provider URL, i.e. it will be some external site URL." I think that partly answers my question in Comment 15-- hopefully it does not load as a chrome:// page itself, but rather as a web iframe within chrome://oobe. That's still bad (and it's the motivation for filing this bug), but it's not as bad as chrome://terms fetching its contents from the web via ChromeOSTermsHandler. I've just modified wizard_controller.cc in my local build to show the EULA even though I'm not an official build, and I've confirmed that the ChromeOSTermsHandler behavior is indeed very bad. The chrome://terms iframe has WebUI bindings and the content (served from the web) can access those bindings directly, without a renderer exploit. xiyuan@: Do you know how to set the "provider URL" for "oem-eula-frame" that alemate@ refers to? I'd like to verify locally whether that has the same WebUI binding problem, or if it would need a renderer exploit to use the WebUI privileges. (If it does have WebUI bindings, we may need to raise the severity of this bug to critical, since it would be a direct sandbox escape for web content.) Anyway, it seems like we'll need two fixes here: 1) ChromeOSTermsHandler should not put web content into chrome://terms directly, since that frame is privileged. If the content comes from the web, it should go into a GuestView. (If the content is local, it's fine to load it into chrome://terms directly.) 2) oem-eula-frame should not load provider URLs in an iframe of chrome://oobe. It should go into a GuestView.
,
Oct 6 2017
That is the TermsOfServiceScreen that we show for enterprise public session. The ToS content is fetched remotely [1]. Then stuffed into a <span> [2] via .textContent [3]. The only guard we have here is the textContent which should strip all <a> and scripts if the fetched content has them. [1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/screens/terms_of_service_screen.cc?rcl=e0875b0964f567478c9e469dc962ed5d651b61ea&l=92 [2]: https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.html?rcl=e0875b0964f567478c9e469dc962ed5d651b61ea&l=8 [3]: https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.js?rcl=e0875b0964f567478c9e469dc962ed5d651b61ea&l=44
,
Oct 6 2017
Comment 19: Thanks. How do I specify the URL for that in a local run, so I can test it? Also, I'm not sure I see the connection between the "tos-content-main" span in oobe_screen_terms_of_service.html and the "oem-eula-frame" iframe in oobe_screen_eula.html. Those sound like two different things.
,
Oct 6 2017
Re#20: Unfortunately, you can not run it locally. It is an enterprise feature and only works on a real device. You would need to enroll the device to some domain. Then enable public session for that domain and specify the ToS URL as the public session user policy. Wrapped a hacky CL: https://chromium-review.git.corp.google.com/c/chromium/src/+/706198 The CL would show the ToS screen on chrome --login-manager startup. I used a random gstatic URL. You can change it in terms_of_service_screen.cc. Only text/plain response is acceptable. Others would fall as a load error. Think this is relatively safe since we have restrict on the URL loader and use .textcontent.
,
Oct 10 2017
Proposed CL: https://chromium-review.googlesource.com/c/chromium/src/+/710738 Instead of using both iframe and webview, the CL only uses webview and load chrome://terms via XHR then set to webview as a data url. Let me know if that addresses the concerns here.
,
Oct 10 2017
Thanks for putting that together! Using webview for both local and remote cases sounds great. I'm happy to take a look at the CL tomorrow afternoon from a security perspective (since I'm OOO in the morning for a talk). Feel free to have another reviewer look in the meantime.
,
Oct 12 2017
CL in review here: https://chromium-review.googlesource.com/c/chromium/src/+/710738 I mentioned in my review that we probably want to avoid having chrome://terms fetch content from the web at all, and maybe just do an XHR for the content if possible. That avoids any risk of loading it with bindings. The terms of service <span> should probably also be addressed. I agree it's marginally safer because of .textContent, but I'm not very comfortable loading web content into a page with WebUI bindings. As for the "oem-eula-frame" in oobe_screen_eula.html, do you know if alemate@ was mistaken that it can fetch content from a provider's URL on the web? It looks like it might only be fetched from a file on disk, but I'd like to confirm. Thanks!
,
Oct 12 2017
Re #24: I can confirm that "oem-eula-frame" only loads a local file. The file is put under /oem parititon on the device. The actual file path is part of a json file handled by chromeos::StartupCustomizationDocument. The customization document is per oem customization id and fetched from gstatic. I will look at the two requests shortly.
,
Oct 12 2017
BTW, would removing the online Eual fetching from chrome://terms has legal issues? That is, do we have a legal reasons to always show a fresh terms content in that page?
,
Oct 12 2017
Comment 26: I can see how removing the online fetch would be simpler and safer if it's allowed, but you'd have to check with legal for whether it's ok. :) (I couldn't answer myself.)
,
Oct 13 2017
Another question: if we make chrome://terms to do a redirect to the online eula, either via window.location.href or meta http-equiv="refresh", would the renderer be swapped or drop webui bindings after the redirection?
,
Oct 13 2017
Comment 28: I'm not sure I understand the proposal. Would you still be fetching the content, putting it into a data URL, and loading it into a webview as your CL does today? And this redirect would be to help with the case that the user visits chrome://terms directly? My main concern with that is that it might break your current CL, since the code fetching the response to put into the data URL probably won't follow the client redirect, and I don't know if chrome:// pages can do server redirects. To answer your question, the redirect would cause a process swap if you loaded chrome://terms in the main frame. It would not work in an iframe (given the restriction we're adding in issue 683418 ). And there are no process swaps in webview tags, but we wouldn't be giving the webview process WebUI bindings anyway. Instead, would we be able to do an XHR or fetch for the network content from the JavaScript code in the CL? Then chrome://terms would only need to serve static content from disk and never go to the network itself. (Indeed, it seems a bit odd to have a network fetch inside about_ui.cc, when XHR or fetch seems like it could be easier to write.) We might not even need the chrome://terms handler at all, if the static content can be served as a chrome://resources file? Just brainstorming, anyway. I'm curious if something along those lines would work.
,
Oct 13 2017
The redirect proposal is to handle the stale chrome://terms in a tab case (if we need to). The concrete version is that if the online terms page is accessible, chrome://terms source would return a javascript or <meta> to redirect to the online Eual URL. So that if user opens chrome://terms in a tab, we would show the online version. The XHR idea does not work because server does not allow CORS. Got this: Failed to load https://www.google.com/intl/en-US/chrome/eula_text.html: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'chrome://oobe' is therefore not allowed access. OTOH, we don't actually need XHR since webview can load the URL directly. But this does not solve the stale chrome://terms problem. I would like get that cleared before going down this approach. Think we could replace with chrome://terms with chrome://resources if the chrome://terms URL itself is not important.
,
Oct 13 2017
> Think we could replace with chrome://terms with chrome://resources if the chrome://terms URL itself is not important. Take this line back because ChromeOS uses offline terms page outside of chrome resources. IDS_TERMS_HTML is a fallback when such offline terms page is not found. So chrome://terms is still needed, at least for chrmoeos.
,
Oct 16 2017
CC'ing halliwell@ for context.
,
Oct 18 2017
,
Oct 18 2017
CC'ing stevenjb@ for context.
,
Oct 18 2017
,
Oct 19 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368 commit c09ae9d1985365d1aa7455eb25e7a70c1bcfe368 Author: Xiyuan Xia <xiyuan@chromium.org> Date: Thu Oct 19 20:42:20 2017 cros: Use webview for Eula screen - Replace eula iframes with webview; - Load chrome://terms via XHR and set to webviews via data url to re-use existing online/local/oem terms loading code; - Get rid of padding for .eula-frame css class as webview looks good without it; - Move online terms loading from ChromeOSTermsHandler to Oobe Eula webui; - Re-write EulaTest since old tests are testing chrome://terms in a tab; - Move EulaTest from interactive_ui_tests to browser_tests since it no longer uses ui_test_utils::FindInPage; Bug: 770313 Test: Manual. Verify Eula screen works with MD/non-MD/language change. Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I2d90492958d0adae06a3e873942f2d3f534f7991 Reviewed-on: https://chromium-review.googlesource.com/710738 Reviewed-by: Charlie Reis <creis@chromium.org> Reviewed-by: Alexander Alekseev <alemate@chromium.org> Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#510197} [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/chromeos/login/eula_browsertest.cc [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe.js [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_eula.css [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_eula.html [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_eula.js [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_screen_eula.css [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_screen_eula.html [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/resources/chromeos/login/oobe_screen_eula.js [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/ui/webui/about_ui.cc [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/ui/webui/about_ui.h [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/ui/webui/chromeos/login/eula_screen_handler.cc [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/browser/ui/webui/chromeos/login/oobe_ui.cc [modify] https://crrev.com/c09ae9d1985365d1aa7455eb25e7a70c1bcfe368/chrome/test/BUILD.gn
,
Oct 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c2da6a66bc9bfdb07e4a2ec945b89aebe0926393 commit c2da6a66bc9bfdb07e4a2ec945b89aebe0926393 Author: Xiyuan Xia <xiyuan@chromium.org> Date: Mon Oct 23 20:20:02 2017 cros: Use Webview for public session ToS - Replace public session ToS <span> with <webview>; - Use data url to set the content of the ToS <webview>; - Adjust style to match previous implementation; Bug: 770313 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I4906ab84b713e0e89245843b4c5162cc534aa463 Reviewed-on: https://chromium-review.googlesource.com/731665 Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Reviewed-by: Achuith Bhandarkar <achuith@chromium.org> Cr-Commit-Position: refs/heads/master@{#510895} [modify] https://crrev.com/c2da6a66bc9bfdb07e4a2ec945b89aebe0926393/chrome/browser/chromeos/policy/device_local_account_browsertest.cc [modify] https://crrev.com/c2da6a66bc9bfdb07e4a2ec945b89aebe0926393/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.css [modify] https://crrev.com/c2da6a66bc9bfdb07e4a2ec945b89aebe0926393/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.html [modify] https://crrev.com/c2da6a66bc9bfdb07e4a2ec945b89aebe0926393/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.js
,
Oct 23 2017
,
Oct 23 2017
Thanks for working through this! r510197 seems like the more important of the two fixes. Do you think that's mergeable to M63?
,
Oct 23 2017
Yep, both could be merged cleanly for M63.
,
Oct 23 2017
+gkihumba to approve M63 merge.
,
Oct 24 2017
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 24 2017
josafat@, could you approve merge to M63?
,
Oct 24 2017
Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec commit 661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec Author: Xiyuan Xia <xiyuan@chromium.org> Date: Tue Oct 24 21:30:09 2017 Merge M63 "cros: Use webview for Eula screen" > - Replace eula iframes with webview; > - Load chrome://terms via XHR and set to webviews via data url > to re-use existing online/local/oem terms loading code; > - Get rid of padding for .eula-frame css class as webview looks > good without it; > - Move online terms loading from ChromeOSTermsHandler to Oobe > Eula webui; > - Re-write EulaTest since old tests are testing chrome://terms > in a tab; > - Move EulaTest from interactive_ui_tests to browser_tests since > it no longer uses ui_test_utils::FindInPage; > > Bug: 770313 > Test: Manual. Verify Eula screen works with MD/non-MD/language change. > Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation > Change-Id: I2d90492958d0adae06a3e873942f2d3f534f7991 > Reviewed-on: https://chromium-review.googlesource.com/710738 > Reviewed-by: Charlie Reis <creis@chromium.org> > Reviewed-by: Alexander Alekseev <alemate@chromium.org> > Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#510197}(cherry picked from commit c09ae9d1985365d1aa7455eb25e7a70c1bcfe368) Change-Id: I671e3d3a090ee1880159180178f448f255330115 Reviewed-on: https://chromium-review.googlesource.com/736037 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#192} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/chromeos/login/eula_browsertest.cc [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe.js [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_eula.css [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_eula.html [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_eula.js [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_screen_eula.css [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_screen_eula.html [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/resources/chromeos/login/oobe_screen_eula.js [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/ui/webui/about_ui.cc [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/ui/webui/about_ui.h [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/ui/webui/chromeos/login/eula_screen_handler.cc [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/browser/ui/webui/chromeos/login/oobe_ui.cc [modify] https://crrev.com/661b08ef5a676041649cacb0ed9fe7c1f8c1f9ec/chrome/test/BUILD.gn
,
Oct 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/82095d7c0cf9d341b234624e93fc3462ae1fbb1e commit 82095d7c0cf9d341b234624e93fc3462ae1fbb1e Author: Xiyuan Xia <xiyuan@chromium.org> Date: Tue Oct 24 21:31:57 2017 Merge M63 "cros: Use Webview for public session ToS" > - Replace public session ToS <span> with <webview>; > - Use data url to set the content of the ToS <webview>; > - Adjust style to match previous implementation; > > Bug: 770313 > Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation > Change-Id: I4906ab84b713e0e89245843b4c5162cc534aa463 > Reviewed-on: https://chromium-review.googlesource.com/731665 > Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> > Reviewed-by: Charlie Reis <creis@chromium.org> > Reviewed-by: Achuith Bhandarkar <achuith@chromium.org> > Cr-Commit-Position: refs/heads/master@{#510895} > (cherry picked from commit c2da6a66bc9bfdb07e4a2ec945b89aebe0926393) Change-Id: I4f39cd0a11c1ef7679d2edb0ff6ac064b4655540 Reviewed-on: https://chromium-review.googlesource.com/736430 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#193} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/82095d7c0cf9d341b234624e93fc3462ae1fbb1e/chrome/browser/chromeos/policy/device_local_account_browsertest.cc [modify] https://crrev.com/82095d7c0cf9d341b234624e93fc3462ae1fbb1e/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.css [modify] https://crrev.com/82095d7c0cf9d341b234624e93fc3462ae1fbb1e/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.html [modify] https://crrev.com/82095d7c0cf9d341b234624e93fc3462ae1fbb1e/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.js
,
Oct 25 2017
,
Dec 4 2017
,
Jan 30 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 27 2018
,
Apr 4 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by infe...@chromium.org
, Sep 30 2017