安装 Steam
登录
|
语言
繁體中文(繁体中文)
日本語(日语)
한국어(韩语)
ไทย(泰语)
български(保加利亚语)
Čeština(捷克语)
Dansk(丹麦语)
Deutsch(德语)
English(英语)
Español-España(西班牙语 - 西班牙)
Español - Latinoamérica(西班牙语 - 拉丁美洲)
Ελληνικά(希腊语)
Français(法语)
Italiano(意大利语)
Bahasa Indonesia(印度尼西亚语)
Magyar(匈牙利语)
Nederlands(荷兰语)
Norsk(挪威语)
Polski(波兰语)
Português(葡萄牙语 - 葡萄牙)
Português-Brasil(葡萄牙语 - 巴西)
Română(罗马尼亚语)
Русский(俄语)
Suomi(芬兰语)
Svenska(瑞典语)
Türkçe(土耳其语)
Tiếng Việt(越南语)
Українська(乌克兰语)
报告翻译问题
If you're having layout problems then delete the browser cache from settings, that could be a bunked up CSS file.
In Task Manager:
- Image Name : steamwebhelper.exe
- Description : Steam Client WebHelper
steamwebhelper is the Steam client window(s) & background processes.
For some reason I have 9 of them right now, plus steam.exe *32
Let's see...
- Client Window on the forums,
- Friends panel,
- Chat window,
- livestream that finished (just closed & re-opened the Client Window to get rid of the livestream and now I have 8 webhelpers),
- background service for receiving software updates,
- background service for receiving notifications & chat messages,
...no idea what the other 3 are for.
THey give you random webhelper things.
Steam is based on Chromium.
So, that's what Chrome does too.
They don't really do much of anything at all.
It's different subprocesses.
The OP is right about one thing though:
it would be better to open payment pages in the OS default browser or to ensure the embedded browser components are more like stock current versions of the actual browsers.
With emphasis on current.
Because the version of Chromium that Steam currently embeds is 20 major versions behind; 2 years old; and has a known security vulnerability that allows bypassing the same origin policies and which might be used to steal cookies or other forms of locally stored data protected by the origin/domain boundary. And they're still casually using that to send you on your merry way to a payment provider.
This chronic lack of updates is endemic with applications using embedded browser engines; and is one of the reasons that has led to several entities in several industries, notably representatives being big-tech; finance; and healthcare, to shift to the assumption of taking insecurity and compromise of in-app browsers as their default state and thus deeming them unfit for purpose.
There are several payment systems already which expressly forbid merchants from using in-app browsers to start payments. Contracting with the rights-holders of those systems to offer payment service through them requires that applications delegate to the OS default browser.
E.g. the iDeal platform operating in the Netherlands is one such system. Technically, Valve failing to delegate payment flow to the OS default browser, but instead continuing to offer iDeal payments directly via the in-app embedded Chromium browser, is a breach of contract.
Specifically for iDeal, the problem is actually bigger than a contractual technicality as well. iDeal is a system which delegates payment authorization to the e-banking portals of individual banks. And some of those banks have (rightfully) started to add protection against offering services on in-app browsers as well, and will basically door-slam on them intentionally.
In practice, this means some customers are unable to finish iDeal payments -- and will never be able to recover and finish those payments -- when started through the Steam client. They have to log in to the Steam website with their regular browser and also start the checkout-flow and payment flow through that, for it to ever be able to succeed.
iirc, you can already buy things through the browser instead of the client but I don't think that switching to default browser should be default or mandatory. The user should simply get a warning & be provided the option to switch or continue here, instead of being required to.
Better still if Steam gave you the option to input a specific browser into the settings to open things up with, instead of using the default browser - for people who have multiple browsers and might prefer to use the different ones for different purposes.
Current-day browsers all install with automatic update settings enabled by default and running in the background without needing to prompt users for permission to update. That's a far, far better guarantee to keep them evergreen than having to rely on the whims of whatever application developer has to manually opt in to incorporating an updated version of the embedded browser engine they're using and then distribute an application update for it.
Proof is in the pudding:
Valve updates the Steam client multiple times each month, but is still 20 major versions behind and stuck on a 2-year old known-to-be-vulnerable version of Chromium.
The fact that they are still 20 versions behind has been reported to them in the Steam Client Beta forum. Multiple times. Also in the actual Bug Reports sub-forum. It has been at least a month since those reports started to be filed and threads started appearing.
They are still 20 versions behind and vulnerable.
I have a large amount of respect for user choice and would generally agree with this sentiment, except - as I mentioned before - several payment systems will simply cease to work for in-app browsers, refusing service intentionally.
Giving users this choice also implies users will need to be aware of whether they are affected or not. Not only that - but if they get that decision wrong, it means they're stuck with a pending payment and you're loading them with the additional burden of resolving that as well.
Aside from those concerns, there's really only one way such a suggested warning could look like. Valve very well aren't going to shoot themselves in the foot with a message that states: "Steam's embedded browser is deemed a security-hazard by some payment providers, so we are offering you the choice to continue checkout and payment in your default browser instead."
Instead, it'd be something more like the current interstitial warning page when clicking links on the forum, that continuing payment outside of Steam means you're leaving the safety of Steam's protective embrace. I.e. it'd be scare-mongering users into continuing to use the option which in actuality is more likely to be unsafe and might, in light of what I wrote earlier with respect to payment providers refusing service to in-app browsers, not even work for them any more at all.
Recommend a user proceed with a third-party browser that is up to date and then offer a button to open the transaction page & proceed in the default browser.
It should be up to the user to make their own informed decision with the ability to make it automatically managed by another program if they want.
The end user typically either takes whatever recommendation is thrown their way, without questioning it, or will otherwise know the flaws in their unique configuration better than application developers will.
That's simple.
Simply forbid transactions be made using those providers through the in-app client then.
This could be included in the recommendation message - something like,
"We recommend you proceed with your purchase via an up to date web-browser, for security purposes. Additionally, if you plan to pay via iDeal, then you are required to proceed via browser.
Click this button if you would like to switch to your default web browser to continue with purchase :
Some people are only paying via wallet code & account funds, though.
Maybe they have a very good reason not to be using those builds, but it'd have to be a really good reason.
Because I'm pretty sure that's been the case for years.
THat they constantly update it themselves.
It's been documented here.
Then it makes absolutely no sense that they still have release notes which contain items noting Chromium was updated to a stated official build number.
All I know is it's well documented they have updated the version they have.
It's simple, really: If Valve actually keep their own custom fork of CEF and Chromium; and if they keep that up to date with upstream improvements themselves; then it would not make sense for Valve to use the official build numbers of official Chromium builds in Steam Client release notes stating things like:
https://store.steampowered.com/oldnews/143476
Which is an official build number that you can find here:
https://github.com/chromium/chromium/tree/85.0.4183.121
tagged on Sep 19, 2020.
Which is the last of such messages that could be found in the Steam Client release notes.
I.e. can be taken to be the current version they are still using now.
Also; I'm pretty sure Valve does - in fact - not keep their own fork; or if they do then at the very least they crucially fail at keeping it properly up to date.
I just used the Steam client's built-in browser to perform a payment through aforementioned iDeal and my bank's e-banking portal, which had several pieces of UI that were broken. (Long live resilience of the web platform; the payment could still be completed - it was just a visual mess.)
But I dug into that a bit by opening my bank's sign-in portal in my regular browser and pulling up the browser developer tools to look at things. As I already suspected: the bank's portal is using some HTML/CSS material that is available in all browsers that matter nowadays, but wouldn't have been available in Chromium ca. Sep 2020.
And that's why the layout is broken in the Steam Client embedded browser. Because it is, in fact, still using that 2 year old Chromium without 2 years worth of improvements and bug fixes. Pray then, that Valve at least back ports security patches, and does that properly.
But no; Occam's Razor would have that the simplest explanation is the correct one:
They're just using a stock Chromium, which is simply woefully outdated.
I get the feeling this is one of those myths where someone basically just made it up out of whole cloth, people started repeating it, and then finally believing it was true because it was repeated so many times.