assuming that you have a potentially compromised linux host (or VM)
what level of client-side risk are you taking connecting a freeRDP client to that host ?
(i'm not worried about the case of the client infecting the host)
what is the most secure similar application ?
i prefer a linux client, though would be willing to consider windows if there was a client that was significantly more secure
I'm also curious about this; I don't know how secure the traditional native clients are (FreeRDP, Vinagre, Remmina, etc.).
On the other hand, there are browser-based clients such as Apache Guacamole and noVNC, which are protected by the browser's security sandbox. They require a server component, but that can be run in a sandbox or on the untrusted server. There are some limitations to running in a browser (e.g. some keyboard shortcuts might not be forwarded).
Economies of scale. If they sold hundreds of thousands ESP32 or Arduinos every day, their price would likely fall down to €1 per complete board.
> why aren't we seeing feature-rich dev boards based on the same platforms ?
Because those platforms are closed as hell and their manufacturers have no intention of publishing enough technical data to allow developers to write Open Source drivers.
That's the reason why the engineers at Pine64 had to design the PinePhone from scratch to make it run a real Linux distribution instead of using already available proprietary boards that would indeed be a lot faster and cheaper, but also would be restricted to run only Android with closed device drivers and the same crappy untrustworthy software that plagues cellphones today.
One thing that is mentioned by ~everyone who tries to reuse cheap phones as computing devices is that the phones are basically not meant to run all the time and fail very quickly when you try to do thing with the screen on for hours and hours at a time or otherwise hold it to high load.
I am sure there are ways to get around this with some cases but it does feel like there are practical issues with the cheapo/used phones. And that's not even getting into having to wrangle the OS.
Maybe someone can make an Android fork that is basically "make this phone a computing device that should last a long time" that you can easily throw onto phones.
Explanation to get around HN guidelines : The guy says : "Hey Morsi [ndlr. common male name in Egypt], Is this English ?". It started when Modamed Morsi was president of Egypt and spoke in incomprehensible English. Since most arabic speaking people are notoriously bad at English, it became a meme used when someone says something incomprehensible in any language
And I don’t get the feeling that it can generate data, in the sense that usually means. More importantly, what it does generate we can’t trust to be accurate…
tangent: for a small air-to-air heat pump, what's the best commercially available coefficient of performance (COP) for a zero-delta-T ?
all the common ratings that i've found online refer to COP at a non-zero delta-t over a ranges of conditions. to illustrate my question, if you needed to pump heat from 70°F indoor air to 70°F outdoor air with a 1-ton unit, what would be the best COP you could achieve in 2022 ?
cher·ry-pick
/ˈCHerēˌpik/
verb
choose and take only (the most beneficial or profitable items, opportunities, etc.) from what is available.
"the company should buy the whole airline and not just cherry-pick its best assets"
the author did not cherry pick. in order to cherry pick, the author needs to have had a predetermined thesis such that cherry picking only certain data points would bolster said thesis. instead, the author was looking to see what the deal was with long-term observed weather in specific places relevant to the author, then later expanded to include a few other locations as well. therefore, unless you are accusing the author of being dishonest, the author did not cherry pick.
How do you know he didn't cherry pick these weather stations? One thing to say that it's not clear whether he did, another to claim - as you have in your post - that he did not.
certainly if the user executes or opens them (eg for a .doc) they're powned. but automated systems can also have exploits. i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target)
for ubuntu 21.04+, i'm aware of:
- gnome-tracker-miner
- gnome-thumbnailer (may require browsing in nautilus)
- mlocate
at least the first two appear to be sandboxed, though unclear of the efficacy.
any other services that you're aware of that would be automated vectors ?
> i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target)
If you're running a lot of "untrusted code from github", then the list of services you have enabled or disabled on your system isn't going to make a difference.
For someone who frequently runs untrusted code, I'd recommend learning any of:
1. qemu / virsh / how to quickly and efficiently spin up isolated VMs
The first two options will be a more secure way to run untrusted code and provide actual protection. The 3rd has better usability, though isn't as secure.
Disabling local thumbnailing services... yeah, sure, do that, but don't expect it to really do much against "testing out untrusted code".
Some good tips on running untrusted code in VMs. If possible I'm interested to learn why you consider qemu based VMs as more secure than QubesOS? If I get it right QubesOS is Xen based so is it about the hypervisor or something else that favours qemu in your opinion?
QubesOS inherently has a higher attack surface due to the features it's added to be more usable.
An AWS VM in the cloud I ssh into can't possibly snoop on another window I have open.
QubesOS on the other hand includes usability features like displaying graphical interfaces from VMs, clipboard sharing features, etc etc https://www.qubes-os.org/doc/gui/
These usability features increase attack surface, whether they're implemented on top of a Xen or KVM hypervisor.
My assumption for a local qemu setup is that the user wouldn't use things like 9p or display sharing, which I think means a smaller enough attack surface to make a difference.
i explicitly said "if the user executes ... they're powned" and never said anything about "running". you're implying i'm taking far more risk than i am
i'm trying to understand (and minimize, if needed) the automated risks of having untrusted files *stored* locally, which would give me time to read them and develop a level of trust
fwiw, if i need to run something untrusted, i'm using #2 some, but mostly:
4. a 2nd (untrusted) machine running locally, which is beefier than my laptop and also used for benchmarking.
i've never seen any unusual behavior from it, but treat it as though it's compromised
what level of client-side risk are you taking connecting a freeRDP client to that host ? (i'm not worried about the case of the client infecting the host)
what is the most secure similar application ? i prefer a linux client, though would be willing to consider windows if there was a client that was significantly more secure