I still don't get how copying copyrighted content to your own website and then asking for donations can be a legal business model. Nor how it can be morally justified.
I get that many people like such an archive to be around for consumption. Me too. But, keeping emotions aside, I can't find a justification to violate the rights of creators.
I'm sure many people here will have the knee-jerk reaction to immediately downvote this question. But I know there are also thoughtful people on HN. If some of you have ideas about the legal and moral justification for archive.org's actions, I would like to hear them.
Copyright is a legal grant from the public to the individual.
Perhaps it is time to recognise that this literal Mickey Mouse law needs to be rebalanced more in favour of the public than the monopolist, as that creates better societal outcomes.
> I still don't get how copying copyrighted content to your own website and then asking for donations can be a legal business model
Because copyright isn't black and white like that. Its a lot more complicated. Its likely a lot of what internet archive is doing is fair use (not all though, they do push the envelope, e.g. their covid library stunt).
As for morally, while that is going to depend on what moral system you subscribe to. Copyright is a relatively recent invention. The bible might say thou shall not steal, but it's likely in context that the bible was fine with copyright infringement. It probably not even something that would have been thought about in a bronze age context.
As far as utilitarianism goes, at first glance seems like Internet archive increases happiness more than it decreases it, so that is a check.
I dont see any reason to think the internet archive violates the Categorical imperative either.
so i guess the question is, under which basis do you believe it to be immoral.
The legal justification is that it's a library. This does actually seem to work for them in general, although they badly overstepped with books and lost in court.
Any creator-based outrage should be directed first and foremost at the for-profit violations by AI companies, rather than the small volunteer service which is keeping history up.
Ultimately there is no archiving without piracy. The alternative is for the web to exist in an eternal present where everything vanishes the moment some business decides it's not worth it or conflicts with current corporate values.
It’s a non-profit that archives publicly-accessible content. If it were a for-profit (Google snippets, LLMs) I’d understand your question, but since it doesn’t profit from it I don’t see the issue.
Morally, the net gain of data preservation and access outweighs the copyright issues. This is especially true for abandoned works. And, morally, the current copyright duration is unacceptable.
For firefox you may need to enable `dom.webgpu.enabled` in `about:config`
It's on by default on Windows iirc - it's considered a potential security risk on Linux by Mozilla, so they ship it but it's turned off and it's up to the user to decide.
I think the reasoning is just because of how varied graphics drivers/stacks are on Linux compared to Windows/OSX and the attack surface been larger.
I tried it and the experience was not great. I first enabled chrome://flags/#force-enable-webgpu-interop which did nothing. Next, I enabled chrome://flags/#enable-unsafe-webgpu which made some WebGPU demos work, but they all use my CPU's integrated GPU, which is worse than using no GPU acceleration at all. Next, I found out that there is a powerPreference: 'high-performance' option. It can be enabled with chrome://flags/#enable-webgpu-developer-features and I can now request a GPU with 'high-performance' power preference, although there is no way to check whether this actually selected the correct GPU, and it is useless to do it like that anyway, since no website actually sets this (experimental) option. Fortunately, there is the flag chrome://flags/#force-high-performance-gpu which should solve this, but it is not available for my platform. I have a fairly standard RTX 3060, but apparently, the most common GPU (according to the steam hardware survey) is not supported.
Unfortunately, Firefox does not work any better. After setting the flag dom.webgpu.enabled to true in about:config, a few WebGPU examples (e.g. https://webgpu.github.io/webgpu-samples/?sample=helloTriangl...) work, but many other examples crash the browser. And of course, Firefox can't select the correct GPU either.
Hey, Firefox Web GPU engineer here. We would love to hear about crashers on any platform! If you need help filing a Bugzilla bug, or want to email me so I can do it, please LMK.
Pretty much the same here with Edge,#enable-unsafe-webgpu got me the emulated swiftshader adapter, but only #force-high-performance-gpu made the dGPU appear in the adapter list of https://webgpureport.org/.
I never understood why a program installed in Flatpak is not just a directory on disk.
When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.
The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`.
Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.
The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.
Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
You don't get such prompts on macOS if the app uses the system file picker, which they nearly all do.
You will get prompts for certain sub-directories of $HOME if the app directly opens them using POSIX or similar, so for example, anything running in a terminal emulator, or inside a virtual machine. Developers will see these prompts a lot more often than regular users do. MacOS doesn't let apps read directories but not files.
This is the sane solution. And not unlike what Android does in the end, with the difference that they have a share panel instead of an open panel: so you initiate the process from the app that owns the file rather than the one that wants to access it.
But GUI apps on Linux are so fragmented that getting everyone to use the same open panel is hopeless.
> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
And what is even the concern about that? I don't mind software knowing that my ssh key is in ~/.ssh/id_ed25519. Maybe if you see a 500 byte ~/.ssh/id_rsa that's an issue, but then the real issue is the tiny key
Thinking about threat scenarios of directory structure access, I'd be much more concerned about exposing that I have ~/documents/work/mergers/2027/[secret]_WarnerBros-Fox.docx
But only being able to see the file name would still be a huge improvement over being able to open the document and exfiltrate it
macOS does this for select directories. You either give access to all of `Documents` or none. It's also not great for notification fatigue, as you get like 8 popups at once in iTerm2. If you choose not to give access to a directory, you'll need to go to system settings to change this.
So, for a "better" system, we'd need to ask for every directory and you better hope the program doesn't try to glob all files in every directory and overload the user in prompts. Or you can "Allow all" or something, and then we're back at square one where the program has too much access.
If only flatseal could set defaults for all future installed apps too…
One thing I could imagine would be a kind of "Firefox tab containers" but for flatpak apps. On first launch, you'll have to select what folder will be ~ for it. Folder sharing between those is manual.
(And yeah, often forgotten but you can have several users on linux. Sadly, permissions and switching are pain.)
> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
Can't it request and be granted that permission, transparently to the app?
E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?
At least that's how I'd thought it would work. Perhaps this isn't viable?
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.
Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.
If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration.
If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit.
For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification.
For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default.
There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case).
Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently.
If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.
Exactly, and for many productivity tasks there can be even more applications involved. There is a reason why the restricted model was introduced on consumption-oriented mobile platforms first.
Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"?
Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.
I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
As everyone else has written, two very different things are being mentioned n your last paragraph:
First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders.
Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.
I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?
Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter
Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind.
If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web!
Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)
It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare.
This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.
It’s also just hard to make breaking changes on Linux. Apple can declare something is changing and you have 1 year to get with the program. In Linux you have to bargain and plead with devs over 10 years to change something.
Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
Apple has much better backwards compatibility than Linux. The APIs haven't changed much since the Carbon->Cocoa transition 25 years ago, and SwiftUI (but that's optional). The impact of app sandboxing on developers was small - and sandboxing is universal on macOS now, there are only different levels of sandboxing but no such thing as unsandboxed apps anymore.
Apple's introduction of sandboxing to an app ecosystem designed without it was a masterclass in OS design that goes unappreciated in our industry. Nobody else pulled that off. It's no exaggeration to say that macOS is the most secure desktop OS by a long way, it's not even close. Linux trails far behind in third place. They achieved this via:
• Extremely long term planning (multi-decade timescales).
• Extremely good systems design.
• Incremental change, so developers always had a digestable chunk of work at any given point. The work needed was smeared out over decades, not drop-kicked onto people in ways that left them flailing.
• Good developer relations work to ensure devs got help quickly if they hit issues.
At no point has Apple's security team had to change course, reverse a prior decision, redesign a subsystem or fail to meet their goals. Everything has slowly clicked together so smoothly most people, even devs, didn't even notice it happening.
The sad thing is, the engineers who pulled this off are largely unknown. The head of Apple Security came from the One Laptop Per Child project and deserves a lot of credit, but much of the careful detailed design that makes the Apple security architecture work is done by unsung heroes. One guy was known only by the name "Perry the Cynic"!
Edit: I did some searches. Perry the Cynic was Peter Kiehtreiber, who seems to now be retired.
>macOS is the most secure desktop OS by a long way, it's not even close.
GrapheneOS has become a desktop OS (because of all the work Google has done to adapt Android for desktop/laptop use) and its security exceeds macOS's.
You can connect a Pixel 8, 9, 10 or 11 to a USB-C DisplayPort-alt-mode hub and have a GrapheneOS desktop that way. In a few months, you might be able run GrapheneOS on a Googlebook.
Aside from that I agree with your comment, particularly your assertion that "Linux trails far behind" macOS in security.
I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.
I've had very good experiences with desktop applications in containers using Distrobox & podman. It handles all the integration into the host system, so video, audio etc. just work.
The default configuration is probably too well-integrated if you're looking to use it as a sandbox, but there should be ways to turn parts off.
Not using Wayland I am not 100% sure, I think Xephyr works in XWayland and I think their is a similar tool to Xephyr for setting up an embedded Wayland session (I would have thought this is even easier and more elegant in wayland but not sure). So could be even better.
I personally use X11 as I am on exwm and exwm does not support wayland and no alternative to it does AFAIK (I think theirs a POC floating around somewhere). Also I know X11 even though it's a bit crap in many ways it's the devil I know.
Supporting more than 1 writer per process. Strict typing. Access controls. Replication at scale is more effecient than copy-pasting files (seems SQLite has improved on this one).
Supporting more than 1 writer per process. Strict typing. Access controls. Replication at scale is more effecient than copy-pasting files (seems SQLite has improved on this one).
Force close the app and clear the cache, your photos will come back.
Or clear data completely, then open the app "for the first time" and immediately log out.
It'll work, but as you've discovered, google made sure that it isn't the happy path.
Also no search (not even by file name), no albums, some editing functions won't work (even though they're local), and a few more annoyances. but also no more backup prompt...
I closed the app, stopped it and cleared the cache. Then restarted it.
The UI is surprisingly sane now. My first impression is that it is much better than before. Everything is neatly layed out in a series of albums, for each the latest images are shown and I can click on the album name and it displays them all.
So I do see my albums. Those seem to be just directories in /Pictures/ which it seems I can edit with the files app?
Am I missing out on anything this way? I don't need search.
All the usualy edit functions like cropping, adjusting colors etc also seem to still be there.
I switched back and forth between "with account"/"without account" a few times now and it seems to work just fine. I stay with the no-account state, as it not only removes the nags, the interface is actually much cleaner and more logical
No idea about Lens, because I never used it. Aren't there webapps or web services for everything these days? I do everything that I do only occasionally via webapps. Barcode parsing for example.
Does this mean it is possible to talk to Codex from ChatGPT on a mobile phone now?
When I tried that with the Codex CLI version on a Linux VM, I did not get it to work. Possibly because OpenAI only supports connecting ChatGPT to a desktop installation of Codex?
I have a codex cli instance on a Debian VM connected to ChatGPT on iOS via SSH. That works since.. about a month and has pretty good UX. Before, I used the shellfish terminal and tmux which also worked really good, but to be honest (even though I'm a big terminal fan), ChatGPT on iOS sometimes has a smoother UX than a terminal.
Are you sure ChatGPT on IOS connects directly to the VM? Or via a desktop as the middle man sitting somewhere?
If you really only use ChatGPT on IOS and a VM and nothing else, then I would be curious how you set that up. I do not see a "connect to codex via ssh" in my ChatGPT app. I only see "Connect to a desktop".
Oh HOLY MOLY! Now I see there is not only a "Remote" section in the app but also a "Connection" section where you can add an ssh connection. I need to try that.
Also for future readers: Yes, I'm sure there's no desktop app in the middle. I have dedicated remote VMs that run agents. I don't have them running on the desktop, not even as a middle man.
Wouldn't such language and reasoning from Anthropic be an argument that they needed written permission to train their model on data from websites?
Has any individual somewhere around the world tested this in court by now? Sued Anthropic for copyright infringement because Claude can reproduce information that is only available on their website?
It shouldn't be that expensive, right? If you sue them for - say - $10000 then what would the costs of such a court case be?
Personally, I think "learning" is not a copyright violation. But if they themselves make it one, then they should also face the consequences, no?
I get that many people like such an archive to be around for consumption. Me too. But, keeping emotions aside, I can't find a justification to violate the rights of creators.
I'm sure many people here will have the knee-jerk reaction to immediately downvote this question. But I know there are also thoughtful people on HN. If some of you have ideas about the legal and moral justification for archive.org's actions, I would like to hear them.