elliotkillick

How did you justify paying $6,000/year for a dedicated IP address? SES will provide you with the same thing for $25/month (https://aws.amazon.com/ses/pricing/#Amazon_SES_Pricing). I noticed your statistics didn't include SES. To me, mystery surrounding reliable email deliverability is primarily a tactic some vendors use to entice non-technical people into relying on their proprietary email marketing solution.

Email deliverability is no secret. Just send an email to one of many email deliverability testers to find out the spammyness of your email: https://www.mail-tester.com

The sender IP address is a large component in determining email spammyness. This is why SES allows you to pay extra for a dedicated IP address (https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip.html). However, it's not something you will likely need unless you send in large volumes.

Thanks! In my personal experience, I've had success delivering to the inboxes of Gmail, Outlook, and Zoho Mail with SES. However, my newsletter is entirely opt-in on my website. When I signed up for SES, there was a human review as to what I would be sending. So, I think Amazon understands spam is an issue, too.

Listmonk supports many email providers though, if your needs outgrow SES.

Oh, nice! I recall Reddit did support RSS at one point, I didn't realize they limited it. rss2newsletter is only ~300 lines of code right now and I'd prefer to keep it more on the minimal side of things. But, that's definitely a cool feature to have.

For sure, converting feeds into emails in that direction is something I've seen as a sticking point for a lot of projects. I'm glad I could fill that gap for you.

My pleasure!

Hey, this looks fantastic! I really appreciate minimal software that does what it sets out do well without bloat. I noticed that your GitHub README states "Collect Emails: Create your simple mailing list". It just so happens that I just released a tool for completing the next piece in the puzzle by taking those email addresses and automatically sending a notification of your new articles to them in a newsletter (assuming Nucelo supports RSS). Check it out at https://news.ycombinator.com/item?id=40898313 if you think it can be of help to you.

This looks like an interesting take on email marketing. I use an open source solution called Listmonk (w/ Amazon SES) for my emailing needs. How does this project compare?

Thank you! I'm glad to hear my project is working well for you on the upcoming Qubes R4.1 (currently untested by myself). To the best of my knowledge, no official QWT build exists yet for R4.1, so yes, building it yourself is the way to go for now. Also, good to know QWT is fully operational on the latest version of Qubes.

Any of the Qubes-certified laptops are guaranteed to work great out of the box, they come with Qubes OS preinstalled: https://www.qubes-os.org/doc/certified-hardware/

I'm not sure the exact details of your hardware problems but you may want to try out Qubes R4.1 when it's released (or the RC1 version now). It will ship with a fully updated base hypervisor and kernel feature set thus granting support for newer hardware.

Otherwise, feel free to open an issue on the Qubes issue tracker and the Core Team will look into it.

Qubes supports VM suspension so if you wanted to you could easily create a simple shell script to suspend and resume upon the Windows VM window becoming minimized and reopened. You could use `xprop -spy <window_id>` to check the window status without polling and `qvm-pause`/`qvm-unpause` to suspend/resume the VM.

I also faced this problem with the low selection of resolutions to choose for the Windows desktop with my ultrawide 3440x1440 screen. No worries, it was easily overcome with a simple modification to SeaBIOS, see here: https://groups.google.com/g/qubes-devel/c/aCCGpYysZTQ/m/4yMY...

I'm in the process of submitting a patch to SeaBIOS so it will no longer be necessary to patch this in yourself.

Wow, I was unaware such hardware virtualization extensions currently existed in such mature form for GPUs. Really unfortunate that they've been lost to the avarice of two tech giants which have a duopoly over the GPU market.

If you're referring to GPU passthrough, then yes, in practice much better with AMD cards then Nvidia cards.

Thanks!

GPU virtualization is a very difficult thing to do securely, I think VirtualBox said it best in their hardware 3D acceleration documentation (https://docs.oracle.com/en/virtualization/virtualbox/6.0/use...):

"Untrusted guest systems should not be allowed to use the 3D acceleration features of Oracle VM VirtualBox, just as untrusted host software should not be allowed to use 3D acceleration. Drivers for 3D hardware are generally too complex to be made properly secure and any software which is allowed to access them may be able to compromise the operating system running them. In addition, enabling 3D acceleration gives the guest direct access to a large body of additional program code in the Oracle VM VirtualBox host process which it might conceivably be able to use to crash the virtual machine."

It's currently a problem yet to be solved.

My pleasure!

That feature is currently in the works (officially speaking) for Windows 10; for Windows 7 it already exists (although it has of course been EOL for some time now).

However, I do recall finding a report of someone successfully using WinApps (https://github.com/Fmstrat/winapps) as well as RDP running in a Linux (GNU/Linux) qube to effectively also have Windows applications displayed on a window level. Security-wise it still holds up because that Linux qube, if compromised via the RDP connection, will lead to the disclosure of no additional sensitive information because it's only being used for that single purpose. As long as you have ample RAM to support it, this could work very well.

By GUI virtualization, I was referring to the way Qubes handles receiving graphical updates (e.g. windows) from the VM and sending events (e.g. mouse clicks) to the VM. The Qubes GUI protocol is like VNC or RDP but much, much more secure: https://www.qubes-os.org/doc/gui/

No HW acceleration by default as of now. It's possible to passthrough a GPU to the Windows VM in order to get acceleration, although, you risk exposing complex hardware directly to the VM which comes with many security implications: https://www.qubes-os.org/doc/device-handling-security/#pci-s...

Note that in practice, passthrough works best with AMD GPUs; I've heard few reports of success with Nvidia GPUs.

You're in luck, there exists exactly what you're looking for. It's called the Hardware Compatibility List (HCL), see here: https://www.qubes-os.org/hcl/

I'm aware hardware support on Qubes has been problematic for some users. Luckily, it's looking to get a lot better with the up-and-coming Qubes R4.1 (currently on it's first release candidate). It will be shipping with a fully updated base hypervisor and kernel feature set to allow support for newer hardware.

I'm not quite sure the specifics of your hardware problem, but, feel free to file a bug on the Qubes issue tracker.

You're starting to get the idea:

Qubes OS assumes that it's impossible to ensure every single application you will be running on your computer is secure. Therefore, the best way to secure your computer is to isolate all of the applications as much as possible so the exploitation of one doesn't lead to compromise of another or the entire system. Through (heavily minimized) Xen VMs is the most basic way Qubes seeks to provide this isolation. However, it goes much further than that into the networking stack, audio stack, GUI stack, and much more. This all lies on a security principle known as "security by isolation" or "security by compartmentalization".

You typically have different "qubes" (VMs) for all of your different day-to-day tasks/activities. Although, not necessarily each process.

By all means give it a try, you won't regret it!

Hi, HN! This is a small project I developed for Qubes OS that allows you to spin up new Windows qubes quickly, effortlessly and securely.

Hope you don't mind the flamboyant title, but, I truly do believe that the small attack surface of the heavily minified Xen hypervisor, networking stack, GUI virtualization, and much more Qubes OS employs + the Whonix intergration implemented in this project (making it a Windows-Whonix-Workstation; thus also giving it Tor-only Internet access with stream isolation between other VMs) makes it the most secure and private way to use Windows currently available today. Those are just the two main points, besides that, there is also the fact that because everyone using this project is both having their Windows VMs set up in the same way and running Qubes OS, that greatly helps to keep the OS and hypervisor fingerprint homogeneous across all users. This effect will only grow stronger as the Qubes OS userbase increases. Lastly, if the user wishes to reset their fingerprint, they can automatically do so by reinstalling Windows with this project.

Of course, I would be happy to go into detail and answer questions about any of this.

Note that this project is the product of an independent effort which is not officially endorsed by Qubes OS or Whonix.

Hey, this looks interesting! I realize how essential telemetry is in the information age even for sizable open source projects. For example, Firefox does a lot of privacy preserving telemetry to provide insights on metrics such as how many people are utilizing a given feature.

Any open source project which helps do telemetry in a private manner is a good thing in my books.

I'm just curious, who exactly is your target audience/market with this project?

Email in general is an antiquated technology for which security came as an afterthought.

If you want to use your PGP key to chat securely with others you could try Keybase.

A developer's PGP key would be a good example. PGP keys are used by git to sign commits and tags. Plus, they're stored in the home directory so they may very well be accessible to a rouge package in the event of a supply chain attack.

That's interesting. You can also put an entire game inside of a bootloader.