Qubes App Store, for developers to earn money

This should be a separate thread, I took Solenes thread (Paid learning material project (book, videos, how-to?) - #4 by catacombs) to be about earning money from making Qubes more usable… Instead everyone else references earning money by Documenting, providing information on Qubes.

Seems to me, The only people who actively use, and keep using Qubes are those individuals who are -somewhat geeky people. Whereas many of who need to use Qubes, are - such as, Journalists, who, I suspect, would not be willing to devote more than two hours to learning how to use Qubes safely.

What is missing in the current implementation of Qubes? Obviously Qubes is delivered to us as more like a ‘tool kit.’ That is not a criticism of the Qubes Developers. What the next step to make Qubes usable to non-geeky, non-techy people is a more finished Operating System, which has usable software, That is third party software.

Yes, Third party software increases the attack surface.

Yes, ordinary people do not know how to choose third party software that is safe. And what is considered safe today, may change tomorrow.

I like the idea that unman presents in his simple implementation of Qubes. That is to provide an entire Qube to point and click install. In the case of his stuff, like Solene, to keep all those things functional, and to add more. What is needed is money for the techy to keep it working. More than half the time spent on software is spend on maintaining software, compared to first time development.

Also putting unmans PGP verification key into dom0 is unsolvable to a non-technical type. If the how to directly, parrot that into happening, that is not obvious. and yes, right away we have telling a newcomer to violate one of the first strongly worded rules of Qubes, “Do Not Change dom0.”

What is needed, is an App Store, and the un-popular part of that is that people must pay to get and use Apps. Which is going to rub those who advocate free software the wrong way. And is profiting on the bones of Free Source software.

And price to consumers, How much would anyone pay for a Qube that is a Click and Install App for a specific VPN???

How to keep free source from duplicating a pay for App, and offering it for free?

That is, I am advocating something like the Apple model of an App Store.

I don’t see how one can keep the typical believers in free software rights folks from sabotaging the concept. ??? Red Hat gets around that, as it seems to me, by offering support as part of the package.

We see Dasharo, as part of taking a step forward in Security, has ways to get revenue.

If one built a version of Qubes, for say a Journalist. Then sold your entire package to some ruthless business type who will market it at exorbitant prices. Given the way the world is going, While he might just steal the idea and the emulate the code (buying it only protects him from one set of lawsuits, as he can claim he is legal owner, and has a right to market it, as a Copyright)

Qubes is unusable for non-geeky people. Either be a geeky person, or spend thousand or two thousand hours getting up to speed.

Right now, Qubes, from the stand point of a newcomer, seems to sabotage the very implementation of other programs into being used inside Qubes.

For what is in Windows is a point and click install of a program, can be, for a new geeky person, a whole weekend project.

All right, Limit these Qubes Apps to those programs that are not suspected of being owned by someone selling user data, or having, authoritarian, sinister connections.

Purism already offers a set of software Apps, such as a safe, sandboxed use of Metta, (FaceBook) I would not want to spend the weekend trying to install that in Qubes.

All I can say, if you build a Qubes App store, you will find someone will find a way to hate you, sabotage your efforts. but for Qubes to take a step into being useful. It seems a necessary direction.

aronowski, Reply in Solenes thread.

Personally, I should have a phrase, “I agree; Hell no that is not safe.” For use with a lot of your points. Being online at all is not safe either.

Is it more safe to let a thousand newcomers, if there are that many, wander through the initial stages of learning Qubes, and deciding which programs to use. Like which Video Chat? Which messaging Service? Which Chat programs? Which DNS? (actually how to get a more trusted DNS going?)

When someone comes on the Forum and asks; ‘Is there a calculator.’ and telling them well mouse over to , and then do this, and do that. Well. After three or four looking for something like how to get “Calculator,” is going to cause newcomers to say, “Uh, I will try this some other time.”

Apple App Store seems to be profitable. Qubes App Store, if properly administered allows staff to limit which programs are easily available. As opposed to a video chat service where the Servers are in an Authoritarian country, where there is no pretense of making the entirely of videos between ‘private individuals’ to be available to another, interested party.

Insofar as Trusting the work of unman. I sure he would smile and say, “Verify then maybe trust.”

Folks often install programs knowing they should not trust, but, “what else can they do.”

Take an App from an Qubes App store, which some others can verify as being accurate to what it purports to be. ???

Trust is not the issue. It is money. I am a cheap blankity blank who lives an a meager pension. I may not buy many Apps anyway.

I know, as others here know, that many of the people who, are at risk, are in places, and situations where they do not want to be tracked, and they have little money to send through the internet. As well as, some Human Rights folks, have little technical knowledge. I suspect some of what we call Journalism is now going over to private individuals, not an individual whose career is as a Journalist, who is part of a credentialed news gathering, then public informing service.

Then there is the matter of what someone referred to as “Work Flow,”

Or Operational Security, “OpSec” for someone to document, and the individual to practice.

I did hope that Business People would adopt Qubes, and Business people would have the money to put into better computer security.

I have a feeling no Qubes App store will come out of this. Just like some of the features to allow the easy install of some programs off the internet have disappeared from an earlier edition of Qubes to Qubes 4.2.1.

but questioning the security, safety of an App store is a good concern.

1 Like

I provided a fix for the application “Software” allowing to install packages in a few clicks in a template, but it didn’t get in.

A nice GUI intro when you first boot Qubes OS, explaining how to do XYZ in a few slides would be really cool… From my perspective, install software in Qubes OS could be really easy, no need for some store because it already exists.

What you want is a store for salt formulas, it’s much more complicated to implement, and I highly doubt it get approved by the developers anyway.

1 Like

Links would be appreciated.

From my experience (not a qubesos dev here), once qusal/shaker salt stores are tested/stable enough, the discussion could open for integration in contrib repo and opt-in. As of now, there are too many discrepancies/bugs to be considered for inclusion. Ideal endgoal here would be post-install, network enabled salt deployments with shaker installer equivalent being installed by default, but there is no consensus here on how to arrive there as of now, unfortunately.

For example, cacher, both included in qusal/shaker contains bugs that prevent cacher to be useable without issues with Fedora (cksum) errors. Shaker doesn’t consider sys-whonix and misses sys-tor still today un repo, where qusal uses shaker upstream and tries to generalize not being bound to some specific use case shaker does.

Tbh qusal is amazing, and needs more testing to become mature enough, where shaker providing an installer (didn’t follow if fixed to work on q4.2 still), by providing rpms which clearly shows entry points for salt recipes in rpm spec files for both install/uninstall. That means installing qubesos customizations means installing an rpm and reverting to uninstall such rpm. Can it get more simpler then that? Yes, if the qubesos installer was proposing such customizations. But I’m getting ahead of ourselves here.

If those two projects upside/downsides were merged with more testing, I’m pretty sure the spec files/rpms could be considered for inclusion (afterall qubesos contribution guidelines are clear on packaging requirements) under contrib repo.


@solene I missed your PR for quick fixes on native distro installers? I Remeber vaguely @deeplow having suggested something similar in the past, maybe tagging him in your PR would get reviews and make this go farther? If software already in trusted repos, having them visually presented would be an improvement for sure.

2 Likes

The fix is quite a hack, I meant that it didn’t get in as maybe it’s not good enough. Upstream doesn’t seem to care much.

1 Like

@deeplow was working in something like this, I’m not sure about the current status of that project.

1 Like
1 Like

that’s awesome. I would have been glad to have it the first time I used Qubes OS, I needed to be productive immediately after installation, I struggled too much to understand how to copy / paste and reinstalled a regular Linux :joy:

2 Likes

Upstream does care and at least part of it got included Make gnome-software work a bit better in a template · marmarek/qubes-core-agent-linux@331e757 · GitHub

I never checked again if it fixed it because I realized that the default templates had switched to -xfce… (Which in my eyes as a blow for usability and asthetics). This meant that default templates no longer a modern-looking graphical software store.

So making it work out of the box to me now seems that it would be a nice niche feature. I was even working on a video tutorial (many actually) on installing software. I had it all already recorded. But the issue is that I had been using 4.2-rc1 and so I never realized until pretty late in the game that in rc2 the default templates changed and most of my recordings assumed gnome templates.

That was not the only reason for why I didn’t make more video tutorials, though. I am a perfectionist, which further delays things and I had a few other setbacks like my Qubes video editing setup not working on 4.2, etc. But it’s still something I want to do. And this was kind of the follow up to the integrated tutorials (a more sustainable approach).

So it would have been really nice to have had Gnome Software fully working and the devs do care (they shipped that patch into 4.2 even as it was in RC mode!). However I don’t think that matters much because default templates don’t ship it anymore :confused:. So there is currently no GUI path for installing software without ever using the terminal.

It’s just an unfortunate set of circumstances…

4 Likes

Also, neither this nor the paid contributions thread belong in All around Qubes, they are totally about Qubes…

1 Like

Is it that bad to install gnome-software in the XFCE template?

I just tried, it’s a 70mb installation.

It’s not ideal, if someone can’t use Qubes OS without an app store, then it’s probably better than nothing.

Alternatively, the XFCE template has synaptic installed for people who just need a GUI tool for apt.

1 Like

I would say yes because you need to use a terminal. So for someone who’s never used one it’s not a very good first experience. Require a harder to use tool to use a simpler to use tool is not ideal. Furthermore, before it was even on the template menu by default, which meant it could be discovered by the user out of the box.

Yes, but other than having a pre-historic user interface, synaptic has poor software discoverability. One has to know already the exact name of the software they are looking for. It’s better than nothing, but much worse than gnome software.

1 Like

you already need to figure that “synaptic” is the program name to install other program :joy:

2 Likes

Precisely. Not even the name is right…

1 Like

Reading all of the above (and I’m sorry for interrupting this thread from reading only e-mail subject and jumped to replying instead of having read the whole thread), this is kinda going where my ideal always was.

So if I recap, the default templates are now closer to minimal, that required a switch to xfce. That’s good for size of iso, and to fit base deployment to reduce size of sys-* runtime memory footprint, which was the goal initially of xfce template. The gnome-installer fix is now there, but required packages to deploy it by default are not present in the installer to be installed (no gnome in xfce templates) without network connectivity nor packages offered to be installed at install.

Maybe a bit of plumbing would be necessary?

If we get back to basics, the typical qubes user (there is no such thing, but still), lets call him “qubes beginner” to reflect persona, would want to be able to install trusted software from trusted distro repos GRAPHICALLY. And that misses a graphical INSTALLER that can talk through update proxy. They want near other Linux distro experience, but inside of qubes. Graphical experience, not shell based (feeeear) and that’s ok. This should be ok. Why is it neglected? Because other technical considerations want over. But it could and should not be a blocker.

Let’s take a top down approach then bottom up for integration path?

Top-down:

  • On qubesos installer, have the installer propose and activate “gnome Gui and Gui installer” ticked by default, whatever that name would be. The default!
  • in the installer, have those base package and associated salt recipes available for activation, without the packages being inside of the templates but made external so not deduplicated across templates (a la “cacher” approach ), so that all minimal templates can deploy them at install without those being inside of the templates (biiiig win on sizes, win for sys-* service qube, lower memory need generally). Fits all, no NEED to be in all templates.

Bottom-up

  • figure a way from the installer to have deb+rpm local repositories or similar somehow so installer can deploy additional software (without network connectivity) or enable on-demand additional salt repositories usage with network connectivity requirement
  • have installer propose those additional customizations which will be able to download other templates and deploy software install on second stage reboot of qubesos

The important point here is that templates choices to land in installer can and will change and just did change, where the defaults might have had size consideration over usability, even though I read complains on github as well on the result of usability of that choice. Setting default is always hard, but not permitting customization is the issue here. I’m pretty sure that if size constraints were respected with customizations at install being possible, then we would get what we want (lower iso footprint, lower sys-* service qube footprint, high usability by default for new comers, opt out for advanced users). AND NO NEED TO REDO ALL DOCUMENTATION.

Therefore I think the issue is the limitations of the installer to permit to deploy user selectable installation options to fit the “persona” problem once and for all. Not what the templates deploy by default and maybe the debate should be around how to push needed packages to be used across templates or other solution, and or salt recipe inclusion/network access in the installer?

I would vote for better usability by default with users opting out if really desired, but yet again without getting too ahead of ourselves, it’s a technical challenge to do this right, while I think the real challenge might be around having packages and salt recipes for templates customization at install to fit different goals, different persona. And if that grows too big, consider network install option while packages available and qubes install, if not in templates and duplicated increasing size of templates, could resolve all the needs of everybody without trying to tailor one size fits all templates that needs to fit in the ISO.

To image this, consider having minimal templates only, and externalizing packages needed to turn minimal templates in their xfce/gnome counterpart. The packages would be there once and available after template deployment at install, and salt recipes present to do this the right thing each time, since clean templates freshly installed. The packages footprint would be minimal, and the packages needed for customization present once instead of in all the templates. The final gain here would be to have one whonix template, not two, saving most of the place needed here for iso size constraints. And the minimal templates could be cloned by installer prior of creating xfce/gnome counterpart, where gnome counterpart would probably be deployed for new users and or not advanced users or lower end perf computer users, if not all because not consuming more ram in service qubes as the end goal of template choices.

Thoughts?

I dream of a day where qubes video companion, qubes screenshot and other needed customizations are in and ticked by default or through UX careful design decisions. The delays between needs and feature made available to users is the main problem I see here. The new user should be able to install softwares available through fedora/debian channels, visually, to get more people on QubesOS. And that is not happening because of technical constraints. We need to fix that. And in my opinion, we need to leave the one size fits all approach, and learn from side projects like qusal/shaker and somewhat bring back what was learned from those PoC projects in slow integration steps upstream. But well, and without jeopardizing usability through regressions. Let’s learn from this and define the needs properly, and choose best strategies to meet them.

From my experience, OEM now create custom ISOs to deploy their packages. This shouldn’t be that way. The ISO could wrap around a loop back disk layer that contains packages and salt recipes which would deduplicate sizes of templates and what creates those customized templates be available externally. This is a strategy not a need. But if we focus on the needs, we might get lucky.

Annnnd. Not need to redo our screenshots/videos all the time to explain to users how to address their needs. But that is the final goal of this thread. Not how to get there.

3 Likes

@deeplow I follow securedrop github repo and see a lot of your involvement there. I’m not sure how to suggest those approaches in a way that fits both qubesos and securedrop, but any insights you have to address the needs and then the strategies to go there would be really helpful for all, and not constantly redoing the docs and videos which are the outcome of both threads now spliited out.

1 Like

(moving this to General Discussion, since it’s Qubes-specific)

1 Like

I’m now working on SecureDrop, that’s probably why :slight_smile:. I don’t have a specific answer for your question, unfortunately and I don’t think the SecureDrop team is focusing on software installation at this moment. But I might have misunderstood your question. Please let me know if that was the case.

Actually I don’t agree that the issue is with customization. A new Qubes user won’t know what to customize and may feel overwhelmed by the options. Furthermore having more default customization also complicates the documentation efforts. Think for example of all the various parts “if you’re on Debian do X if fedora, do Y”. Now we could have the matrix of options for [fedora,debian]*[gnome,xfce], which is not sustainable.

I don’t fully agree with the XFCE default templates but I understand the reasoning. Now we just have to deal with the consequences, documentation-wise.

1 Like

Tik Tok Money accelerates the when, the point in time, when a usable, more polished Qubes is available.

I see some ideas put forward, that are like the perfect solution.

I was going to suggest to a more simplistic, way forward.

Then I wanted to experiment with the versions from downloading entire Qubes. As I do not have at home internet, and my public library was not open. So the impracticality of my what I thought was a good solution. Well.

Still. It is possible to create Qubes that might be directly installed, no salt. Salt may be a better solution, but it does not feel like it will take less time as testing and such.

As the first thing a person who needs a secure connection needs is a VPN.

First Qubes for the VPN’s ( which are not complained about as being , owned by someone who might be exploiting them, and/or, . . . .

As work flow, I imagine one having a disp Qube that is open to the internet, and
Such as a Template and a disp App for Mullvad. Or other browsers. Claws Mail.

then the information should be moved to an offline Qube , for viewing, preparing reply, deciding what to keep.

So a Template that is offline, with most of the standard types of tools, office, calculator already installed. this list could be from someone more knowledgeable than myself.

A Template that is prepared to allow installation of Snap Packages, Flatpak, Gnome, gee would that include Synaptic. So the user could clone up this Qube, and install what he desires with less study, looking back and forth to documentation.

Notes somewhere on how to move things between Qubes.

I feel unman has created Qubes already that cover some of the other needs.

Qube for use with a secure chat, and there are several options, I feel, just one of the reviewed software ones,

If we can find a Video chat that is not from an authoritarian country with adequate encryption protocols. Put that in a Qube by itself.

I had read that Ubuntu had an, “I talk, it types.” if it works, and it is free, then create a qube for that, that is always offline. but I have not found that applications (I talk it types)

This seems to cover a lot of, what the newcomer might need. If the user will stick to the flow of work, receive information in one set of disp Temporary Qube, transfer to a Qube for actual viewing and such.

If just one more Qube, is to be created, then it would be the tempate which already has all the connections to allow software to be installed without a lot of terminal work. Like has Flatpak installed. Snap Installed, the installers needed for the other software. and it will leave a clickable tab to be shown, for any Software installed.

1 Like

I wonder how this impacts the project, but since I joined the community, I feel like developers are working on a secure operating system, while the majority of users seems to be chasing a privacy oriented operating system?

If this is really the case, Qubes OS won’t provide a good user experience, and will never do.

Are there any data about the community? Like a survey to understand what people need, what people lack etc…? This could be interesting to help the development team IMO.

1 Like

Yes. Qubes Survey: The Results | Qubes OS

1 Like