<qyliss>
Irenes[m]: my current vision for a good application layer experience is basically focused around leaning into the existing free desktop ecosystem, getting involved in new developments where compartmentalization can be accomodated
<qyliss>
For example, XDG Portals are a very promising development that I hope to be able to integrate with, to provide file open semantics that look just like they would on a non-compartmentalized system.
<Irenes[m]>
that makes sense.
<qyliss>
So, ideally, by following existing and new best practices, general applications will work really well on Spectrum.
<Irenes[m]>
sure. it's a reasonable approach.
<Irenes[m]>
huh. are portals a flatpak thing? that was the first result that came up
<Irenes[m]>
guess they are
<qyliss>
Flatpak is driving a lot of this sort of thing
<qyliss>
As is Wayland
<Irenes[m]>
makes sense
<Irenes[m]>
good to know
<qyliss>
Nice to make your acquaintance after seeing you online for years, btw :)
<Irenes[m]>
oh! curtsy you are welcome, pleased to meet you as well :)
<Irenes[m]>
thanks for doing SpectrumOS, it's an awesome project. we've been hoping for years that somebody would pick up the CromeOS hypervisor and do something else with it.
<Irenes[m]>
*ChromeOS
<Irenes[m]>
(we = Irenes, not Google, we don't speak for Google)
<qyliss>
figured :)
<qyliss>
Google are doing other things with it too, though, I hear
<qyliss>
And there's Firecracker and Cloud Hypervisor, of course
<Irenes[m]>
ah, yeah
<Irenes[m]>
we knew the internal names for those things heh, nice that they're public now
<qyliss>
Another thought I had recently, since I've been looking for ways for other people to feel involved in Spectrum development:
<qyliss>
Would anybody be interested if I were to livestream or record myself working on Spectrum? I figured it might be a good way to get an idea of what's going on day to day, and how you mig hwork on the code if you wanted it to.
<qyliss>
But I'm also worried about making things more about me, which is the opposite of what I want.
<cole-h>
I can't guarantee I'd turn up live, but if there were recordings dumped somewhere, I'd probably watch some here and there
<Irenes[m]>
that sounds fun
<Irenes[m]>
we'd try to tune in if we were around at the right times
<Irenes[m]>
the fun of it would be the live participation, we probably wouldn't watch recordings
<cole-h>
"around at the right times" is exactly why I was hoping for recordings :^)
<Irenes[m]>
certainly. to each their own.
<qyliss>
okay, that's a pretty positive reception
<qyliss>
I'll have a look into what it would take to set up
cole-h has quit [Ping timeout: 265 seconds]
<IdleBot_a52e420f>
pie_: yeah, but I am just reading backlogs of low-traffic IRC channels twice a day under this instance, IdleBot is for idling; and I also need to get some reaction from edolstra. Do you mind dragging a rectangle or two in when2meet? It was chosen specifically for dragging rectangles unlick the Doodle annoyance by a hundred clicks
<IdleBot_a52e420f>
Irenes: consistent visual style is overrated (and I hope that passing a theme config should be easy once other things are done right)
<IdleBot_a52e420f>
qyliss: how confident are we in XDG-portals DBus interface being resilient?
<IdleBot_a52e420f>
I would also say that having an application see so few subtrees that the file dialog becomes easier to navigate is something I find quite convenient…
<Shell>
IdleBot_a52e420f: I’m fairly confident in xdg-portals being resilient, and it comes with the benefit that it’s roughly what everyone else is doing (e.g. Firefox uses parts of it under Wayland, there is GTK and KDE filepicker support that can be plugged into applications easily, etc) so using it means there is growing application support and work from others going in the same sort of direction. It’
<Shell>
s also actually useable - people just... open files/directories, and only what they open can be seen by the application, no fiddling with some unrelated UI to mount some directory before opening it necessary.
<Irenes[m]>
We mostly have found that the stylistic choices that do the most to create a sense of consistency are not ones that widget styling really allows anyone to customize. Compare any gtk or qt style to iOS or to Material Design.
<Irenes[m]>
We acknowledge that it's not everyone's priority
<IdleBot_a52e420f>
It is probably useful to modularise the low level enough that once can have a smaller trusted memory-unsafe code base than the current expectation of wlroots or KWin, then xdg-desktop-portal — and all that on top of hard to avoid Linux KVM code plus whatever gets effectively exposed to guest
<IdleBot_a52e420f>
Irenes: intuitively it seems to me that leaving the applications to do what they prefer and letting pick the apps that match is both the best one could do and also something that is likely to succeed
<Shell>
So to be clear, I’m coming at this pushing really hard on the usability side of things. In fact the original design for file access in Spectrum was, iirc, to just assign statically declared filesystems to instances of apps, which is inflexible enough that I (and p much everyone else) would wind up with a small handful of filesystems (Identity A’s Documents, Identity B’s Documents) where a wide num
<Shell>
ber of apps can see everything in them, which is likely more of a systemic risk than assuming the project can implement a file picker correctly.
<Irenes[m]>
I mean, I guess my question was more about whether developing stuff at the application and widget toolkit layer was in scope
<Irenes[m]>
The answer appears to be that it is not
<Irenes[m]>
Notionally there's no reason it couldn't be
<Irenes[m]>
Clearly, yes, existing Linux software is a hodgepodge
<pie_[bnc]>
IdleBot_a52e420f: i did do the rectangle draggy thing though?
<IdleBot_a52e420f>
Irenes: I think even Qubes is not large enough to also branch into GUI toolkit preferences, they just do the necessary minimum of edge-colouring to achieve the legibility goals
<Shell>
Note: if the issue is we don’t like dbus, we could stick a xdg-desktop-portal to something-we-like-better-over-a-vsock converter in the container with the app. And technically on the other end it could just pop up something like “hey, run this command in a trusted terminal to return a file to the container”, if you don’t want to install a filepicker. Fairly low TCB there.
<IdleBot_a52e420f>
Threat-model vs GUI design is as much of a context-switch as you can get, and not completing the context switch means failing at both things…
<Irenes[m]>
Sure. Very fair.
<IdleBot_a52e420f>
Shell: what you have described about a low number of compartments is I guess how people use Qubes anyway? I would say that for me isolation drives usability of workflows aligned with isolation (as opposed to trying to tradeoff security and usability of completely unmodified flows)
<IdleBot_a52e420f>
pie_: sorry, was not sure that you are deliciouslytyped and not one of the other shepherds whom I have not yet got to reply
<IdleBot_a52e420f>
Shell: well, it is sometimes hard to understand what to filter to make sure you cannot mount an attack using the shared file-picking server as a relay between applications
IdleBot_a52e420f has quit [Remote host closed the connection]
IdleBot_e923fa8a has joined #spectrum
<Shell>
IdleBot_e923fa8a: the xdg-desktop-portal spec has a rather minimal interface to what an app can ask of the filepicker. Most of the risk, I think, comes from user confusion re what’s on the filesystem - homograph attacks and suchlike.
<IdleBot_e923fa8a>
I am probably still more worried about something like a very long file name ending with a multi-codepoint single-glyph cluster being normalised wrong and leading to a stack overwrite in the file picker or something annoying like that
<Shell>
I mean, my assumption is that the filepicker would be written in a language where that sort of thing is much less likely to happen.
<IdleBot_e923fa8a>
In the directories I care about, I will not approve a file name that looks unrelated to content, and then mixing up two files with very similar name should not be as bad as a generic homograph attack
<Shell>
True.
<IdleBot_e923fa8a>
Well, it seems plausible that many people will go with KWin if it ends up the preferred compositor of the only full-time developer, and then KDE default filepicker (dunno if Qt or GTK) might end up being used by most people
<Shell>
Uhh, wait a second. The xdg-desktop-portal implementation would have to be partially custom to match the needs of Spectrum anyway (knowing how to mount files into the container, etc), which means that it is not necessarily tied to a specific DE’s implementation, and parts can be swapped out.
<IdleBot_e923fa8a>
I was under impression that for Flatpak isolation use case XDG-Desktop-Portal supports simply relaying the file contents over D-Bus
<Shell>
I don’t believe so?
<IdleBot_e923fa8a>
Hm, so even more custom code is needed, and of the type most likely to complicate reasoning about threat model
<IdleBot_e923fa8a>
But indeed less temptation to reuse a non-security-oriented implementation
<Shell>
My hope for Spectrum is that it is the one object-capability system that can be used on a daily basis. Applications ask for what they want, I choose what to give to them based on what they have access to right now (so I can see e.g. that when I go to open a sensitive file that the application instance has previously been granted network access, and decide instead to open a new instance of the app
<Shell>
without network access). Maybe I could even automate this so that I can declare that some resources cannot be granted to applications that have been granted some other resources, just in case I fail to notice - and maybe the filepicker can’t even see them.
<Shell>
Or the other way round, “this application wanted to ask for network/gpu access, but couldn’t because it has access to X file”.
<IdleBot_e923fa8a>
(looks at the current use patterns of network access code) I think you could add that an application could get access to multiple implementations of the same resource, like being configured with different proxies (which carry different policies and different forwarding) or different DNS etc.
<Shell>
Yup.
<IdleBot_e923fa8a>
As a command-line user, I am actually OK so far with just specifying the resource allocation on launch (and scripting whatever becomes to annoying to specify manually every time)
<Shell>
Specifying resource allocation on launch and saying “no more resources ever” could totally be a thing, but I don’t think Spectrum is living up to what it could be if that were the only option. I still want to be able to open up a LibreOffice document and see what a couple of different pictures from my photos folder look like in it ad-hoc (preferably without giving it *all* my photos and potentiall
<Shell>
y having it secretly embed something compromising that I didn’t notice from an irrelevant photo back in 2014 into my document).
<IdleBot_e923fa8a>
Yeah, true, I have various initially-empty shared folders that can be filled/drained by a more trusted instrument
<Shell>
That’s kind of the other thing with classifying files into strict security domains, people are gonna miss things and wind up with high-sec stuff in their low-sec filesystems. At least if you have to give an application the file directly, you might notice the issue in a solidly sandboxed preview pane in a filepicker before you give the file to an app with network access.
<IdleBot_e923fa8a>
In my case everything happens at pretty fine granularity, so typically if I give a subtree, it is a small subtree, and otherwise I give the application files if I forgot it needs them
* Shell
nods.
<IdleBot_e923fa8a>
But I kind of have a working workflow by now, and also I have other weird things I want to integrate it all with, so I am most interested in the low-level Spectrum parts being a reasonably cheap upgrade from containers to VMs
<Shell>
Yeah, I... don’t. I’m really quite bad at security, largely because the options available to me are really big and heavy and intrusive in a way that means they prevent me from using my system for the boring things that I care about less. Imagine, for example, if using TAILS on occasion meant people couldn’t easily play video games or make music or whatever any more - I know a lot of people who wou
<Shell>
ldn’t be doing basic Tor stuff if that was the case, and it’s the same sort of situation for operating system security in general right now. Either you buy into a heavy framework that intrudes into how you do everything, even when you don’t need it, or... you just don’t do anything really.
<IdleBot_e923fa8a>
This is the annoying elephant in the room of the modern computing… like everything has a pretty exploitable code path to GPU, and GPU drivers are garbage
<IdleBot_e923fa8a>
(… and GPU itself has thick and underconstrained DMA)
<IdleBot_e923fa8a>
On the other hand, «garbage gets zero filesystem access, except whatever files it created itself last time» is pretty easy to define and gets you pretty far as long as there are no IO/rendering-mediated attacks
<Shell>
Mhm
<Shell>
Like, I’m fine with “don’t give GPU to anything when handling non-public info” or whatever, but “I now have to learn how to use a computer from scratch just to write recipes down, apply for a passport, and maintain my music library” is not so fine and is also not something I can reasonably convince others I need to share information with to do, is my point really.
<IdleBot_e923fa8a>
Actually, Firefox seems to survive lack of /dev/dri access pretty well, which is nice. From that point of view, Maybe Wayland some more restrictive protocol like VNC is actually safer for isolating JS-enabled FF than Wayland
awordnot has quit [Ping timeout: 258 seconds]
awordnot has joined #spectrum
awordnot has quit [Ping timeout: 268 seconds]
awordnot has joined #spectrum
cole-h has joined #spectrum
awordnot has quit [Read error: Connection reset by peer]
awordnot has joined #spectrum
awordnot has quit [Ping timeout: 272 seconds]
awordnot has joined #spectrum
<qyliss>
You can just not give Wayland clients GPU access
<IdleBot_e923fa8a>
Ah, at least. (Wayland protocol being quickly developed still makes me nervous, but at least nothing assumes GPU access)
<qyliss>
It's only really being developed in terms of protocol extensions, afaik
<qyliss>
Not the core "get a surface and draw on it" stuff
<qyliss>
And we largely will want to avoid protocol extensions, or do custom implementations for them anyway
<qyliss>
Like, we don't want any normal clipboard implementation, for example.
<IdleBot_e923fa8a>
I think you said that a pretty basic test required fixing a version mismatch for some extension, though
<IdleBot_e923fa8a>
I am from the side which would be OK with inside-VM-only clipboard (with a special bridge available, of course)
<qyliss>
That wasn't really an extension, that was a fairly rare update to the drawing protocol.
<qyliss>
They added a function to damage a surface using different coordinates
<qyliss>
This interface now contains about eight functions IIRC
<qyliss>
not exactly fast development
<qyliss>
Inside VM-only clipboard with bridge is what Qubes has and it works reasonably well.
<qyliss>
Not really sure how that'll look for us yet.
<ashkitten>
what does the bridge look like for user experience?
<qyliss>
You do Ctrl-Shift-C to copy from a VM clipboard to the global clipboard, then Ctrl-Shift-V to copy from the global clipboard to a VM clipboard
<ashkitten>
hmmmm
<ashkitten>
that would conflict with terminal copy/paste by default but i imagine that's configurable
andi- has quit [Ping timeout: 268 seconds]
<qyliss>
presumably
<qyliss>
I might have the shortcuts wrong
feepo has quit [Remote host closed the connection]
feepo has joined #spectrum
tazjin has quit [Remote host closed the connection]
tazjin has joined #spectrum
dgreid_ has quit [Remote host closed the connection]