trestacos

I strongly agree! I think occurrences like these are going to be common when using platforms where we assume that creators will run security checks after the fact. In another comment here, lovable is say that app creators are culpable because they didn't take action to fix security issues.

I'm the creator of Skape - an app building platform where the security is baked into the platform itself. Login and sharing data with other users all happens in the platform. This doesn't mean "your app shows its own UI and then feeds username/password to a login service" - I mean that Skape's UI handles login, and then while you use your app, Skape routes your data requests to your database. The app is treated as untrusted by the platform, which means app creators and users have to worry a lot less about the security of vibe coded apps.

I think that this is a better approach to security that will allow users to trust the software on the skape platform to a higher degree.

Check it out - https://skape.run/

As someone looking to use supabase for a project, I'd love to learn more about what you mean by supabase rots - did you run into scaling problems?

+1 "alchemy of air" is a great read. The angle that would be most interesting to the HN crowd is that it exposed me to how much innovation was happening in chemistry in this pre-WWI era. Reminds me a bit of silicon valley.

The also a fascinating look at how the inventors got heavily caught up in WWI and WWII due to being in Germany and how tied up their industry became with government. Interesting to reflect on in current times.

Truly a great book.

Pikapods looks to be running containers for you, preconfigured for the self hosted apps they support. That's a cool service, I assume there are other similar services around.

The concept I'm thinking about is different - it doesn't run any app code on the server, the apps are SPAs that run in the browser only (no backend supporting code), and then the server just syncs the data from the apps. This means the apps can focus on building ux/business logic and not worry about database, how data gets to/from clients, identity, etc. Somewhat like firebase but where the users pays for the server, not the app. That should hopefully be simpler for developers, and theres a lot less likelihood of issues with server config/etc (although presumably pikapod will handle that). It should also be cheaper since you're not constantly running a container, just storing data.

I'm not sure if it's a useful concept or not yet :)

I've been thinking about building a service that makes it easy to self host apps like this. I'm curious if you'd find it useful.

It would host webapps like yours that use in browser sqlite to store data, then the service provide a sync their sqlite data across different devices. The user not the app would pay for the storage of the data, so they would own their data. And you can use CSP to lock down the app from sharing with other domains, meaning an app can't leak your data.

The service would handle identity (only you can access your sqlite data - the app just ) and could provide an app store like experience with different apps of this type.

Sort of like a firebase style backend as a service, but the user would own the data instead of the app.

Practical engineering has a good detailed walkthrough of what happened at Oroville dam from an engineering perspective: https://youtu.be/jxNM4DGBRMU

Thanks for finding/sharing those links. As I read them they reminded me a lot of what I've been seeing as I have been using Remix (remix.run)

For example: in "how to update content", they discuss path dependent updates. Those are how remix does all it's updates - they use nested routes, so it knows it only needs to update a part of the page (eg only update the content of the page, leaving the nav alone, since an update occured only in the content part of the page)

I think the htmx folks would have a lot of issues with remix but I think remix takes a lot of the best of both worlds. Remix focuses on using basic html/http concepts and layering some smart JavaScript on top of that.

To return the favor, here's a couple docs I found helpful:

https://remix.run/docs/en/v1/tutorials/jokes - this is their advanced tutorial and it's a bit long but once you get past the setup steps it's a really well written introduction to the concepts of remix through useful examples. One of the better tutorials I've ever read.

And then two of their technical docs which are a bit hidden in their site but useful: https://remix.run/docs/en/v1/pages/philosophy

https://remix.run/docs/en/v1/pages/technical-explanation

The key concepts is remix is understanding the loader(), UI component, and action() interactions and how those work with minimal code changes in: 1) server side only mode (with only raw html served) 2) server + smart JS client mode

I think another option here is for email masking services to allow other services to ask if a user has registered at their site before. Details: https://dev.to/stephensisk/throwaway-email-blocklists-want-t...

I'd be happy to work on building that for my service if someone is interested in using it.

I think your point about mozilla's pricing being too cheap is an interesting one. I don't think of the pricing as $1 - I think it as $1/month, so it builds over time. But clearly it would be a bigger deterrent if it cost more.

I think blocking these email masking services and treating them exactly like throwaway email services is the wrong way to go since I think a lot of users want to use something like this. (discloure: I'm working on https://www.thxnothx.com which is also an email masking service combined with some other features)

A fundamental part of charles' argument is that in order to sell ads, facebook must encourage you to set your profile settings to public. That's not the case. It doesn't matter whether you've set your profile to fully private - Facebook's privacy settings don't affect whether or not marketers can target you with ads. In fact, in that regard facebook is incented to protect your privacy so that you'll be comfortable putting more information in the site, which they can then use for better targeting. Since marketers don't get specific information about you when you're targeted, your privacy hasn't been breached in doing so.

This doesn't change that people should be very careful about their privacy settings, but the fact that facebook does targeted ads doesn't mean they have incentives to encourage you to make everything you post public.

I think Charles is right to be concerned about the current state of privacy in social media, but I take issue with his statement that facebook is deliberately making it harder to make your content private. If you click on Privacy setting in facebook today the first thing you're greeted with is a big control asking you if you want your profile to be public /friends/custom. But first you have to care enough to click on it.

Building social network privacy controls is not an easy problem b/c people don't want to do the extra work that's involved in setting privacy on things that they post AND it's confusing. Most people just don't want to choose a circle for their 300 fb friends.

Facebook has gone through many iterations of privacy controls - https://blog.facebook.com/blog.php?post=391922327130 goes into some of that history. Some of them even included google circle-like functionality for privacy. No one used them.

I'm not saying that these controls couldn't be improved, but the point here is that privacy controls take work from users. Until society as a whole is aware of these issues (and Girls Around Me does a great job of it :), people aren't going to invest the time to do it.

TL;DR - building privacy controls are hard. The industry as a whole needs to improve them, but society also needs to learn to care about their privacy so they actually use what's available to them.