But obviously yeah, nothing's going to prevent you from giving a website access to your .ssh directory if you explicitly select it.
Personally I don't have a problem with that. The ability to upload files has been a thing on the web for forever and I don't think there's ever been anything that stopped users from uploading their private key. Possibly some users have gotten phished that way, but at a certain point you have to accept responsibility for your own actions, otherwise you start ceding control of your life to a corporate nanny state.
So websites can now nag users to allow access to the root of their local disk and then read all their files and settings, all their SSH keys and other passwords?
From what I gather from the docs [1], this API gives you a FileSystemDirectoryHandle object, and then you just call getDirectoryHandle() on that to recursively read the the entire filesystem. The spec [2] has some vague suggestions about blacklisting certain particularly sensitive files, which doesn't seem reassuring.
So what should I do if I want to make an app with this functionality? Do I have to tell users to download and run some executable? You can imagine a case where that is a bit riskier than a nicely sandboxed web app with permission to access one directory.
Well there is a permission dialog and you need to select the directory to grant access and common sensitive directories are blacklisted.
A malicious ad would probably have an easier time tricking you into downloading and running an executable, which is something that has actually happened many times IRL. Worry about that before worrying about theoretical exploits that nobody has actually exploited in an API shipped in the world's most popular web browser for the past 6 years.
That isn't how any of these things work, though. This kind of thing needs a permission to be granted by the user and it does not extend to third-party ads appearing on the site that it is granted to (banner ads have, for a long time, been sandboxed in iframes in the browser to prevent such exploits). I wish native applications had this level of isolation from each other.
Apple will never implement anything in a browser that could make a web app as capable as a native mobile app, they are simply too greedy. Firefox typically doesn't implement these things unless they have to because they don't have the resources that Google and Apple do.
Apple is also on the W3C committee that approves new specs, where they abuse that power to prevent any spec that might cut into their app business from moving forward.
Just because a problem is not hard to imagine it doesn't mean that the problem is actually a problem in practice. It is worth asking if there are any signs of it existing for real.
I hear a lot of this "nothing has happened so far" from people who DUI before their first crash and people who use the same password on multiple sites before their first credential stuffing hack
to use your analogy you're claiming that half the population has been driving drunk for years and yet you aren't pointing to an increased rate of collisions on the road. This is not the same thing as an individual doing a dumb thing and getting away with it for a while.
Could it simply be because many use their smartphone to browse the web and of those many have an Apple device and Safari based browsers don't support that API?
It's like the eraly claims that MacOS has no viruses.
No the bad guys jsut didn't care enough because the ROI wasn't big enough
Root directory would be on that blacklist for sure.
Those "vague suggestions" actually seem to include some pretty specific examples.
> A user’s entire "home" directory. Individual files and directories inside the home directory should still be allowed, but user agents should not generally let users give blanket access to the entire directory.
All of them, unless they're also on the list of examples to exclude (like the Downloads folder).
I think the point is that as long as the user is sharing things on purpose and not by accident, it should be allowed. Selecting the root of the home directory would probably share a lot of things the user didn't really intend to share (because a lot of apps just dump random config files and stuff in there), but if they specifically select a subfolder they probably have a good idea of what that folder contains.
Is the camera roll excluded? I bet I am not the only one who has a passport picture in there. I don’t know about other people’s camera rolls, but I bet it is occasionally more saucy than mine.
Let's not forget that, at the same time, Google forces every developer of any Android app to register in the Google database using an ID scan, otherwise no one can install it.
What happens when the data contains the record or field separator characters?
I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.
In the case of this system (a quasi-EDI interface used to move records from a fleet fueling point-of-sale system to the ERP software) those characters were forbidden by the source application. My code would have exploded in a fireball if they had been present, but the specification said they couldn't be.
Otherwise you need to have some sort of escape mechanism, exactly like quoting strings in CSV. In fact, there's an ASCII code "ESC" for entirely that purpose. :)
The problem is that those characters are non-printable, which means if you're just dumping the file out somewhere, you can't see them.
What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?
An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.
While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.
Regarding Swing, virtual threads are "just" threads so no reason they (and structured concurrency) can't be used.
So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.
There is no public-facing continuations API afaik.
Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.
You still can't block in UI code, right? You don't know whether you're on a virtual thread or the UI thread (even if its virtual) by design. You still have to bifurcate your APIs into blocking and non-blocking, don't you? Virtual threads will help you keeping the CPU fed but it won't handle separating UI and non-UI work, or know when a frame deadline ends.
Have there been Swing specific updates to deal with that?
The colorless functions approach has well-known disadvantages though, including providing less control and making interop a pain. It isn't like one approach is the correct one and another is a mistake.
> including providing less control and making interop a pain
This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI.
In general, the costs and limitations associated with a feature in language X don't extrapolate to language Y, because they often stem from interaction with existing constraints in language X.
The design of FFI is a very common source of problems for various features. For example, if the FFI is designed such that you frequently pass pointers to to objects to C, that can have a big impact on other features. In Java, you nearly always only pass pointers to "off heap" memory, i.e. memory that's not managed directly by the JVM. While this has no performance cost, you could say that this, in itself, has some convenience cost, except Java programs need to rely on FFI much less than other languages, so the overall cost to convenience is low.
How can green threads have zero impact on FFI in the presence of callbacks across the boundary? I mean, as soon as the other side uses TLS in any way, for example, you have to figure out how to handle that, and it's not free.
In every user-mode thread or stackless coroutine (async/await) implementation I know, the construct is pinned (i.e. can't be preempted) while there's a foreign frame on the stack. There is no advantage to either design on that front.
But 1. there's no speed penalty in Java for doing that, and 2. In Java, calling native functions that block (which is the only time this limitation matters) is rare, especially in high concurrency situations where you'd use virtual threads in the first place.
The problem the article is describing seems to have little to do with open source. There were GitHub repositories that had links added in their READMEs to a zip file containing compiled binaries.
GitHub is not a curated software repository. It's essentially no different from some random stranger linking to some binaries on a forum. (There are communities that seem to have no concerns about running unknown binaries from strangers in forum threads, but I wouldn't recommend it.)
there are numerous OSS maintainers who have turned GitHub into a religion. the maintainers of bevy and brew come to mind. it is a "curated software repository" and so much more, it's practically a way of life for these guys.
The vendors are never going to give you control over your computer no matter what vision they try to sell you on. The whole point, from their perspective, is to use their control of your computer to gain more control over you, which they hope to then exploit for profit.
Idk I feel like Ansible and RHEL aim to give you that control in a way that’s not typically corporate icky in the way you describe but ymmv. Granted both are products based on FOSS; so in the broader sense that pattern may hold
> Security: I run every Pi session in a Docker container and give it permissions only to bash so that it can’t run Python code or do web browsing
How does that work? The script in the post references the file "docker-compose.sandbox.yml", but I don't anything about what that file does.
The post that this one links to, that it's based on, says that Pi doesn't do proper sandboxing.
Presumably bash can still execute other binaries, otherwise it would be fairly useless. What stops it from executing Python? Or opening a network connection and downloading Python?
> During voice agent startup, the slowest part are [...] in dlopen-ing large shared libraries (ONNX Runtime in particular) and in hundreds of small random reads off the SD card as Python walks the import graph.
Could this maybe be fixed by arranging the files on the filesystem in the order they're read? Or maybe importing the Python modules from a zip file (with no compression) would be faster, if that makes it easier to store them in the required order?
I seem to remember Windows having some sort of feature like that, automatically rearraging the data on disk in the order it's read when booting the system.
reply