WebBrowser concerns!

[chrome bloom]

beep boop

[tardy marten]

Just to make it sure, we are talking about In-game browser, not Steam browser or something?

Gah yesh you said that

[chrome bloom]

Yes.

Its basically the browser from the steam overlay (using same steam API)
But integrated into a control, embedded into the game.

The browser itself runs inside the steam client, and just sends a screenshot to the game.

[tardy marten]

So the concept is input an URL via some SQF command, boom a browser is open and ready to show some fancy thing?

[chrome bloom]

Yeah.
You can also display it on an object, via ui2Texture.
Like https://silentspacemarine.com/

[sick isle]

what if that browser would only support html and nothing else

[chilly coral]

the browser should be able to handle lag and fails to connect so it wont overload arma

[chrome bloom]

The browser is basically doing nothing in the game.
Its all handled by Steam.

We send mouse/key inputs to steam. Steam sends back an image screenshot of the browser, we display the image in the game.

The steam API also limits what we can do. Cannot for example block javascript or iframes.

[toxic acorn]

Continuing discussion here: can mission makers be trusted to be smart enough to consider the safety of the websites they whitelist? Large mission makers probably can, but for example unit mission makers maybe not?

[tardy marten]

I somehow thought of, what about a local HTML that is stored in mission

[chrome bloom]

That is a thing, I already have "display a string" and then string contains html.

[tardy marten]

Oho. Now it does seem to be a good additional way to show something in-game

[chrome bloom]

True.
But unit mission makers building things for their unit. Probably won't throw malicious things into their players faces, or they'd quickly be out of the unit

[sick isle]

would this really be BI's problem if a mission maker was that stupid?

[chrome bloom]

Not really BI's problem, when "user created content" is bad. But also we could make doing bad things, much easier with this.
Should still consider the issues.

[toxic acorn]

Maybe not intentionally, rather I am thinking of a script kiddie compromising the website they use and mess with it. Sure it's not the end of the world if they just display explicit content or something, but is that the worst thing they can do? Could they steal cookies etc

[chrome bloom]

Worst thing they could do is what I want to find out.

The browser is running inside Steam. The only cookies present are your steam login, and they are only accessible from Steam websites, and also not even accessible from javascriot.
We've explicitly blocked steam website access for that reason.

[sick isle]

i mean, at the end of the day this could happen with any mission. like, if i made a popular mission that has the web feature, someone could try to hack that website used in the mission.

for example i would probably not use it in any cdlc content, because then i have a huge responsibility to make sure my linked website is secure at all times for realsies

[chrome bloom]

I am personally not very worried about malicious mission makers showing stuff like porn.
They can already just include a image or video in the mission file if they wanted to.

A mission displaying their own website, and that website getting hijacked to show bad stuff. Is a valid concern, but I would say that is out of our hands.

[chrome bloom]

Unless the displayed content is a .html file from inside your pbo.
I would make that possible some way.

The only concern I have in there is embedded iframe or javascript, inside that .html file could still do bad things.
But I can't come up with many ideas of bad things that would actually be bad-bad.

Again the argument, a malicious mod can already do bad things. There are a few more with this, but how much more?

[chilly coral]

what if some people use it for spam. like creating fake mission that only leads you to their site that is spam or games involving money or some illegal stuff, etc?

[chrome bloom]

They already can.

Say via script you open a message box.
And bind the "OK" button, to a malicious URL. And whitelist that malicious URL in your mission.

User starts mission, sees message box. Tries to click it away, malicious URL gets opened in steam overlay.

So mission makers, already can open any URL in browser that they want. Even without this feature.
It just won't be embedded inside the game.

[chilly coral]

oh ok, guess no way to prevent that then

[sick isle]

can i as a player open that browser but at the same time tell it to never run any scripts?

[chilly coral]

unless you require sites whitelisted by BI

[sick isle]

kinda makes the feature a bit lame, but more secure as well

[chrome bloom]

No, steam doesn't give us control over it.

We can run custom javascript in browser. But we cannot block it

[sick isle]

ok

i mean. at the end of the day there is always trust involved from players. personally i'd never allow it on a public mission-- but if you play with your group, chances for something bad to happen is probably very small

and as you said, if someone wants to do something bad, they kinda already can do it anyways

if i open that webbrowser from the mission file, can i send data to the website?

[chilly coral]

battleye verified sites =/

[sick isle]

i mean like variables or whatever

[chrome bloom]

Yes there is a "RunJavascript" API. SQF can send any javascript to the page and execute it

And the javascript inside the site, could communicate with some Server API

[sick isle]

i just had that idea... imagine someone making an actual AAN website, which on opening reads the current mission date and then filters the website content based on that date 😄

then there could be news posts and articles and stuff all depending on current ingame time 😄

you could implement it into any mission file and no matter when the mission takes place, that website would show fitting news and stuff 😄

could also filter based on terrain name

basically interactive arma timeline 😄

[toxic acorn]

I don't think we'll know if this is secure / a smart thing to do until it is implemented. You mostly know what bad this could do if you are a 'blackhat' and already have experience with Arma cheats / cheating in general, and I don't think that crowd hangs around on this server (and has any intentions of coming forth with any potential exploits they might use)

[chrome bloom]

Here is a list of all the things the steam API offers us.
We can:

• send keyboard/mouse inputs
• Get a screenshot of the current page (which we display in-game)
• set/get the currently open URL (Will be available to script, but with whitelist check)
• go forward/back and reload the page (Will be available to script)
• get notified when a web-page is tried to be loaded, and can approve/deny it (this is where whitelist check is done)
  • But this only applies to the actual root URL, the one your webbrowser would display in the top address bar. We can not control requests to embedded content (images, iframes, javascript) inside the page itself
  • Can probably also make this SQF eventhandler, but can't bypass whitelist ofc
• get notified when a file is tried to be opened(uploaded)/saved(downloaded) and can approve/deny. We automatically deny these.
• get notified when Javascript executes a alert()/confirm() which would normally open a dialog. We forward the dialog message string, into a SQF eventhandler. So this can be used to pass data from JS to SQF. The SQF then has to OK/Cancel the dialog, the browser is stuck until the request has been answered.
• set cookies. (Will not make this available to scripts, though Javascript can also set some cookies afaik)
• set HTTP request headers (Will not make this available to scripts)
• open the chrome developer console (scriptable)
• execute Javascript inside the currently open page (scriptable)
• trigger it to open notepad displaying the "Show source" of the current page (no purpose if we can just open developer tools)
• set DPI scaling and page zoom (scriptable)
• get the current page vertical/horizontal scroll and pixel size (scriptable)
• get notified when URL tries to be opened in new tab/window. We just ignore it, the new URL will not be opened.
• Get the current page's title
• Get status text (when hovering a link) and tooltip text
• Get clickable link at X,Y coordinates and read the URL on it

That is a complete list of what the API offers us.

[chrome bloom]

It will be in today's ( 🤞 ) dev-branch and profiling branch.
It will stay there in testing till we release 2.20.

I'm hoping some of the people who know how to do bad things with it, are in here

[sick isle]

the yes/no popup also shows up if you load a html from within the mission folder?

[chrome bloom]

I would say yes.
html in mission folder can do all the same things as a website, it just cannot be redirected elsewhere afterwards.

[sick isle]

event handler for that box would be good for sure

so we can detect if player accepted or declined

[chrome bloom]

You will have script command that tells you if the browser loading failed (because player refused, or because steam is broken).
Maybe also a way to force the popup to show (If the player previously selected "No - Always", and you want to re-ask them).

Because say you play something where it doesn't matter and you don't want it, so you disable it always. Then you enter a life server cinema, where you need it. And you need some way to allow it now.
But we would probably just show it in game options, so you could tell the player "Go into your options and change it there", that's better.

But you can still spam a popup telling them to go into game options (BIS_fnc_guiMessage). vs spamming a popup that directly lets them press yes.

[sick isle]

hehe annoy the player with popups so much that they give up and press yes

[chrome bloom]

Rude ping @balmy shuttle @tidal remnant for feedback #dev_rc_branch message

[mystic pine]

@ashen storm

It means BIKI can be navigated ingame, right?

a client side opt-out option could make sense (global/any, per mod, per mission, per url)

does stream browser accept 3rd party cookies? what about ads?

[chrome bloom]

yes

[chrome bloom]

Either we do global/permission. Or per-domain. Domain would be alot more work, and not easy to display it in ingame options screen.

[mystic pine]

what about network timeout or firewall influence (especially china/russia)? how is this working atm?

[chrome bloom]

Afaik yes. In steam overlay you can for example log-in to other websites. Haven't tested yet but surely that'll work.
ads, well its chrome webbrowser without any adblocker addon.

But, any key-press to a UI control, can be captured by SQF script. So logging in is not a good idea. Not sure how/if to communicate that to players. Probably not much we can do about that.

[chrome bloom]

Will work the same as steam overlay.
Local windows firewall wise the browser is inside the steam client (SteamWebHelper.exe I think).
Besides that it would work the same as a normal webbrowser

[mystic pine]

feature limited to missions, or also accessible in main/MP menu?

[sick isle]

main menu is just a mission as well, no?

bg i mean

[chrome bloom]

Anywhere where UI control is accessible.
menu works too, but then the whitelist needs to be in mod (Which you already do for htmlLoad displays in main menu, for example ACE does that afaik)

[mystic pine]

@sick isle
engine atm limits certain things to main/mp menu or the opposite - hence the question

[chrome bloom]

Of course, for security just blocking it in MP is also an option.
But IMO that'd make the feature basically useless as most things happen in MP

[daring stag]

Never tried this in the steam browser but I imagine it has audio. How would that be handled in arma? Or would that be non-existing?

[sick isle]

hm also if i show it on a monitor, is it synced for every player? 😄

[chrome bloom]

The audio is played from the steam client.
Sadly we have no control over it

[chrome bloom]

No, UI controls are local.
If you want some syncing, you would need to do it yourself via javascript

[chrome bloom]

For discussion purposes, making this a thread!

[fair egret]

a way to force the popup to appear sounds ripe for abuse imo - as lexx already said

[runic leaf]

Personally I wouldn't restrict too much. And since everything is based on a whitelist I think the best would be to be transparent with the user who is playing it and actually show him the whitelist.

1. example.com - Used for in-game map data
2. example2.com - Video tutorial for the mission
3. otherexample.com - Embedded scoreboard

Do you trust this content and allow it to be loaded?
[ ] Yes, allow this time only
[ ] Yes, always allow for this mission
[ ] No, block this time
[ ] No, always block for this mission```

[chrome bloom]

[ ] Yes, allow this time only
[ ] Yes, always allow for this mission
You really, really don't want a popup everytime a page is loaded. You would get at most one per mission. So the first option doesn't really have a purpose, no-one would click that only to get another popup later in the mission while driving a car or shooting at an enemy.

And the whitelist doesn't change, so if you approve all at the start, then you'll have approved all of it.

Just showing the user the whole whitelist is a nice idea, and a nice balance between "everything" and "per-url".

But I would like a choice to always accept it, everywhere and not have to accept every. single. time. I. join. the. server.
And for a "accept always", you can't really show a URL list.
We could do a "always allow on this server". I think that would fit best, most users use cases. But then again, showing the list of URL's there, isn't optimal.
Because the next time you join, it'll still be allowed, but the list might have changed.

Though.. there really is nothing stopping us from storing the servers IP AND the whitelist.
So if the whitelist changes, you need to re-approve.... That does sound good.

Annoying thing with the "always"/"Remember this choice" options. A simple "Yes all" "No all" we can easily add into the game options so you can easily change it after the fact.
This per-server thing, not so easy.
I guess in MP we can just show you the setting for the current server, in the options... Maybe that will work fine..

This mission wants to load web content from the following sites:

1. example.com - Used for in-game map data
2. example2.com - Video tutorial for the mission
3. otherexample.com - Embedded scoreboard

Do you trust this content and allow it to be loaded?
[ ] Yes, for this game-session only
[ ] Yes, always allow for this server
[ ] No, for this game-session only
[ ] No, always block for this server

So this, we can do? And "always allow for this server" will be "until the whitelist is changed"

We don't have message boxes with 4 buttons. And the URL whitelist doesn't have description texts. But that's all doable (I'll hate it, but I can do it 🤣 )

[runic leaf]

Sounds good to me👌

[chrome bloom]

Not sure how to handle that in singleplayer. There is no server to store. And the missionname is not reliable, multiple missions can have the same name.
You'd probably just not get a "always" choice and need to approve every SP mission at the start

I would like to just by default, allow loading .html files from pbo. Without having to approve it. That would solve most SP mission things I think.
But, there is the iframe problem.

And detecting whether html contains iframe and blocking it, is not possible, unless we also block javascript.
And blocking JS, while only being able to read the html text, don't think that would be reliable.

ah nevermind.
The "always" does work in SP.
Just instead of serverip+whitelist, we only use the whitelist. If the whitelist is different, we ask again.
So even if different missions use the same whitelist, it'll be ok

Wondering if we can do the same for MP, ignore the server and only use the whitelist. But maybe you trust one server accessing example.com, but a different server you don't trust with it

[fair egret]

per-list per-server works best imo

if youre accessing youtube.com for example can still show nsfw content or whatever unlisted etc

[chrome bloom]

youtube nsfw content should be behind a 18+ banner 🤞
But yt probably doesn't do that filtering on unlisted

[fair egret]

yeah and is just an example anyway

other websites could do the same principle

[chrome bloom]

Then you could also argue the singleplayer one should also be per-list&per-mission.
But.. Also like if you run a campaign with many missions. You don't want to re-ask the same thing.

Also, the whitelist we display, there are 3/4 whitelists combined.
Mod config, campaign config, mission config.

And there is also server config, which when its set, overwrites all mission/mod whitelisted things.
And for server config ones, I won't be able to provide description texts.

So we would display all of them.
And always show the user all of them.

That means you get asked for the ACE mod one, and the vanilla "http://oldman-online.bistudio.com/rules.html*"
But as long as the list is not too long (ugh, I have to make it scrollable.....) that's not really an issue.

[chrome bloom]

The per-whitelist thing would be alot of effort to implement.

Is it actually worth it to show the whitelist to the user.
As KJW said, youtube.com for example can be fine, and can also be not fine.

If you join a server and get prompt

This mission wants to load web content from the following sites:

1. missionAuthorsName.com - Used for in-game score display
2. youtube.com - Used to display the Tutorial video

Do you trust this content and allow it to be loaded?
[ ] Yes, for this game-session only
[ ] Yes, always allow for this server
[ ] No, for this game-session only
[ ] No, always block for this server

Would you accept?
Well reading these sites, sure does make sense and sounds alright, so yeah I'll approve it..

And then.. The mission script opens a web browser displaying the pages

missionAuthorsName.com/subPageThatEmbedsPorn
and
youtube.com/watch?v=SomeVideoContainingBadStuff

Does it really matter that much, which Websites's it requests and whether you trust them?
Or is it more a "I trust the person who made this mission/server"?

If its a "I trust this server that I play on", then I can save myself a couple days of work implementing all this displaying the URL's and descriptions for the URL's and per-whitelist checking stuff.

If we just do this

This mission wants to load web content and display it inside the game.

Do you allow it to be loaded?
[ ] Yes, for this game-session only
[ ] Yes, always allow for this server
[ ] No, for this game-session only
[ ] No, always block for this server

That would save alot of time to implement it.

[fair egret]

yeah imo its more of a server/mission maker trust thing than webpage thing

i dont wanna see porn from this random server but i do wanna see porn from this less random server where itll be funny for example.

[chrome bloom]

So 4 options.

1. Allow everything or nothing.
   There we can easily provide a toggle in the game options, so it can be changed mid-game.

2. Prompt per URL.
   User gets spammed with prompts when there are multiple URL's
   Would be quite hard to show a list of URL's in game options

3. Prompt per server.
   Hard to display a list of servers in game options, but we can just display the "current" server while playing on it, so it can be changed mid-game.
   What if the server changes the whitelist, since the last time we played on it.

4. Prompt per server + check for changed whitelist.
   Ignore the last "Always" value if the whitelist doesn't match the one from last time.
   Can still display "current" server in game options.

The last 3 variants, can all show the whitelist.
3. doesn't really make sense to show it, because it might change.
4. would require to show it, otherwise why would you care if it changed, if you can't see it.

3/4 with whitelist showing, would also show URL's from mods or vanilla, that might not ever be accessed in a browser (maybe its just for htmlLoad, or for users clicking a button to open something in steam overlay)

Showing the whitelist, has the problem that while the site may seem reasonable and good. It might have a sub-page with bad content, that the user by themselves cannot judge.
Additionally there is still the iframe problem, a good page, may contain a bad one in an iframe. You'd not see it on the whitelist.
And the F'ing iframe problem is still an issue for pages loaded from pbo

[fair egret]

imo prompt per server - and then if whitelist has changed since last time inform the user of that; option to show the delta there but not much point imo

[chrome bloom]

No delta. I'd only store the hash. Don't want to fill user profile up with masses of different servers whitelists.
But we could say that whitelist has changed since last time

[fair egret]

yeah sounds good to me

is there any scope for scripting command with all whitelisted htmls if there isnt one already?

[chrome bloom]

The mod config, campaign config, description.ext ones you can read yourself via config scripting.
The server.cfg list you currently can't access.
I can cram everything into the command that does all the webbrowser control things

[fair egret]

yeah imo being able to get all the htmls whitelisted in an easy way would be useful for clientsides to tell you that info in case people are really desperate

[chrome bloom]

Well you won't be running scripts to look it up yourself on some public server you're playing on.
And if the server owner shows it to you, you cannot trust it anyways because they might just hide whatever bad thing

[fair egret]

fair

[unkempt linden]

Is there any precedent from other games integrating the browser?

[sick isle]

does anyone have some copy&paste code i can use to test webbrowser in 3den on a monitor? 😄

[tidal remnant]

I'm not a web dev so I can't comment on it from that perspective, and I didn't read the whole discussion here, but one thing that comes to my mind is that a malicious user can create a UI something similar to the steam overlay and ask you to sign in because "something went wrong", and then steal the user's login info

So what I mean is, you said you blocked the actual steam addresses but what about fake ones? (I don't know how easy it is to spot a fake address in the in-game browser)

[chrome bloom]

createDialog "RscDisplayRenderTest"

[chrome bloom]

Could. But why would anyone log in in the steam overlay.
Well I guess users that fall for phishing gonna fall for fishing. Probably don't even need the steam overlay, can just open browser

Its basically impossible to spot a fake address.
Just use a unicode one that uses some unicode circle instead of the "o" or whatever.
I don't think there's much we can do to fix that.
That'd be a good point against this feature

Potentially could be helped if we do actually show users the whitelist.
If we force ascii, you'd notice it being messed up with unicode tricks.
but someone using a lowercase l instead of an i, people might still fall for that even if they see it

But. Again brings the point of "people can already do that"

Pop up a dialog saying "There is a problem with your steam connection, please re-login" with a "Login" button, and when you click onto it, it opens phishing site inside the real browser in the real steam overlay.

[sick isle]

that user texture doesnt work in your test file, right?

[tidal remnant]

If there was a way to at least warn people not to enter any login info via the in-game browser, that would make it ok imo

[chrome bloom]

Its off by default, need to copy the thing from script into texture box in the attributes

[chrome bloom]

I would like that, but how do we display it in a way that a script cannot just get rid of it by running "closeDialog"

And in a way that its not..

Well we already make a "The game wants to use a webbrowser" dialog.
We can just put it in there and hope the user will actually read it, and remember what they read weeks/months ago when they approved it

[sick isle]

cool. now just need to be able to interact with it 😄

there is a lot of cool stuff that could be done with that. shame about the possible exploits and abuse

imagine scripting ingame interfaces just via that webbrowser thing instead of whatever we have to do right now

[chrome bloom]

Yeah.. I tinkered with that and everything I came up with was horrible.
As an example I popped the display from the texture, also into a normal dialog display on screen, and then turned off rendering for the dialog and forced on mouse cursor. So I could click onto the UI in the texture...
And i don't think its safe to add commands to let script click things on it

Well..

You can interact with it. Send javascript

javascript can scroll the page, click buttons and stuff..

[tidal remnant]

Would it be so terrible to block all keyboard input (mouse-only interaction)?! 😅

Or prompt once when you want to enter something. idk how that one would work tho

[sick isle]

damn, this shit is really cool

wish i had a lot more free time on my hands

like remember those AAN websites in IDAP showcase etc... this could all be an actual website 😄

no need to script those terrible interfaces and all of that, just build an actual website

i like how this looks and feels. lots of potential

almost makes me go meh that later there will be a popup first 😄 pulls you out of the game

[chrome bloom]

We could block it.. But you can just add a KeyDown eventhandler to the display, and then run javascript to push the user input into a textbox on the page.
And I'd prefer usability for actual non-on-texture UI uses

[chrome bloom]

You can force the popup at mission start, and only actually display the UI later on. There won't be a second popup.
It pops on first browser usage

[tidal remnant]

Oh wait there's a popup? Is it from steam or Arma?

[chrome bloom]

There will be one

#1275768332905353317 message
Guess this sums it up the shortest

From Arma

[tidal remnant]

Ah this is actually nice

[balmy shuttle]

Sooooo does this have an adblocker

[chrome bloom]

Sadly not.
I tried to record a Rick roll and needed like a dozen attempts to get one without ad

"go to my website to learn how to easily make $200 per hour"
Just doesn't ring as well as "never gonna give you up"

[edgy lagoon]

Other games are already using html for UI's.  It would be great if we could do the same in arma.
But the whole popup thing will make it less attractive. 
What about having a secure mode, that limits the features of the browser and therefore does not require user interaction. 
The secure mode will allow setting the URL but won't allow SQF access to page content or execution of JS code (from SQF).
Maybe even disable Video/Audio playback. But I don't see that as a problem. Missions can already include and play video files, that might be porn. Where is the difference?

[chrome bloom]

I cannot limit the features of the browser

The worry is not about SQF executing javascript.
The worry is about someone opening a website and showing you bad content that you don't want to see.
And just disabling SQF access to the page, wouldn't help there.

I wanted to disable audio, but I can't.

[edgy lagoon]

You could additionally only allow HTML files that are inside the mission. That won't eliminate the possibility due to external JS and iframes, but would make it more difficult. 
Another possibility would be using CEF instead of steam

[chrome bloom]

Using CEF is too much effort.

I'm thinkin about allowing html files inside mission even without a whitelist set.
But due to iframes, that doesn't get rid of the risk, so we'll still need popup for it

[chrome bloom]

WebBrowser concerns!

Need to make the box a bit wider
Not much space for text in these buttons

[chrome bloom]

By the way, you also do not have to deal with the popup, if you are willing to make your own extension.
Extensions are all powerful anyway, so they have no safety prompt and you can also implement a webbrowser in there.

So either deal with popup, or deal with making your users use a extension. And if you mess up the security things in your extension, that's on you.

[mystic pine]

The wording will need refinement to be more clear and better grasp implications.

ie its the embedded Steam web browser, right?

• its not about allowing but whitelisting additional domains, or really yes or no regardless what domain(s) used?

would advise also to change "trying to" => "wants to"
and flip the 2nd sentence and less technical but more about impact: "Do NOT enter passwords or other sensitive information inside the Web Browser! Otherwise you risk the information getting misused!"

good would be also to name the question at the end and name the buttons with actions:
"Do you want to allow the Web Browser:"

• Block/stop for this mission
• Block/stop on this server [for any mission]
• Enable for this mission
• Enable on this server [for any mission]

PS: i guess its not per session but permanent. So to adjust their dialog decision, people would need to adjust the profileNamespace?
PSS: how to avoid a script to tamper with the profileNamespace?

[chrome bloom]

"+ its not about allowing but whitelisting additional domains, or really yes or no regardless what domain(s) used?"
its yes/no to the whole whitelist.

Text is just my amateur example writeup, we have people who are good at writing texts who will clean this up.

"PSS: how to avoid a script to tamper with the profileNamespace? "
There is no profileNamespace involved here

It'll be in the game options

User can also mid-game turn it off in the options.
Which will close all currently active browsers.
Or they can turn it on, which will open/load all browsers that were queued up

[chrome bloom]

[mystic pine]

what audio channel is used? custom one like for videos?

[chrome bloom]

It's played inside the steam client. No volume control

[mystic pine]

so can be done via winows volume mixer. separate to steam itself

[mighty tiger]

How does the sound of the web browser play in game? Is it 2D or 3D? I ask because I'm tempted to rig a music player up using this system on dev branch using YouTube playlists.

[chrome bloom]

Its not at all ingame. 2D, no volume control, not listening to ingame volume controls

[runic leaf]

could possibly make it to 3D via an extension

[chrome bloom]

Technically possible if you give extension the position of the texture (and the texture is only in one place) and the players.
And you'd have to implement CEF yourself. Lots of work

[runic leaf]

there was an live car radio mod on the workshop which had 3d sound, you could get out the vehicle, walk around it or even fly away with the camera and you could hear it coming it from the car

https://youtu.be/JrSy9ZFFNRo?feature=shared

[chrome bloom]

Okey one security thing that I keep running into are iframes.
But, I could just force the engine, to run javascript that simply deletes all iframes from the page. But then it needs to run somewhat regularly, because other javascript could dynamically create new iframes.

That is not perfect, they might appear for a short moment, maybe a few seconds before they get deleted. But maybe this is enough?
I could run the script every frame, but I don't want to F up performance with that, especially as in 99.99% of cases it won't do anything useful because there shouldn't be any iframes

[fair egret]

How much performance does it eat with no iframes there per frame?

[chrome bloom]

Don't know.
The script will run in steam so Arma doesn't care how much time the script needs.

But, the webbrowser in-game is only updated rarely. If the page is static, it might never update, very nice for performance. If the script triggers a re-render, we need to copy the texture over which takes some time.

In any case, it would not be noticable when having a dozen browsers, but everything impacts fps a tiny bit, and things add up.

[fair egret]

I think given it's a security concern every frame is the ideal option but at least every 0.5s imo

[chrome bloom]

Wonder if I can assume that when an iframe is added, the page will re-render.
Then I can only run it if the browser updated since the last check. So for static pages it would just never run.

But I assume it would only re-render if the iframe is also visible.. to be tested then

[ashen storm]

Ugh... I forgot about this thread, since when I was mentioned I was busy as hell, so I did not read this (yet 😦 )

That is not perfect, they might appear for a short moment
I don't really have the context now, but if you're considering the security implications of someone stealing tokens/cookies by opening an iframe and accessing it, then I'd say that even "a short moment" may be catastrophic.

If I were malicious, I'd just keep opening the iframe again over and over again, in a loop, until the engine catches a hiccup and lets me go far enough to render the steam page and steal the cookie, or sth (I'm not a js dev so not 100% sure if that can be done, though)

[chrome bloom]

Cannot access tokens/cookies.
You can only run javascript in main window, which cannot access iframe contents

You cannot open steam pages in main window. And steam page has cross-site scripting protections.
And I think, javascript launched post requests, wouldn't be able to use steam cookies, because they should be tagged as secure/SameSite/HttpOnly