06:31 ahmadraniri[m]: <ifreund> "so remove them from the list? wl..." <- Hi, it works, thanks ifreund.
09:18 nomanias: Death metal exploit is not so difficult cause tcp is secure channeled communication protocol, only difficulty is to regenerate the hash of the communication https://github.com/Coalfire-Research/DeathMetal/blob/main/charles/charles.py their method is similar to uart, first they nop the load , then they inject the nonce or md5hash so everything would be juridically ok
09:19 nomanias: it is quite similar to uart, but the time they inject the nonce they can be already root
09:23 nomanias: so if it was a biggest level of threat to estonian country at the moment i would have to force my last liquid out, cause the defense to the commodity hw to annul those attacks is little more complex, it has quite medium complexity
09:28 nomanias: russians know all those vulnerabilities as americans and nato does, it's first they always used those simple intrusions over satellite guidance to send missiles to generals.
09:28 nomanias: things such as satellite phones were very big dark death
09:28 nomanias: but ukranian soldiers started to get training from nato and americans
09:47 nomanias: Problem with me, everyone is so angry at me, and i got phone which is likely military tapped, but i am unsure which side of the conflict, so that is the problem when you author the code not yourself you have to trust others but i have kept using this phone and hopefully nothing happens, i think i am on the side of nato
09:48 nomanias: so i have not switched the phone
09:48 nomanias: hope that is the case otherwise i might get slaughtered
09:56 nomanias: used my hunch there, others thought this might be the technology for russians, cause they are advanced too, but i saw something that might be above russians according to my understandings and i think that might be the other side of the battle field.
09:56 nomanias: me i have never heard that russians posess such laser communication
10:00 nomanias: there are two sets of different implementations roughly, i call it bus guards, one that tries to service and defend against ddos too, but one that takes the abuse client off the line only
10:02 nomanias: so this looks like so, you have some bus content and you retime everything, depending what was posted on the bus your units can validate it and execute as delayed
10:04 nomanias: so the best one is that you hold the bus all the time open, but you have some fast networked computer resources
10:04 nomanias: but you add conent to the bus and decipher what attacker sent
10:05 nomanias: decoding what was sent, and should we react on executing ddos army at it
10:08 nomanias: first implementation can be thrown at the mix, but some claim it's more related already to military world
10:08 nomanias: cause it scrambles the bus while bus is held all the time open, it's not possible to read the circuits also
10:09 nomanias: and the level of complexity is not so dramatic high, it can be beautifully made for static location, one the wireless world, i do not have such backend equipment to draw back the ddos network of course.
10:10 nomanias: cause the mast in my house does not belong to me
10:25 JEEB: that was some weird spam
10:32 MrCooper: not really spam per se, just ramblings of an individual with mental health issues
10:45 kennylevinsen: Sure this isn't a Markov chain at this point?
10:46 MrCooper: yeah, he's been around for a long time
10:55 kennylevinsen: Yeah fair enough, just feels like coherence is down
13:23 Company: jadahl, swick[m]: I'm looking at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_1899436 from a client perspective
13:23 Company: like, if GTK was given a random icc profile (from a fullscreen gstreamer say) and wanted to pass it on, it seems suboptimal if stuff doesn't show up on screen
13:23 Company: otoh, GTK can likely just parse the profile and extract the stuff the shell cares about
13:24 Company: *the compositor
13:24 jadahl: yea, if it only cares about e.g. the primaries then it can extract them and create them via the other factory
13:24 Company: it seems a bit evil that we pass secret bianry blobs through the stack
13:25 jadahl: scary no doubt
13:25 jadahl: would have to wrap it in bubblewrap or something
13:25 pq: please do not assume that you can dissect all ICC files like that
13:25 Company: it's really convenient if you don't wanna touch the pixels
13:25 Company: pq: it feels weird to say "here's a magic blob that you don't understand, please just pass it on"
13:26 pq: yes?
13:26 jadahl: Company: if it's for a subsurface then it is just scary, not "bad" since you don't care about the content
13:27 Company: jadahl: if it's for a subsurface, GTK won't see it, because subsurfaces pass us by
13:27 pq: An ICC file contains a number of color transformations, from which you pick one based on your rendering intent, and connect it with the destination profile which may require additional comptation steps in between. You cannot assume that you can reduce an ICC file into anything else the protocol can carry.
13:27 jadahl: if its not a subsurface, you need to parse it and "composite" the content given the ICC profile in gtk
13:28 Company: jadahl: but even then it feels evil - there's 4MB of unknown data being happily passed through all sandboxes potentially into the kernel
13:28 pq: Company, it will definitely NEVER be parsed in kernel.
13:28 jadahl: pq: for "get pixels and ICC from gstreamer" I imagine the ICC profile as a whole has less meaning if the pixels are reprocessed by gtk thus it can use some other factory
13:28 pq: or even handed to kernel
13:29 Company: pq: passed to the kernel might happen sooner or later with things like virtio
13:29 Company: no idea if/when monitors are gonna start reading icc profiles
13:29 Company: but yeah, likely not in-kernel
13:30 pq: jadahl, sure, if GTK takes it onto itself to use the profile and produce pixels based on some other description, then that other description is what you'd use.
13:30 JEEB: I think at least some pro monitors boast that they can ingest some sort of ICC profiles?
13:30 JEEB: or at least LUTs based on them
13:30 pq: Company, ingesting a LUT is totally different from ingesting an ICC profile.
13:32 pq: like I said, an ICC profile contains possibly multiple color transformation pipeline definitions in both directions. It is nothing like what you see in the protocol elsewhere.
13:32 Company: yeah, icc profiles are wild
13:33 Company: which means they're an amazing path to exploit things
13:33 Company: buth in good and bad ways
13:33 pq: what isn't?
13:34 pq: However, it's a self-contained file of data. It's not executable, it does not contain bytecode or anything (yet), and it cannot refer to anything outside of itself.
13:34 Company: it feels to me like this should be some async call, so the app knows what it's getting into
13:34 pq: A wl_buffer is a huge binary blob.
13:35 pq: yes, jadahl raised a point there
13:35 Company: still not sure how i'd want to represent that in GTK
13:35 pq: in the end, you end up trusting the CMM you use to parse it
13:35 pq: what do you mean?
13:36 Company: do I send all the icc profiles to mutter just to have them ready when needed?
13:36 pq: all what icc profiles?
13:36 Company: do I have an API so people can say "make this icc profile usable with the compositor"?
13:37 Company: the ones people create ColorState objects with
13:37 pq: that's a way to make the app start-up heavy
13:37 pq: there is no "make this usable", either the compositor accepts it or it doesn't. If it doesn't, you get to fall back any way you like.
13:38 Company: well, if it's async, then the answer is "maybe" until I get a reply
13:38 pq: sure
13:38 Company: but attaching a buffer to the surface isn't async
13:38 pq: but you cannot use an image description anyway until it's ready, even if it is acceptable
13:38 Company: so I need to be sure the compositor has made the decision before I try to attach a surface
13:39 pq: yes
13:39 Company: so I need to make it acceptable
13:39 Company: asap
13:39 Company: because who knows how long it takes
13:39 Company: once I want to use it
13:39 pq: you can't
13:40 Company: well yeah, so I'm in a bit of a pickle
13:40 pq: just like you can't know when the surface commit is actually going to be shown
13:40 pq: until it actually is shown
13:41 Company: I can either parse the profile locally and do a fallback path, if the compositor can't handle it
13:41 Company: or I can let the compositor take care of things
13:41 Company: but if the compositor hasn't answered yet, what do I do?
13:41 Company: not attach a buffer yet?
13:41 Company: do the fallback until it replies?
13:42 zamundaaa[m]: You always need a fallback path, as the compositor isn't required to support icc profiles
13:42 zamundaaa[m]: Company: Yeah
13:42 pq: Why does it need to be so immediate? If it's a new window, why can't you fold that delay to the delay on mapping/showing the window? If it's an existing window, why can't you let it run without the new thing until the image description is ready?
13:42 Company: sure, but if my fallback is visually different, it will glitch once I get a reply
13:42 Company: pq: dunno - I'm just wondering
13:43 Company: there's probably multiple different use cases
13:43 pq: don't do the fallback in the meantime, that could lead to a glitch if the compositor accept and you move to relying on the compositor.
13:43 Company: not sure if videos can change the icc profile they use halfway through
13:43 jadahl: the mapping of a window is already pretty async, the difference would be if an existing window should suddenly get an ICC profile attached to it that it wants to forward, which seems a bit unlikely if it still needs to draw widgets etc
13:44 pq: so yeah, creating some image description in advance could be useful if you know you will likely need them
13:44 Company: jadahl: an example would be pressing the "next image" hotkey in fullscreen Loupe
13:44 Company: and the next iamge being one with a fancy new icc profile
13:45 pq: Company, then the photo is on a sub-surface. If you're not using a sub-surface, then you get to re-draw all your UI elements too using the photo's profile.
13:45 Company: fullscreen often has no ui elements
13:46 pq: ok
13:46 Company: but yeah, that would be another question
13:46 Company: should I use the typical path anyway if I might need UI elements later
13:46 pq: An image description is always set on a whole wl_surface, not a sub-region of it. If you change the image description, the whole surface is affected.
13:47 Company: yeah, but I could switch when not needing any UI elements
13:47 pq: I would very much recommend using sub-surfaces for photo etc. viewers, because you may not be able to match your UI element colors with the photo's profile.
13:48 pq: sure, you can switch
13:50 pq: OTOH, an application could target the compositor recommended image description only, do all color management itself, and never relay any photo etc. profiles to the compositor.
13:50 Company: I generally assume that the app and compositor are equally capable in their color management features
13:50 pq: assuming the application understand the recommended image description
13:51 Company: and the goal is for app + compositor to get the original image to the monitor as unmodified as possible
13:51 jadahl: Company: but shouldn't moving the mouse and showing the overlay widgets show the exact same content, meaning you need to handle re-processing the pixels in gtk without any precision loss anyway
13:51 Company: ie it's about matching the monitor's abilities with the data
13:51 Company: jadahl: yes, it's a tradeoff
13:52 Company: jadahl: I cannot composite with subsurfaces like I can with textures, so using a subsurfaces is limiting there
13:53 pq: I would stay away from re-drawing UI elements using arbitrary image profiles. It's too high risk to not keep the color match.
13:53 Company: it's essentially a decision the app needs to make
13:54 Company: the app may even want to force the image into its colorspace, like if it wants to edit the image
13:55 pq: right
13:55 Company: and generally it doesn't matter if the app or the compositor does the compositing
13:55 Company: because I assume they are equally capable
13:55 pq: It does matter. The result may be different, and neither may be incorrecet.
13:56 Company: right, but then the app should always do it
13:56 pq: just don't switch between compositor-managed and app-managed color for the same image
13:57 pq: choose which way to play, and then keep it like that as long as the same content is up
13:58 Company: which kinda means GTK should probably never use the from_icc_profile API
13:58 Company: and leave that to apps that create subsurface
14:01 pq: that would make sense to me
14:03 pq: Anything that GTK draws probably has assumptions about the color space it uses, so makes sense for GTK to own it.
14:04 dottedmag: pq: If the protocol does not specify alpha blending mode, then how can "use subsurfaces" be reconciled with transparency of elements on top of it?
14:04 dottedmag: it = content displayed on the subsurface
14:04 pq: Then a wild profile or another from arbitrary sources cannot make the GTK UI unusable accidentally.
14:06 pq: dottedmag, by using semi-transparency *very* carefully. I.e. mostly for just shaping.
14:06 pq: a fade-in/out animation is probably fine too, since it's transient
14:06 pq: but permanent semi-transparent objects I'd be wary of
14:09 kennylevinsen: semi-transparency and color correct presentation feel like complete contradictions...
14:09 pq: heh
14:10 pq: well, if people will ever agree to commit to an wayland extension that defines the blending behavior...
14:11 pq: but before anyone jumps to that, I would hope they see the color-management saga into production first, because that's how you find out the opinions
14:25 Company: so far I don't see many cases where people care about color-correct alpha blending
14:25 Company: I do see that blending happening by accident though
14:26 Company: like when there's an animation in an image viewer that switches between 2 images
14:26 Company: using a crossfade or whatever
14:28 Company: or somebody overlays a semitransparent right-click menu
14:42 MrCooper: case in point, the incorrect blending is pretty obvious with light text over dark background, still nobody's bothered to address that in a good two decades
15:11 Company: unless it's about text
15:11 Company: then all blending is wrong