Something similar again is my little tool hemlis [0]
It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).
That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).
Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
> Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system.
> Surprised to see no discussion of other data structures like dicts/maps, or arrays of arbitrary type. Hopefully they'd be a straightforward extension. IME, apps need collaborative data structures more often than they need pure collaborative text editing.
Totally agree. I guess an array of "atomic" objects, where the properties of the objects can't be changed can be done just by replacing the string with your own type. Changes inside of the object is probably trickier, but maybe it's just about efficiently storing/traversing the tree?
I've also always thoguth it should be possible to create something where the consumer of the helper library (per OP terminology) can hook in their own lightweight "semantic model" logic, to prevent/manage invalid states. A todo item can't both have isDone: true and state: inProgress at the same time. Similar to rich text formatting semantics mentioned in the linked article.
Every year or so I've been toying with the idea of a thin client dev environment. Smallest possible device that can run Linux (or a RDP client) and support being plugged in to a single USB-C dock cable (display, usb for keyboard/mouse and power).
Maybe this is the answer? Even though I don't need the screen, the footprint of a smartphone is smaller than almost all SBC supporting the above requirements.
I had a project related to this in a big telco about 10 years ago.
We used Citrix because a lot of apps were not native (yet).
Women in tech loved the concept: instead of carrying a laptop they could use the medium-size tablet we provided and have a wireless mouse and keyboard both at the office and at home. We also provided a monitor for both home and the office.
The project didn't lauch commercially because in our tests the microusb to micro-hdmi cables caused a lot of issues and management decided against it.
Nice to see PagerDuty mentioned here. I was on the mobile team at PagerDury that battled to get the entitlement to use Critical Notifications in the app. We were refused multiple times before we got the entitlement.
Agreed, and I would argue that it's even worse on the browser side. We have Chrome and Safari on iOS, the rest is essentially irrelevant. With regards to web standards, Edge is just another Chrome-reskin. When Apple sooner or later looses the WebKit monopoly on iOS, it will all be Chrome...
My "fear" has always been that Meta/Alphabet would slowly but surely migrate their apps over to their own third-party App Store to get past the pesky IDFA limitations[0] and other tracking hurdles.
So far nothing seems to indicate that it's happening. The question is if it's due to Apple's "measures" or just because it is not worthwhile for Meta/Alphabet. I think it's a combination of. But if it was as easy to "side-load" an app on iOS as on macOS - per your suggestion, I'm confident Meta would have done the switch in a heartbeat.
Just imagine if Apple provided nice API's for auto-updating, essentially no limitations on what binaries can be attested, API's/mechanisms for easy migration between AppStore apps and side loaded ones, no scary screens etc. Essentially implementing the DMA to the fullest extent, really honouring the intent of the law. Why wouldn't all the mega apps just move over? And what consequences would it have?
I think it would be awesome to e.g lift the JIT blocking and allow more strange niche things in alternative app stores. But getting all regular people on a wild-west third party app stores for the (ad financed) apps the use every day is just begging for a huge _actual_ loss in privacy.
I think it's just not worth it for them; look at Android, where sideloading was always available as an option.
Facebook does offer separate APKs on their website (so do, in fact, most major services - Netflix and Spotify also offer APKs from their website), but practically the only reason people end up using them is if they're on a device that doesn't support the Play Store (for whatever reason).
The only serious Play Store competitors on Android are either vendor specific (like Amazon's store) or wouldn't host Facebook apps to begin with and are unambiguously a positive force for users due to their standards (F-Droid, whose policies are designed to protect users from the typical mobile app rugpull of filling it with ads down the line). Anything outside of this tends to be independent hobby projects or corporate business apps.
The inertia of being the default is still really strong (for a slight alternative, much of Google's strength comes from the fact they paid millions to browsers to be the default search engine for them, a practice that's been found to have violated antitrust laws - it's telling that Google really wanted to keep doing this), which is still enough to keep Facebook attached to the Play Store and is probably why they won't try to leave the App Store either.
Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:
- (1) Each client generates a key pair
- (2) The fingerprint of the public key is part of the SDP message each client generates
- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.
The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].
This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.
Only the initial SDP needs to be fudged. The attacker could just set up two clients that pretends to be the sender/recipient. Then the data can just go through regular Google TURN servers.
In other comments to this link people are describing GPS according to my mental model, which is hard to combine with cryptography making it un-spoofable.
If someone can re-broadcast the keystream and control the latency I perceive as a receiver, how would me checking that the MAC is correct help?
"Modern" .NET (previously ".NET Core" v1, v2, v3 - but now just ".NET" v6, v7, v8, v9) works really well on Linux and in containers etc. "Legacy" .NET, .NET Framework, version 4.X, does not.
If you build something new today in .NET land you are using a version that is compatible out of the box with linux, but there's gazillions of LOC .NET Framework out in enterprises that have yet not been migrated/rewritten.
But I don't actually know if Mono is stable enough to run Framework services on Linux?
I don't know how (if at all) Kudu is related to Mono, but on Azure you can run .NET Framework in e.g App Services (which uses Kudo under the hood). It's probably the only way to host a Framework service outside of IIS on a Windows VM. And Kudo contains references to Mono, and looks really linuxy when I've used it.
It 100% is! I've used Mono years ago to run older .net in VMs and containers. I found a single service that didn't really work well and we spent our time working on that instead of rewriting the world.
> If you build something new today in .NET land you are using a version that is compatible out of the box with linux
This is not a generally true statement, particularly with anything involving UI. WPF or anything modern WinForms are not supported. MAUI has no official Linux support.
And neither is recommended to be used over AvaloniaUI (or Uno, or Gir.Core if you want to target just Linux), which supports it.
Given the amount of whining about Linux GUI support despite good and proven solutions being provided, it leaves me with an impression some parts of Linux community actually don't want support at all and the goal is to have a convenient scapegoat to complain about.
It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).
That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).
[0]: https://github.com/filleokus/hemlis