In a reductionist view yeah but blog generators and agent harnesses sit at a different spectrum than an EHR/Excel/whatever other insanely complex edge case ridden work you can think of
I personally like Blender’s Gitea theme better than the rest but I guess that’s subjective. In dark mode I do not like the low contrast Codeberg theme or the default Forgejo theme, but all of the instances custom themes look great.
As far as Git forges go in general though.. tangled is very pretty https://tangled.org/tangled.org/core I think more power user oriented software should be comfortable with compact interfaces
That Blender Gitea theme is really nice! I wonder why exactly it's so much easier on the eyes? In a lot of ways all of these are "just Github" with minor changes, so the one that is actually better really stands out.
This is unbelievable!! At a certain point surely doing things the right way would be easier or more clearly correct? Like, if you were implementing this you’d obviously know that it’s insecure right??
As a current Waterloo student (who is not particularly tied to any specific place). I’m curious about this and I’d like to know more. Why US for 5 years and why back?
Right out of school it was fun and easy to drop everything and go somewhere cool (SF, NY, etc.). Can tell everyone you work for a flashy big tech company, make a ton of money, and have no responsibilities.
But eventually life catches up to you, especially if you have strong family/social roots in Canada. It's not easy to bootstrap that in a new country.
I was also there under a TN Visa and had a few border experiences that rubbed me the wrong way since the TN Visa is a bit hand wavy and up to the border guard at your time of entry. The hostility at times from the border guards didn't make it feel like I was returning "home". Sure, I worked for a company that had an army of lawyers to fix it if anything went wrong but it still leaves you with a sour taste. I can't imagine they're getting any friendlier these days.
Lastly, I didn't mean it like 5 is some magic number - some stay less, some stay more.
Can’t speak for the OP but it’s often about what’s most valuable at different points in life. Depending on where you are in the US, having kids can be a formidable experience. Poor leave, expensive childcare, etc etc. It can change the calculation for whether the extra money in the US is actually worth it.
And to simplify, there’s also really only two reasons to move:
1) more interesting work opportunities; and
2) more money
And the delta on (1) has never been smaller thanks to remote work post-covid (even after all the RTO).
So basically, at some point, you start asking if the extra money is worth it.
(Depending where you come from in Canada, lifestyle in SF might be better overall - but then you can just move back to somewhere else in Canada and have it all.)
I was working in anti-spam at the time, so I was eyeballing a lot of raw email dumps and writing analysis scripts for "anomalous" urls, so it popped up fairly frequently.
The primary problem is we can't search through time via WayBack Machine where a lot of these things have gone. Took me a while the other day to surface the Choco-Banana Shake Hang which Microsoft deleted from their production site.
I noticed the WebKit quirks file even has rules for new websites, like claude.ai.
That feels like a bad idea in my opinion… in my mind it would make sense to wait for Anthropic to address any browser compatibility issues, especially since claude.ai is clearly software that is being regularly worked on.
I can understand quirks for old websites/ones from companies that work very slowly, but this seems strange to me.
The reason stated in the article seems sound to me: if it’s broken ins safari/ff but works in chrome, users conclude that the browser is the problem and switch to chrome.
>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)".
But if it can't talk to the internet, I kind of don't see the issue.
EDIT: Apparently due to how JS and Electron works, Obsidian plugins are just JS blobs that run in the global scope, and can read/write the whole filesystem (limited by user permissions) and make HTTP requests? Can someone confirm/deny this pls?
> But if it can't talk to the internet, I kind of don't see the issue.
No internet access doesn't save you.
With file system access it can delete a file.
Without sudo access it can silently add something to your user's crontab so a few days from now it runs a custom shell script that does anything with internet access. If you're not checking into this sort of thing regularly, you wouldn't know.
It can add something to your user's shell's rc so when you open a new terminal session, a bad side effect happens.
Malware scanning won't protect from these sort of things and every time a new version is available, it's another opportunity for something bad to happen.
To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.
> To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.
While it's not unique to Obsidian, Obsidian not being open source makes it harder to verify their security model. Personally I use a note taking system which has the same problem but all the code I run is visible to me and I can scan it myself.
Installing a plug-in and reviewing its code at that point is one thing. But if the plug-in can be updated withut you knowing, then there’s little guarantee of security.
You can automatically check for updates but it's off by default, and still requires a manual click. Also the new plugin review system automatically scans every release.
Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.
That's why I wrote cyberwriter, my company needs sandboxed apps because we work on sensitive data. Community plugins are too risky running with full system access
It doesn't do anything about first-party malware, but it can help a lot in gauging how dependencies are kept up-to-date and whether they contain any known CVEs, e.g. the same way that e.g. Trivy does and Artifacthub highlights.
I am curious how well this works out in practice for the ecosystem, though. In my experience blanket scans have a good chance to produce false-positives (= CVE exists but doesn't apply to the context it's used in), so the scans need some know-how to interpret correctly, which can lead to a lot of maintainer churn.
Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams.
All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch.
The blog post contains details about the rollout, but it will be a phased approach because it requires changes to the plugin API.
I'm not sure that "Plugins will declare what they access" should be interpreted as a planned sandbox system. My (cynic) interpretation that it's an opt-in honor system, that would give a good overview about well-maintained plugins, but doesn't do anything to restrict undesired API access by malware.
We haven't shared anything about sandboxing yet. Yes, to start disclosures will be opt-in because we have to help thousands of developers with existing plugins migrate.
However, a permissions system alone is not enough. For example if a user allows a plugin with network connections, it would be easy for a plugin to abuse that permission. That's why scanning the code is still necessary to give users trust in the plugin.
Take a look at scorecards on the Community site, you'll see why some issues are not something a permissions system or sandboxing could catch.
Speaking as someone who has been building a business around an Obsidian plugin - I think you're on the right track.
What actually matters is that the plugin developer is pro-social, discloses the behavior, the user accepts that disclosure, and that the user isn't duped by their inability to review all of the code for every update.
Sorry, I think think my comment came off too dismissive.
I do think that self-reports on permission usage are a step in the right direction, and can also help in decentralized uncovering of unintended API access.
However I think with the recent pace of supply chain attacks, I think we'll be in for a rough couple months until a sandboxing system is added.
Hey kepano - can you please grandfather in existing plugin IDs?
Forcing a migration seems really user-unfriendly unless there's a symlink or something.
We have a "caution" score because our plugin (system3-relay) has a 3 in it (part of our business name), and we have thousands of daily active users that would need to essentially download a new plugin if we change it.
Yes. That's fixed! There will be some false positives and false negatives as we iron out kinks in the new system, but we're working feverishly in the #plugin-dev channel on Obsidian Discord to help devs. Please be patient, we're only a handful of people working on it :)
Obviously this wouldn’t be compatible with existing plugins, so I’d separate legacy plugins and new plugins, and add a lot of friction to install the legacy plugins, which will be deprecated at some point.
Security and authorization is just hard and at one point if you are designing a platform you have to ask yourself if it's worth the risk for the sake of flexibility. To plan for a perfectly safe system is a hopeless proposition.
IMO this is an outdated view. Existing developer platforms have had to rely on static heuristics and capability-based permission systems, but now AI can run at scale and surface a lot of user-unfriendly intent that wasn't possible before.
The permission system are definitely useful for hard limits - but AI review can surface way more detail (what kinds of things are actually sent over the network, etc).
In fact, a combination of the two is likely to be even more effective. As another commenter mentioned, heuristic-based analysis can generate false positives, but that's less of a problem if it's possible to analyze these in an additional AI step.
Also worth pointing out that the N isn't too terribly large: the article says that the ecosystem has about 4000 plugins and themes? With that volume, you could almost reasonably just use static analysis to flag suspicious plugins (saving tokens), have an AI do a pre-analysis and pass to a human for final decision-making.
reply