The simplicity of Git is awesome. Great article! I had looked at what it would take to find a single file in a remote git repo. I decided against talking the git protocol directly and just checking out the entire repo to get a single file. Reading through this makes me think I may have given up too easily.

I asked a few git hosting providers, and they all said they had private APIs developed internally for the purpose.

In response to the end of the article "it’s important to note that some of these issues exist on other version control system products." I actually have experience helping someone with an issue on BitBucket with PII data that you can't rotate.

Once we eliminated the references in the tree and all forks (they were all private thankfully), we reached out to BitBucket support, and they were able to garbage collect those commits, and purge them to the point where even knowing the git hashes they were not locatable directly.

Github also supports that if you reach out support directly

Specific IDEs is actually the selling point for me as a polyglot developer, that often switches between projects in different languages. When I need to work on a C project, I'm in CLion; when I'm working on a Python project, I'm in PyCharm; when I'm working on Go, I'm in GoLand. I don't have a ton of plugins dragging my single IntelliJ down, I just have what I need when I need it. I could spend a bunch of time tweaking each project with project specific settings, but that eats a lot of my time I could be making features or fixing bugs with.

The other thing it does, it let's their team really focus on polishing a product. For instance with Go, they had a plugin, and it worked okay, but when they came out with GoLand, they really started filling all the gaps, and polishing the Go development experience, making sure all the default plugins for it made a great overall Go development experience by default.

These reasons are I think why you see people excited about a JetBrains Rust IDE in other comment branches of this post. The polish and ease of use. The priority on taking the point of those things that just are slightly annoying. The difference between something cobbled together or a plugin that just has to deal with existing extension points and a fully polished marketable product.

SQLite doesn't have an authentication mechanism to identify users. This seems to me to be a dependency for setting Authorization.

Since SQLite DB is just a file accessed using a library, the authorization limitations would only exist if accessed through the library, any program that could read the file could easily bypass the authorization.

This feels like a separate task/module that would need resolving first.

There may be benefit even if we do RLS with a soft authentication mechanism. In this case I would assume the accessing application would handle the Authorization and then pass that to your extension somehow, which then would filter any subsequent queries with RLS trusting that setting until it was changed. Keep in mind, nothing would prevent the app from setting another user, but this could make it easier to segregate data exposed via a webapp based on the webapp's logged in user.

Thanks for the input. I'll make some previously unstated assumptions, which I should have sent in the first post:

1. the db file is not publicly accessible. it is accessible only to some private application 2. user data is inside the database 3. the application passes some configuration in before the query runs (a la https://www.graphile.org/postgraphile/security/#how-it-works) 4. that configuration identifies the user through some downstream `check constraint` implementation, which currently doesn't exist :)

These assumptions are consistent with your second paragraph, which is my goal.

I think something really important here, is that it has been agreed that Elon Musk is not to be more than 14.9% beneficial owner of the companies common stock. I'm not a lawyer, but this also looks like a tactic saying "Let's give Elon a voice on the board so he doesn't buy controlling interest in the company."

Elon is being forced (or heavily incentivized at least) to liquify Tesla stocks, so he's going to be looking for alternate places to put that money to avoid the consequences of holding on to liquid capital, this limits him from putting too much of it into Twitter, and being more than just a board member.

Gives stockholders & existing board members what they want (retaining control of the business, and makes it harder for Elon to build a competitor), while giving Elon what he wants (influence in the business). This sounds like a win-win.

I find this a good way, where they expose their resources via tools that makes improving OpenStreetMap data with data they have access to easier. This isn't exposing their maps directly, so it does not come with their assumptions.

Unfortunately HIPPA is actually specific in this scenario. I highly doubt file sizes have to do with PHI. However if you can show that they are sending the actual data in the backup, that would be a reportable offense.

Disclaimer: I am not a lawyer, this is not legal advice, YMMV.