HN

Comments (38)

• Menu

  jdub
  (c.f. other comments about confusing misuse of security terminology)An easy way to remember the difference between the As in AAA: Who is your daddy, and what does he do? ^ authentication ^ authorisation And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad.:-)
• Menu

  sandeepkd
  Got drawn to the topic, however usage of authentication and authorization seem like misnomer here, the core topic seems to be data ownershipThe concept on a surface level to have ownership over the data makes a lot of sense and to a large part the support exists in a fragmented manner across the different providers/applications.The concrete idea of user having a database and then authorizing that to the service is highly impractical. It might be applied for experimentation purposes in highly controlled environment but cant scale beyond that.1. Databases require maintenance, backups, failover2. Schema update are nightmares. No one is ever comfortable with it, specially the bigger you are.3. Authorization seems to be following one to many pattern here, one database and multiple applications. Its a no go in case of update operations
• Menu

  pakl
  So many tools and libraries combine authorization and authentication, and it’s hard to find an authorization server that lets you outsource identity.(All too often the underspecified abbreviation “auth” is used to cover both.)Shameless plug: My colleagues and I implemented a minimal authorization server that lets you leverage a trusted identity provider of your choice (like Entra ID or even Auth0/Okta) and handle authorization. It looks up what roles and permissions the identified user should be able to have/grant and issues tokens containing that authorization.https://github.com/DMGT-TECH/the-usher-server
• Menu

  _def
  We are back to File->Open I guess. We could use native applications instead of web apps while we're at it.Sadly this approach does not work for a lot of (web) apps.
• anon
  undefined
• Menu

  ebiester
  1. How do you get around performance issues? If I have a difficult join and you have a slow database, or you have a flaky connection, how can I debug the problem on my end?2. What stops me (or any attacker) from exploiting your lack of security? Are you 100% sure you are secure?3. You mention collaboration - How does this work at a company level if we have many users and need to control access - the company is the entity with rights to the data in this case.
• Menu

  smallerfish
  I've been hacking on my own task manager on-and-off for years (https://the.do.zone). It has no database; the primary store is the browser, and you can optionally sync to local file system (if using chrome), dropbox, or google drive (less optimal for my needs, because their js oauth implementation is very conservative about token length.) It has some crude but functional diff resolution, so that you can sync across multiple machines. Browsers _could_ provide better tooling to make this kind of app architecture more convenient to write; and theoretically you could imagine cloud providers providing some kind of standard for datastores. But there's no market for it; non techies really don't care about the location of their data to any great extent.
• explodingwaffle
  I really like this concept (though the post is terribly named as others have said). "Databases that are easy to make as documents" is so obvious that you wonder why it isn't more of a thing. Add in "untitled" databases that live in a session/browser so you can "try before you buy", maybe the option for single file databases with no intermediary/service (so you have a Databases folder that is as messy as your Downloads folder... but is that really so bad? better than a password manager full of garbage services IMO), and you basically get EASY seperation between application and data, which is Good for a lot of reasons (lock-in, ownership etc)
• Menu

  hankbond
  I feel like this blends two discrete things1. Can I have access to my data (the side effects of my interaction with an application) in a portable way?2. Can I stop or prevent others (like the application author) from having access to my data?I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in this article but I'm not so sure how practical it is. I don't know how much overlap there is between "author has to run application a central server" (can't just be a local app) and "author must not retain data".Seems like a really awkward space to inhabit.
• brabel
  The idea of apps accessing a database directly instead of going through an API keeps popping up every few years. It never works. And the reason is exactly about authorization. Google CouchApps and read the post they wrote about why doing that is a very bad idea, despite sounding awesome without spending too much thought on it.
• zkmon
  Absolutely. A service has no business to know who you are. They should only care if the user has authorization.Authentication has historical reasons. Employee access, citizen services etc all are identity based. Identity was translated into authorisation for multiple services instead of each service requiring it's own authorisation.
• sqemo
  If people manage their own data, that essentially means each person has their own database. And a database has to be connected to an application. Whenever the database schema changes, the application's CRUD operations have to be updated as well.In the end, it seems likely that everyone will develop and maintain their own web application, and if others need access to their data, they'll expose it through APIs.
• m463
  I remember all the confusion when I was first learning secure connection stuff, like sslBecause when I saw "auth" ... was it authentication or authorization?
• jdthedisciple
  Good idea, but how is it supposed to be practical for non-technical users?
• warkdarrior
  Not sure this does anything for data portability, since apps will just store the data as encrypted & signed BLOBs.
• ashleyn
  Isn't this the core idea behind atproto?
• Menu

  esafak
  > It’s your data! You shouldn’t have to prove to anyone else that you have the right to access it.How does the service know who you are? That's the point of authentication. Once that question is settled, the service can decide what you are authorized to do. You need both.