All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.
Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)
This is huge. A lot of these are the underpinnings of modern computer science optimizations. The ACM programming competitions in college are some of my fondest memories!
> A lot of these are the underpinnings of modern computer science optimizations.
Note that older articles have already been open access for a while now:
> April 7, 2022
> ACM has opened the articles published during the first 50 years of its publishing program. These articles, published between 1951 and the end of 2000, are now open and freely available to view and download via the ACM Digital Library.
In a concurrent environment, I wonder if the overhead of wrapping every API call with a synchronized would make this significantly slower than using ConcurrentHashMap.
Thanks. This is actually one of the topics I really want to tackle next.
If we just wrap every API call with synchronized, I'd expect heavy contention (some adaptive spinning and then OS-level park/unpark), so it'll likely bottleneck pretty quickly.
Doing something closer to ConcurrentHashMap (locking per bin rather than globally) could mitigate that.
For the open-addressing table itself, I'm also considering adding lightweight locking at the group level (e.g., a small spinlock per group) so reads stay cheap and writes only lock a narrow region along the probe path.
I think that's a great idea! I just checked one of my larger projects and it 55% ConcurrentHashMap and 45% HashMap so I'd personally benefit from this plan.
RL is still widely used in the advertising industry. Don't let anyone tell you otherwise. When you have millions to billions of visits and you are trying to optimize an outcome RL is very good at that. Add in context with contextual multi-armed bandits and you have something very good at driving people towards purchasing.
It's likely that yes, you will end up with an alias that links you because of a cookie somewhere, or a finger print of the elliptic curve when do do a SSL handshake, or any number of other ways.
The ironic thing is that because of GDPR and CCPA, ad tech companies got really good at "anonymizing" your data. So even if you were to somehow not have an alias linking your various anonymous profiles, you will still end up quickly bucketed into a persona (and multiple audiences) that resemble you quite well. And it's not multiple days of data we're talking about (although it could be), it's minutes and in the case of contextual multi-armed bandits, your persona is likely updates "within" a single page load and you are targeted in ~5ms within the request/response lifecycle of that page load.
The good news is that most data platforms don't keep data around for more than 90 days because then they are automatically compliant with "right to be forgotten" without having to service requests for removal of personal data.
There is definitely a miss-alignment of incentives with the bug bounty platforms. You get a very large number of useless reports which tends to create a lot of noise. Then you have to sift through a ton of noise to once in a while get a serious report. So the platforms up-sell you on using their people to sift through the reports for you. Only these people do not have the domain knowledge expertise to understand your software and dig into the vulnerabilities.
If you want the top-teir "hackers" on the platforms to see your bug bounty program then you have to pay the up-charge for that too, so again miss-alignment of incentives.
The best thing you can do is have an extremely clear bug-bounty program detailing what is in scope and out of scope.
Lastly, I know it's difficult to manage but open source projects should also have a private vulnerability reporting mechanism set up. If you are using Github you can set up your repo with: https://docs.github.com/en/code-security/security-advisories...
One way to correct this misalignment is to give the bounty platform a cut of the bounty. This is how Immunifi works, and I've so far not heard anyone unhappy with communicating with them (though, I of course will not be at all shocked or surprised if a billion people reply to me saying I simply haven't talked to the right people and in fact everyone hates them ;P).
Totally agree. I was just thinking that I wouldn't want this feature for Claude Code but for Codex right now it would be great! I can simply let tasks run in Codex and I know it's going to eventually do what I want. Where as with Claude Code I feel like I have to watch it like a hawk and interrupt it when it goes off the rails.
Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again.
In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).
This. We replaced Hotwire frontend with Inertia and it's night and day.
Unless you work 100% alone (and for a smallish project) hotwire leads to a real mess nobody can work on way before anything else I've ever seen in my life.
I've used turbo/stimulus/hotwire. It's best suited for STATELESS interactions withe the browser/web page. The problem is not all desired user experiences and use cases are stateless. And the ecosystem for hotwire is a minuscule fraction of all the other popular js frameworks.
If you're searching for inventory available its perfect. However if you want to update one thing based on the most recently touched input it becomes more complicated and in all honesty more trouble that it's worth.
Honestly if you're a solo Rails dev, use whatever you want. However the React ecosystem, and really all of the other popular JS ecosystems (vue, ), are very strong and you have so many available options. Stimulus is 2 steps back from jQuery, it inverted the Event delegation pattern. No one else outside of the rails community is using it.
I think the fundamental misunderstanding (for the majority of devs who dont "get hotwire") is that you can very often delegate the statefulness of a given interaction to A: The Server via the database or B: The Browser via localstorage.
If your page can be written with it's state being "reasonably" delegated to one of these two, hotwire is _all you need_. (To be clear, it's more common that you're just doing a bunch of work to duplicate state that already exists in the database/on the server, or handled natively by the browser, and by "delegate" I mean don't-duplicate-for-no-good-reason.)
There are many (but fewer than those who "don't get" hotwire believe) cases where it's more of a headache to delegate state to A or B. In which case you should absolutely pull in react/vue/<insert_js_framework>/etc. My go-to is: https://github.com/skryukov/turbo-mount + react because it minimizes it's footprint on the "omakase-ness" of your rails app.
Stimulus is basically a very small event system with HTML hooks that integrates well with the Rails request lifecycle. I'd love to know if anyone has built anything sophisticated with it because I found it difficult to do anything remotely complex.
I'm a huge rails fanboi but the state of Stimulus and Hotwire make me sad. The concepts are awesome, and I think the execution might even be good. But the documentation is so incredibly horrible that I have a hard time even getting started, and I can't learn enough about it to answer the question of whether or not using it in any given project will end with me painted into a corner.
I feel so validated! When I started learning web dev, I was working through The Odin Project's Rails course. All smooth sailing til I hit the Turbo/Stimulus/Hotwire sections.
I thought I was stupid or just terrible at JS/front-end stuff, because I would read and re-read the same chapter in the Stimulus docs and become more confused.
Now I'm mainly in TS-node/React land, and boy do I miss Rails.
Going against the grain here, but I liked Stimulus so much I lifted it out of Rails and plopped it into a Phoenix app.
I think the problem here is a disconnect of assumptions. Stimulus isn't meant to be an alternative to React.
If your app is (tens of) thousands of lines of JS, and that is all you know a web app to be, then React may be a sensible, battle-tested approach for you.
But if all you need is a few dozen lines of JS to polish the UX of an overwhelmingly server-side app, then Stimulus is a neat way to encapsulate and surface it when desired. In Phoenix, it slots nicely between static HTML views and dynamic LiveViews.
I don't think anyone has ever suggested you should use Stimulus to try to replicate a SPA, and I imagine you'd have a very bad time if you tried.
Are you familiar and adept with React/Vue/Svelte? I haven’t looked at Stimulus or Hotwire much yet. Just picked Rails up again a few weeks ago.
Tailwind and Shadcn (or similar ui) are standard for me now.
Yes. It's also recommended to not use much of it and do almost everything else with turbo drive, or turbo frames, or with turbo streams, or with whichever convoluted magic you can do to avoid it until you can't anymore. Then you use Stimulus. Yes, I know it.
The fact people can't escape JavaScript doesn't stop people from being JS haters.
> The fact people can't escape JavaScript doesn't stop people from being JS haters.
It just creates more of them.
The nice thing about stimulus is that it binds the pages I'm making to the javascript. It's all easy to find.
90% of what I want react for is to update just part of the page. This is simple with Hotwire now. There is no added marshalling/unmarshalling of json -- just regular crud requests the same as everywhere else. There is no second programming language. There is no added toolchain.
Adding in Stimulus and I can do most of the other things I've been wanting to do -- like modifying dropdowns.
The one place I can see React perhaps being better is when something happens on the page and I don't talk to the server. For most of my business applications, this doesn't come up as much. But say I was organizing a schedule, only to submit it to the server at the very end, React might be better at dragging things around, labelling them, then one big update at the end. Maybe it's easy in Hotwire also, I don't know yet.
Most of the reason I've started losing interest in Rails and the DHH cult is their insistence that their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite.
I am maintaining a Rails app with Vite + Interia + Vue, and it's many times easier to manage, develop, especially when working with LLMs that haven't been trained on DHH's new frontend experiments du jour.
Industry standards are not platform standards. React (enabled by Inertia) is in many ways is an industry standard for building UIs on the web today, yet it's not part of the platform. Same with Vite, it's the standard way to bundle on the web.
Decidedly, Import Maps are not used as a standard for dependency management in the web dev industry.
Here's the thing. They could have put up link to a git repository where others can follow along with the maintenance of this project, but here isn't one. There is a list of maintainers explicitly mentioned on this page but no link to the git repository. This leads me to think this project is not about the code but about the people.
It's a package repository. A link to an Ansible repository or whatever doesn't need to be in the first announcement.
> This leads me to think this project is not about the code but about the people.
Trust is of utmost importance to a package repository. Even more so than code. A hostile takeover, like the one that occurred with RubyGems, fundamentally undermines that trust. In contrast, an alternative run by the original maintainers who have built years of trust, represents a positive shift.
Unfortunately, it seems that your conclusion was drawn before your justifications. When you invent justification though, at least make sure you don't undermine your own position. Where's the prominent link to the Git repo on rubygems.org top page?
I think the issue that you overlook is that you assume this group of individuals is trustworthy.
I'm not saying they aren't, but there are a LOT of conflicting opinions about what happened, why it happened, and who was right/wrong.
This it what tends to happen when money gets involved in a project without a clear structure/business plan/guarantees put in place. People just did whatever and made assumptions, and now suddenly the whole community is rocking and rolling thanks to the actions/view points of a select few.
Ah! Good catch. I saw the repo exists but didn't dig into the contents, given that it's (as far as I know) purely a proxy for rubygems at the moment, I figured it would be pretty simple.
I agree they should post the whole source, regardless.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.