StewardMcOy

I checked it out a while back. It still requires you to write two different UIs in two different frameworks: SwiftUI or Appkit on Mac, and WinUI on Windows. It's just that now you can write WinUI code in Swift instead of C#.

I may be misreading it, but I believe the third option the EU is expects from Meta is non-targeted advertising.

The article is missing a lot of context. The Video Game History Foundation (VGHF) has gone into this in great detail on their podcast, and slightly less detail on their blog. In summary:

Every three years, the US Copyright Office considers petitions for exemptions to the DMCA. The big famous example that everyone talks about is in 2015, teachers won the right to bypass DVD copy protection to preserve teaching materials. This exemption had been rejected at least twice previously, but they finally won approval in 2015.

Every three years though, it's a fight. Previous exemptions can also be withdrawn during these proceedings if the Copyright Office or the Librarian of Congress believes that the exemptions are not working as planned and are harming the market.

For a long time now, folks like the Internet Archive have been petitioning to legally allow digital lending of all kinds of content, including video games. This is far from the first time this exemption has been considered. However, these proceedings include testimony and discussion, and the Entertainment Software Association (ESA) always sends lobbyists to oppose the exemptions.

In the past, one of their main arguments that worked was that those who wanted to allow digital lending were customers and enthusiasts who wanted to open their own digital arcades. There was no serious scholarship behind it.

They also were able to imply that video games weren't culturally important like books or movies because they were purely entertainment, and therefore not worth studying or preserving. And this argument worked because indeed, the Registrar of Copyrights saw video games as lesser cultural artifacts.

That's one of the reasons why organizations like the VGHF became so important to the fight. By proving that there is an academic community and non-profits engaged in treating video games as seriously as they deserve. Because of that the ESA shifted its argument completely to the economic harms to the retro game market.

To counteract that argument, the VGHF performed a study last year showed that 87% of video games are no longer commercially available, so there's there's no market to ruin if those 87% were allowed to lend. They even proposed a lot of safeguards to limit the number of copies lent and DRM schemes to prevent borrowers from dumping the ROMs (which are out there anyway).

The ESA countered that those games would still be competing with retro games that are still being sold on the market, and that the protections weren't good enough. DRM can be cracked, and they don't trust the people who want to lend the games to not introduce side-channels to get around the restrictions. In their argument, only the rights holders can properly protect their games, and only with help from the DMCA.

It's worth noting that the Registrar of Copyright is famously even more strict than rights holders at these arguments sometimes. In 2012, they denied the request for teachers to break DVD encryption, even though lobbyists for the motion picture industry said they would accept it.

And so that's what this news is about. Despite the lobbying and the studies, they sided with the ECA, seemingly taking their arguments all at face value.

I should also note that publishers do often go after libraries for lending books. It's often said in these circles that if lending books through a library weren't already common when the DMCA was enacted, we'd have to fight just as hard every 3 years to get exemptions for what libraries have always done, and we still probably wouldn't get everything.

If you read the article, they went through the casa audit, found that it did not improve the security of their app, and came to the conclusion it wasn't worth the time and now money to do it a second time.

> if Google supports this, and if it doesn’t then I agree they should drop the support altogether

Last time I used it, the file picker was by file, not folder, and was fairly janky. By that I mean it was slow and cumbersome to use. Selecting one file was bad enough, let alone multiple.

But selecting an entire folder would definitely be better, assuming that the experience could be much improved. I still think there needs to be a way to bypass it for apps that truly need access to every single file--even at the risk of attackers exploiting the app or the developer deciding to turn evil--but that's getting sidetracked from the real argument. So for now, let's assume I agree that the select a folder solution is perfect.

The real issue is that Google should not be the arbiter of what apps are allowed that kind of access, and they certainly shouldn't be making small developers jump through the expensive, ineffective CASA hoop to get it.

That's the real reason iA's discontinuing development on Android, and they're right to do so. Google Drive should have a permissions model that allows for users to control how much access an app should have. That would solve the issue without the unnecessary bureaucracy, the mistakes (like suggesting an editor be read-only), and added expense that other platforms don't put on third-party developers.

iggldiggl makes some good points about APIs not being flexible enough, but I also have to ask why go through the complexities of extra APIs? If I'm installing an editor and using it to open my files, I already trust it implicitly with all of my data. That means I also trust it to be reasonably free of RCEs that could modify or exfiltrate my data.

I could see your point if this was some fly-by-night web app accessing Google documents. But this is a native app I'm running on my phone or computer. I may have legitimate reasons to access those photos, to embed them into a document.

> With the S3 API, you usually create one or multiple buckets per app – perhaps even one bucket per user. Your app manages those buckets, so it’s natural that it has access to the whole thing. (You can ask users to plug in their own S3 buckets, but that’s also not something I’d expect from iA.)

Then I think we have completely opposite expectations of what a native editor should do here. I don't want to use iA to create an app-specific folder for all of its files, I want to use it to edit all of my existing files in all of my buckets. Who organizes their files by app? Imagine if VS Code could only edit projects in a folder it created to manage files? What about Photoshop? Should I be forced to save images in the Photoshop folder and then move them to my VS Code folder?

I would never "create one or multiple buckets per app," because my life isn't app-centric, it's document-centric.

On S3, I organize my buckets by project, or sometimes by client. On Docs, that's how I organize my folders. If I download a new editor, I expect it to be able to edit any and all of the files without fuss, whether they're on my local disk, on S3, or on Google Drive.

If I'm running an editor, it really does need to "access everything I have in there," including files, created by other apps or uploaded by the user directly.

EDIT: I'm not trying to question the intentions of those who think apps that access all files should be more secure. But the current process is untenable for independent developers, and in my experience, does little to actually improve the security of the app. iA is correct to drop drive support rather than attempt to shoehorn their app into a scope it's not designed for or waste time and money jumping through these useless hoops.

Which is why I said

> I suspect this is why Google took away the free option and are requiring a review by a security lab.

> How so? (I agree that the readonly category doesn’t work for iA, but drive.file should be fine IMO.)

Arguably, I'm not as familiar with iA as I should be, having only tried it briefly a while ago, but IIRC it basically mounts your file store as if it were a filesystem and allows you to completely manage files. Add, rename, delete, etc. And it's not just limited to iA's App's data. Part of the sales point is to be able to go between iA and Google Docs.

And it allows you to search for a string in every file in a folder. Sure, it has to download every file to do that, and that can be a bad idea, but it if you have a folder of 100 files, 100 KB each, that's reasonable. But with drive.file, what are you going to do? Show a picker for each of those 100 files?

And this is for a native app. It would have to load up a web view to show the picker.

> With S3, you only get access to your app’s data, not everything user has.

This is incorrect. With the S3 API, you could implement the search every file in a folder feature I mentioned above, no pickers required. Just use ListObjects (or ListBucket) along with GetObject.

And again, Google is locking this kind of access behind a CASA review, and while I don't want to insult anyone's intentions, CASA review is fairly useless. Even the paid option is more security theater than anything else. And it's a burden put on developers that other services don't require.

Strong disagree.

Part of my disagreement comes from the fact that the process is inconsistent and time-consuming from Google's end. If you read more of the article, you can get a glimpse of how poorly it's run. And iA have been lucky here. Some apps submit to Google for OAuth approval and get stuck waiting for approval for years.

But another part comes from the fact that drive.file access is not enough for some apps, and iA Writer falls into that category. Some apps really do need full access. (But Google told them they only need read-only access, lol.)

Additionally, having been though the CASA process, it has been pure security theater. No offense to the people working on it, because I'm sure they have good intentions, but letting developers run a python script on their app to self-report vulnerabilities really doesn't solve anything. I suspect this is why Google took away the free option and are requiring a review by a security lab.

The problems with this is that Google only guarantees a minimum cost, not a maximum cost, and that not every company is in a position to let the lab Google has partnered with see their code. And finally, I'm skeptical at how much a security lab is going to find with a quick check on a small payment.

And frankly, Google Drive access is not worth the cost. Even if it's $500/year in fees, + time working with the lab (which, as iA pointed out, can be a huge opportunity cost), in most cases, the kinds of apps that need full access won't suffer $500/year in damages by removing Google Drive support.

And Google Drive doesn't exist in a vacuum. There are other cloud storage solutions out there. Amazon doesn't make developers jump through their ridiculous hoops to access the S3 API.

As someone who has worked on large projects in both Swift and Rust, I have to disagree with the author about error handling. It's not perfect, but Rust's use of Result and syntactic sugar is probably the best solution to error handling I've ever used. try/catch (or in Swift's case do/catch) is more disruptive to the program flow. And prior to Swift 6, throws in Swift were untyped.

(Yes, there's arguments that untyped throws are better for library code because it leaves you more room to add more errors as you become aware of the need for them without breaking the contract with your users, but really, client code is going to be written to the errors you're throwing anyway (i.e. Hyrum's Law). I much prefer my errors to be typed so that if an error is added, the library version has to be bumped to indicate the new incompatibility with old code. And for my own, non-library code, typed errors make sure I'm handling all the error cases.)

There's a nugget of truth that Oregon's decriminalization drew people to the state. However, free access to treatment centers wasn't part of that. Badlucklottery is correct that Oregon did not have the treatment programs, even for the people already living in the state.

And there's a lot of reasons for this. Measure 110, which decriminalized possession and usage of drugs, envisioned funding treatment with money from the tax on legal marijuana sales. There are a variety of reasons it failed, but the tl;dr is that it took $100 million from other state programs handed it to the state, and said, "Here you go. Create treatment programs." And the state replied, "But how do we do that?" The legislative branches of the Oregon state government is generally incompetent at administering programs it's been running for years (e.g. public defense). They had no idea how to even go about creating a treatment program or what one even looked like.

And Measure 110 also created a weird bureaucratic structure for dispersing the funds across multiple entities. IIRC 10% would go to the cities. And there's some 200+ cities. I'm sure they tried to allocate the money proportionally, but imagine being a small or medium sized city and the government says, "here's $30,000 for you to establish a drug treatment program." What are you going to do with that? Probably look at it, confused, and put it in a bank account where you'll forget about it.

There were lots of other reasons the attempts to establish treatment programs failed. NIMBYism of people not wanting treatment centers near them, for one. For another, few people ever actually expressed interest in treatment, which became a topic of much time-consuming debate about why we're spending this money on programs addicts don't want. And part of that was because the police basically never enforced the part of the law where they would ticket public users. The users would either pay a fine or call a substance abuse hotline. There are multiple reasons the police never felt it was worth their time to hand out the citations, and that's a topic for another time, but the fact that the treatment centers were being funded by tax money that went to law enforcement before decriminalization probably didn't help.

So yeah, can't swamp treatment facilities that don't exist.

AI artwork can definitely be more a distraction than a benefit for an article, especially if it's an image that you would never accept from a human artist.

For me personally, I tend to notice and obsess over an image's details when I see something's off. When AI art catches my attention this way, I end up going over it for a few minutes, which detracts from the time I have to read the actual article. In some cases, I just decide I've spent too much time and close the tab.

The image should be there to support your article, not distract from it. If you're going to use AI art, make sure it's indistinguishable from non-AI art.

While I freely admit I am frightened by the possible impacts of this ruling, I do not believe that it has, in this case, impaired my ability to look at the situation logically.

That said, as I mentioned in a different reply, I should have stuck to the legal implications around impeachment, rather than the practical. This decision states that the only remedy for a president breaking some laws is impeachment. At the same time, it says the president now has a legal, if not entirely reliable, means to avoid impeachment: Order the military to kill those who would impeach them.

Yes, that was always a theoretically practical option, but now it's also a legal option, and that's bad. A strong nation requires a strong legal system.