Hi @MarkGStacey and @NightMachinary - Thanks for this conversation! I’ll respond with as best I can on both concerns. Please note, too, that I am not an Observable team member:
Security
I work mostly with private, government-owned data. I operate in a context where I cannot install software on my computer, and I cannot use most third-party sites and tools for development and testing. I can, however, use Observable, because it does answer Mark’s concern. Here’s how:
Using teams, I can collaborate with colleagues in completely non-public, but shared coding environments. Using secrets within Teams, I can rest assured that if anyone ever tired to expose our working notebook publicly, that connection would immediately break. While I don’t use the Observable database connectors, it’s a similar principle: your host and port properties are not exposed, but you can open access to whatever data that you wish to evaluate. In my S3 notebook, I agree that it’s something of an ‘exposure’ that my bucket name and file name is there in the config, and I fortunately don’t have to worry about exposing details at this level (as our security team is comfortable with IAM roles and S3 bucket permissions, and we can avoid unwanted access through these protocols). I could very easily, however, just expose text-input fields for bucket name and file name and never would these values be exposed either: access would require a user knows where to point the connection. However, I imagine that database connections should get you where you’re going.
edit: I just caught your concerns here and the points you raise are a bit beyond my capacities to address. Thank you for the clear statement of your challenges! I appreciate learning these pain points as I am slowly building the case to integrate Observable more centrally within my organization.
Longevity
@NightMachinary - This is also a very valid concern. I have a couple of points for your consideration. One is that Observable-as-a-platform is different than Observable-as-a-runtine. Just as you may not be concerned that React.js will ‘go out of business’ (because it’s a technology, not a company per se), so too should you not have to worry about Observable going out of business. As long as the runtime works, you can host and work with your code entirely independently of the platform itself. Now with respect too all of these shared secret protocols and database connectors connected to the Teams working environment: Yes, if the company fails, then it becomes more difficult to work privately (and in a real time co-editing environment). This is part of the advantage of Observable-as-a-platform and it’s also something that I am thinking about a lot in terms of how my organization can use Observable. But at least I am assured that, as long the JS packages that I use work, so too will my notebooks, regardless of the success of Observable-as-a-platform (though I wish the team great success)!
… As a last point of reflection, I would like to point out that it’s sorta similar to Git vs. GitHub. Git is a technology. GitHub is a platform / interface leveraging that tech and adding a lot of extras. There’s not a necessary or direct connection between Git and GitHub (and in many respects, the centralization of code on GitHub is mis-aligned with the essence of Git), and so too you can carry on all day in Git without ever needing GitHub (which is also how I work, for the most part).
Hope this helps! Happy to continue the discussion!