Browsers have an absolute insane level of relatively unchecked permissions to do whatever they want on a client.
There's a lot of effort by browser developers to scope creep the browser into essentially being an OS-agnostic tech stack (one where, conveniently, code can be shipped across the network "as necessary", removing a lot of user agency for the software being ran); Chrome being the biggest driver of this, while Firefox has an extremely weak spine in trying to limit it.
It's fairly dire and I wouldn't be surprised if there's a lot more of these side channel attacks in a lot of web APIs.
Unfortunately, real apps and native tech stacks can not only write data to your SSD, they can usually write data to the user directory however they want and they can read it as well!
This is a Linux-centric take. It does not apply for example to iPadOS or to AluminiumOS (coming soon to a Googlebook near you). It applies less and less over time to MacOS.
Yes, if one is committed to the standard Linux desktop, then one must hope that any proprietary apps one might need will continue to be available through the browser, but I'm ready to let the standard Linux desktop go (not right now, but eventually).
It very much applies to macOS, or do you know of a way to know what permissions a sideloaded macOS application will have before opening it that's accessible to regular users?
The very fact that you've qualified your question with "sideloaded" suggests that you are already aware that a non-sideloaded MacOS app is installed into a sandbox that is much more secure than anything available on a standard Linux desktop excepting possibly Qubes and Secureblue, and hardly anyone uses Qubes or Secureblue -- probably for very good reasons.
Yes, and I'm also aware that most macOS apps are still only available as a sideload, where sandboxing is optional and importantly not user visible before the app runs.
I don't know, maybe something about backwards compatibility, maybe nobody can agree on how to do it correctly. It hasn't happened for decades, so I'm not going to hold my breath.
Except you’re not going to install native apps for the vast majority of things you use a browser for. You’re going to use the browser for content consumption and native apps for a few things that need system access.
It's also the technology that will allow software to run without a continuous connection to the server. If you want to break out of a world where companies own your data it's the tech that is needed.
They can, but there's an OS option that basically is "I'm going to say yes, but then effectively do no". Basically it'll pretend to the application that a permission is granted, but then just keep returning empty information or doing nothing with it. So notification perms would then be seen as enabled, but nothing is actually being send to the user.
Unfortunately Google isn't really exposing this to users, so you need something like App Ops or adb to set it up.
If you're using nginx/apache/literally anything that does reverse proxying correctly, this shouldn't be a problem unless you're routing all traffic over default_server rules unstead of server_name (or the equivalent).
They should be stopping this attack at the door (even if only to clean out your logs from scraper door knocks), which is probably why it went unnoticed for years. I don't think anyone would be deploying {A,W}SGI servers on public facing ports these days. Even if only because SSL termination is much easier in the proxy layer.
Also good lord that ARS article is a mess. What the hell happened there? An ASGI server isn't unique to AI or anything, it's just a regular supply chain dependency. I kinda expect better from ARS on stuff like this.
The saving grace here is that people are most commonly doing this for reasons other than as a defense - serving static files efficiently, combining multiple services, caching, DDoS protection, etc. There are certainly some directly exposed FastAPI instances but it’s been against the grain for decades.
Or probably the most straightforward one, which is SSL termination. Most backend software usually has very bad support for HTTPS communication, while it's typically extensively documented for something like nginx. It also catches some other strangeness like making it easier to update the certificate.
The biggest risk is incorrect usage of the default_server directive, the proper way in which to handle it isn't usually taught in most "here's how you use nginx" tutorials. Most usually just have you edit the default server blocks.
Tldr that covers 99% of all cases: you want 2 default server blocks, one on port 80 and one on port 443. The one on port 80 should only return 444 (an internal nginx status code that stops the connection immediately with no response), while the one on port 443 should use ssl_reject_handshake to terminate the SSL connection as quickly as possible without causing strange errors (you also need a self-signed certificate because otherwise openssl refuses to do protocol negotiation correctly, but the cert doesn't actually do anything). After that, specify your actual domains as separate server blocks using server_name (including a separate one for each to do the port 80->443 redirect).
Arguably this should be the default configuration shipped by distros, but it isn't for some reason, which doesn't help matters.
If I’m reading https://github.com/nginx/nginx/pull/966 right (not a given on my phone), just having Nguni in front would help because It’s now filtering the characters which make this attack possible.
But you have to be super careful about defining the mitigations for this one, as for example Cloudflare passes malicious headers as-is without extra configuration, leaving hosts vulnerable when they are assumed to be protected.
Yes. you always want to test any mitigation but Cloudflare and AWS ALBs both blocked non-DNS characters in host headers with no additional configuration when I tested it. It would be surprising if Cloudflare didn’t because the Host header is how they know which customer to route a request to.
Ars has had a depreciating quality the past few years by most accounts. They've been trying a bit harder recently it seems, but shaking off the allure of half baked short form journalism is hard, I guess.
In 2 years the contract is up for renegotiation to a different entity (and there's now plenty of political pressure to go with a different one), so I don't think it's a problem by then.
Tying the process up in the courts for that period is also a political victory, since by the time it'd be resolved, Solvinity wouldn't have the contract anymore anyways.
The FSFE isn't nearly as impractical as the FSF is. Unlike the FSF, they're actually getting results, typically by lobbying politicians and trying to get governments to require that the code made for them is publicly available. From everything I've seen of them, they're much more capable of meeting people where they're at; take this lawsuit as an example.
The FSF wouldn't participate in a lawsuit like this because from the FSFs ideological perspective, the mistake is allowing Apple to have a closed source system to begin with (because they declared victory in the 90s and since then have shifted towards blaming users for not using Free Software); at most you'd see a head-up-ass press release after the lawsuit is settled, because that's what the FSF usually does; probably easier than actually putting in the effort to do anything to advance Free Software politically. The FSFe from what I can read in this post is actually cognizant that Apple actually has a market share and that opening up application development on Apple devices is a major step to ensuring a healthy Free Software ecosystem.
The FSF these days is a decrepit organization whose primary purpose in practice is to enable Richard Stallman to not have to participate in modern society and to host his philosophical screeds. It's issues are so specific to it that in terms of FOSS, they're a historical artifact at most. Even in the US, the SFC does more for the average free software developer (ref. the recent Bambu incident where they stepped up to help a developer from getting legal nastygrams from the company in question.)
> The FSF wouldn't participate in a lawsuit like this because ...
Because in reality the FSF is a WELFARE program for RMS.
Look, I'm done defending the FSF and the GPL. I worked professionally on open source software for over 20 years, but I'm just another former Red Had employee. But oh boy have I seen some stuff, and have seen how the open source sausage is made. I could probably write a wall of text about how the open source world is populated by a bunch of people with various kinds of pathological personality disorders. I certainly consider some of those crazy people my friends, but we have to recognize the nature of these folks.
RMS has to eat. That's why the FSF will never get involved with any big legal controversy. RMS cannot afford the legal expenditure from the modest stream of donations given to the FSF. But even if lawyers were willing to engage pro bono, they get disenfranchised by RMS and his specific quirky personality disorders.
But whatever. In my humble opinion... I highly doubt these European open source zealots will make much progress. On the one hand they say closed source interoperation with GPL code is a violation of the GPL, and on the other hand they say closed source code must interoperate with GPL code, or else... Something something European this-or-that... I think these are nice people, but clearly crazy. Then again it's not quite clear what these crazy people are chasing after? Maybe they merely want API documents, but probably they want to run GNU Hurd on Apple silicon
It's in theory already possible with iDeal from what I can tell (I've seen companies that use subscriptions set up an initial iDeal payment and then convert it into a regular recurring SEPA Direct Debit), but I'm going to assume that the process is kind of messy since I haven't seen many companies implement the system in that way.
Direct Debit is very nice, largely because your bank manages the subscription; companies have to declare the payment ahead of time and if you get balance mixed up for some reason, then the bank will just do the payment whenever your balance is correct if it happens within a week. I've had credit cards decline on subscriptions before because I didn't have enough loaded up on them. Never had that issue with SEPA.
Either that or "credit cards just work", so very few entities bothered until now.
It's a bit more loaded than that. 538 post-Nate Silver had a model setup that was apparently kind of a mess. 538 was apparently sending strange messages to Republican leaning polling agencies, demanding they gave far more detailed audit information than usual (with the implication obviously being that they were fraudulent pollsters), and the guy running the site had fairly openly tuned his model on the assumption people cared about certain talking points. 538 was predicting Biden victories even when the polls were so overwhelmingly against him that not even the most Democratic leaning polling agencies had trust in him; even if you aren't running difficult math, that means something has gone wrong with the model.
(Something which got worse after Harris was picked, although every polling aggregator went barmy - there's suspicions that a lot of polling agencies aggressively normalized their data to avoid being seen as biased, leading to an almost 50/50 split.)
So, I would actually agree with you that 538 was a mess in that period. I would actually trace the first problems back to Enten's departure, but it did get worse when Silver left.
It's just that this particular criticism (that they got it "wrong") doesn't seem very well founded.
npm ci does indeed prevent that. The issue isn't really with npm in specific. Rather, it's with build tools like Microsoft's Oryx, which get pushed in GitHub Actions if you're using Azure App Service. That one by default uses `npm install` on older versions (it's been changed nowadays, but Azure's generated action files have a bad habit of generating with older versions of the actions they're using), even though it's specifically meant for CI usage.
In general, use of npm ci is usually sparsely documented - most node projects you can find just recommend using npm install during the setup, suggesting a failure in promoting it's availability (I only know of it because I got frustrated that the lockfile kept clogging up git commits whenever I added dependencies with what looked like auto-generated build-time junk).
Everywhere in the sense of "I have a USB stick/SD card, what do I format it to so that every major device I'm using can read it".
In practice, every OS has its preferred system and the rest has varying levels of "I guess this works", with FAT32 and exFAT being the only real cross-platform options.
To wit:
* NTFS is only really properly and fully supported on Windows. Apple mounts it read-only. Linux can certainly mount NTFS and do some basic reads and writes. Unfortunately for whatever reason, the Linux fsck tools for NTFS are absolutely terrible, poorly designed and generally can't fix even the most basic of issues. At the same time, mount refuses to work with a partially corrupted filesystem, so if you're dealing with dirty unmounts (where the worst case usually is some unclosed file handle rather than data loss, but this also happens if you try to mount a suspended Windows parititon, which isn't uncommon since Windows hibernates by default and calls it fast boot), that's a boot to Windows just to fix it.
* Apple filesystems basically only work on apple devices. It's technically possible to mount them on Linux, but you end up digging into the guts of a bunch of stuff that Apple usually just masks for you.
* ext4 is only properly read/write under Linux and requires external drivers under Windows (which may not work properly either, as corruption issues are common).
FAT32 is reliable in that any OS can fsck/chkdsk it and properly mount it without needing special drivers, but is hindered by ancient filesize limitations. exFAT, at least for most cases, is the only filesystem you can plug into most devices and expect more or less the same capabilities as FAT32 (read/write support, can fix filesystem corruption.)
Out of the os specific ones, NTFS seems like it has the most potential to be the one filesystem that works everywhere; it's modern, works good-ish on most devices, it's just that the fsck/chkdsk tooling is awful outside of Windows.
There's a name for when a virus scanner finds a program that may have a legitimate purpose, yet is typically bundled into other software in a malicious manner.
It's called a PUP, or Potentially Unwanted Program and most anti-viruses offer to remove them. They can be legitimately installed, but often aren't. (Usually they were shipped in the installers of legitimate software downloaded from sketchy distributors.)
Random AI models being shipped with Chrome is very much a PUP. The user wanted to browse the internet, not use a model. They'd install an extension if they wanted that.
The Ask toolbar was seen as a virus. Mozilla had massive user bleed in Firefox due to installing sponsored extensions in the browser. The only reason this shit isn't regarded the same way is because it's both done by Google and because it's labeled with AI, so all AI bros have to retroactively find an excuse to justify it.
There's a lot of effort by browser developers to scope creep the browser into essentially being an OS-agnostic tech stack (one where, conveniently, code can be shipped across the network "as necessary", removing a lot of user agency for the software being ran); Chrome being the biggest driver of this, while Firefox has an extremely weak spine in trying to limit it.
It's fairly dire and I wouldn't be surprised if there's a lot more of these side channel attacks in a lot of web APIs.
reply