I’m Hursh, cofounder and CTO of The Browser Company (the company that makes Arc). Even though no users were affected and we patched it right away, the hypothetical depth of this vulnerability is unacceptable. We’ve written up some technical details and how we’ll improve in the future (including moving off Firebase and setting up a proper bug bounty program) here: https://arc.net/blog/CVE-2024-45489-incident-response.
I'm really sorry about this, both the vuln itself and the delayed comms around it, and really appreciate all the feedback here – everything from disappointment to outrage to encouragement. It holds us accountable to do better, and makes sure we prioritize this moving forward. Thank you so much.
Was the post written for HN users only? I cannot see it on your blog page (https://arc.net/blog). It’s not posted on your twitter either. Your whole handling seems to be responding only if there is enough noise about it.
Hursh, can you please respond to the above commenter? As an early adopter, I find it fairly troubling to see a company that touts transparency hide the blog post and only publicly "own up to it" within the confines of a single HN thread.
Security bulletin is posted up top on the blog page now, but I have to say it doesn't exactly give me a warm and fuzzy feeling.
It falls a bit flat for me where you address the tracking of domains visited by users, I don't think this accurately addresses or identifies the core issues. When you say "this is against our privacy policy and should have never been in the product to begin with"--okay, so how did get there? This wasn't a data leak due to a bug it was an intentionally designed feature that made its way through any review process which might be in place to production without being challenged. What processes will you put in place to prevent future hidden violations of your stated policies?
Edit just to say, dubious as I am I sincerely hope Arc can overcome these issues and succeed. We desparately need more browsers, badly enough that I'll even settle for a Chromium-based one as long as it isn't made by Microsoft.
Right now You and Arc are advertising it's ideal to position posts such as "Hidden Features in Arc Search" to users but security bulletins and remediations are something that need a hidden stopgap until you've scrambled to build an alternative site to hide them away at instead.
Browser security is more than finding the best PR strategy, it's a mindset that prioritizes the user's well being over the product's image. I've deleted my account and uninstalled Arc. Not because of the issue in itself, but because it's clear what the response has been aiming to protect (not my data).
The sibling comment to this by sieabahlpark is already dead but to respond in case they get a chance to read the thread again anways:
The engineers already closed the hole, the blog post was already published, more work was (/is still?) going to be done to make a new site to hide them in. I wasn't asking for them to move engineers off patching to blog posting, I was asking for the already created blog posting to be made as visible in the blog the same as the posts were (which is now the case, so at least there is that).
In regards to whether or not they did analysis to show it wasn't exploited that was indeed nice to see but you still have to make the post visible anyways because you're not always right, even if you're one of the biggest companies in the world https://www.theregister.com/2024/09/17/microsoft_zero_day_sp... The measure to meet here is transparency, not perfection.
And no, I wasn't really sitting around waiting for a good opportunity to delete my account and uninstall my main browser. That would be... very odd? I'm free to change browser without a reason to blame haha. I didn't say what I was switching to either (it's quite irrelevant to the topic), which can certainly be more than one of 2 options you have quips for. Regardless which option, the measure to meet here is again not perfection but transparency and yes, others do meet that well and above how Arc did in this case.
More than anything, the reason for responding is less to argue about most of those points (I even debate just removing them now as they may detract from the point) and more to point out "real" transparency on security incidents (not just what a PR person would say gives the best image) is as big a factor in trusting a company with your data as their actual response to vulnerabilities. It doesn't matter that a company looks great 100% of the time they tell you about things if you know they are being intentionally stingy on showing you anything about it since you now have no way to trust they'd show you the bad anyways.
(repeat of the above response type. Sorry if this breaks a rule or something Dang, but it's a pretty tame/decent conversation)
This is still responding to a different complaint. The operational performance of "optimally distributing" the message, or however you want to word it, on was/is both imperfect and perfectly fine at the same time. Where the ball was dropped was in responding to a complaint about how the posting was specially hidden where the communicated action was how it will be shown on a different site in the future in place of acknowledging it should be visible as a normal post currently.
When the alarms are going off you're going to be slow, you're going to make the wrong decision on something minor, you're going to wish you had done x by y point in time looking back, you're going to have been imperfect. All that kind of stuff was handled fine (from what I can tell) here. The disappointment in transparency was in deflecting a presented highlight in how to fix a visibility issue instead of outright acknowledging it was a miss.
My message was/is about how that's not cool. Not that their handling of the issue itself was bad or an expectation of apology or expectation more resources should have been put on doing x, y, or z. Just that deflecting callouts on security communication issues with deferrals and redirection is not a cool way to handle security communication. They've since changed it, which is cool of them, but the damage was done with me (and maybe some others) in the meantime. Maybe in the future they handle that differently, maybe they don't, but for now I lost the trust I had that they always will, even when nobody is looking, since they didn't even when they knew people were.
Not a good look it not being on the main page! I personally use [zen browser](https://github.com/zen-browser/desktop); I like the ideas of Arc, but it always seemed sketchy to me, especially it being Chromium-based and closed-source.
I used Arc for a while because despite my misgivings about using a browser that requires an account etc the workflow was very good for me
I started moving to Zen about a week ago, hearing about this vulnerability yesterday and especially seeing their reaction to it I know I made the right choice in leaving Arc.
Hell despite missing tab groups, Zen browser is the only browser that finally had a "good enough" vertical tabs implementation, which allowed me to finally drop Edge as my main browser.
Hi Hursh, I'm Tom. A couple friends use Arc and they like it, so I had considered switching to it myself. Now, I won't, not really because of this vulnerability itself (startups make mistakes), but because you paid a measly $2k bounty for a bug that owns, in a dangerous way, all of your users. I won't use a browser made by a vendor who takes the security of their users this unseriously.
By the way, I don't know for sure, but given the severity I suspect on the black market this bug would have gone for a _lot_ more than $2k.
Selling vulnerability on the black market is immoral and may be illegal. The goal of bug bounty programs was initially to signal "we won't sue white hat researchers who disclose their findings to us", when did it evolve into "pay me more than criminals would, or else"?
Let's set aside morality for a second. There is a reason low payouts are bad without even having to consider the black market: it pushes people to search for bugs in a competitor's app that pays more instead of in your app!
If your app is paying out $2K and a competing app pays out $100K, why would anyone bother searching for bugs in your app? Every minute spent researching your app pay 1/50th of what you'd get searching in the competing app (unless your app has 50x more bugs I suppose, but perhaps then you have bigger problems...).
I'm always so confused by the negative responses to people asking for higher bug bounties. It feels like it still comes from this weird entitlement that researchers owe you the bug report. Perhaps they do. But you know what they definitely don't owe you? Looking for new bugs! Ultimately this attitude always leads to the same place: the places that pay more protect their users better. It is thus completely reasonable to decide not to use a product as a user if the company that makes the product isn't paying high bug bounties. It's the same as discovering that a restaurant is cheeping out on health inspections and deciding to no longer eat there.
Bug bounties are always in relation to severity, number of users potentially at risk, and market cap. A browser operating at a deficit from a small company with a small market share cannot pay 100k even if they wanted to.
If you and a couple friends released an app that had 50k users and you’d not even broken even, can I claim my 100k by finding a critical RCE?
No, because you probably haven’t bothered to find said CVE. There’s a strange refusal to understand the simplest market considerations here. I understand it sucks and you may not be able to afford it, but the consequence, regardless of all the reasons you can give, is that you will get less of the right kind of attention (security researchers). Now, you can hope that you will also get less of the wrong kind of attention too, and if you’re lucky all of these will scale together. Or, alternatively, you can for example not start by introducing features like Boosts that have a higher probability of adding security vulnerabilities, counter-acting the initial benefit of riding in Chrome’s security by using the same engine. Browsers are particularly sensitive products. It’s a tough space because you’re asking users to live their life in there. In theory using Chromium as a base should be a good hack to be able to do this while plausibly offering comparable security to the well established players.
Long story short, there are ways to creatively solve this problem, or avoid it, but simply exclaiming “well it would be too hard to do the necessary thing” is probably not a good solution.
lol, that’s not how this works, that’s not how any of this works…
you cannot demand more than someone is willing to or able to pay, either a researcher out there will spend some time on it because it’s a relatively new contender to the market and they’re hoping for low hanging fruit, or they won’t.
obviously the bounty was enough for someone to look at it and get paid out for a find, otherwise we wouldn’t be having this conversation. trying to argue that they should set a bounty high enough to make it worth your time is pointless and a funny stance to take. feel free to ignore it or be upset that they aren’t offering enough to make you feel secure, it’s not going to make 100k appear out of thin air.
I’m not a security researcher, so it’s really not about me. You seem to be confused about what we’re even arguing about, this discussion started because someone said they wouldn’t use this browser because the low bug bounty amount represents that the company isn’t taking security seriously. My posts simply defend why this is a perfectly reasonable stance to take. They are not me demanding an increase in bug bounties so that I will work on them. A good trick if you’re ever confused about a discussion is to simply scroll up and read the posts, I’ll make it even easier for you, this is where it starts: https://news.ycombinator.com/item?id=41606272
Secondly, in a true demonstration of confusion, if you read my posts they demand nothing. They simply state what are likely outcomes of certain choices. I’m not sure how to possibly make the stance of “if you pay smaller bug bounties in a market that has other offerings, you will get less research focused on your product” any simpler. It seems fairly straightforward… and the existence of one bug report does not somehow “disprove” this. Why not make the bug bounty $1 otherwise? Oh, is that a ridiculous suggestion? Because that might not be a worthwhile enough incentive perhaps? But who are you to dictate what is and isn’t a worthwhile incentive. “That’s not how this works. That’s not how any of this works…”
> “either a researcher out there will spend some time on it […] or they won’t.”
Yes, I agree with this truism that they either will spend time on it or they won’t. Interestingly, this is true in all scenarios. My point is how to optimize researchers spending time on your product (which in theory you are inclined to do if your are offering a bounty), and I then separately even make suggestions for how to possibly require less attention by making safer choices and being able to “ride” on another project’s bug bounties.
But again, the simplest point here is that the position of “we offer low bug bounties because that is what we can afford” is fine, it’s just also absolutely defensible to be completely turned off by it as a potential user of that product, for the likely security implications of that position.
Put it this way. If someone got hold of the vuln and exploited all the users and they all sued you, how much would it cost to defend yourself in court (not even considering winning or losing)
Right, part of the idea is to close the gap in incentives for white hats looking for vulnerabilities to report and black hats looking for the same to exploit. You don't have to beat the black market price of a vuln because that route is much riskier, but somewhere at least in the same order of magnitude sounds decent.
It's not about viewing security researchers as sociopaths who will always sell to the highest bidder, the fact is there will always be criminals going for exploits and bug bounties can help not just by paying off someone that would have otherwise abused a bug but also by attracting an equally motivated team who would otherwise be entirely uninvolved to play defense.
> because you paid a measly $2k bounty for a bug that owns, in a dangerous way, all of your users
The case is redeemable. It may still be an opportunity if handled deftly. But it would require an almost theatrical display of generosity to the white hat (together, likely, with a re-constituting of the engineering team).
After thinking about it for a good long ten seconds, yeah. It would be very easy to steal users' banking information with this. If you crack into one single bank account you have a decent shot at making over $2k right there, a skilled hacker could do a lot more.
Comments further down are concerned that on each page load, you're sending both the URL and a(n identifiable?) user ID to TBC. You may want to comment on that, since I think it's reasonable to say that those of us using not-Chrome (I don't use Arc personally, but I'm definitely in the 1% of browser users) are likely to also be the sort of person concerned with privacy. Vulnerabilities happen, but sending browsing data seems like a deliberate design choice.
I think that is addressed in the post. Apparently the URL was only sent under certain conditions and has since been addressed:
>We’ve fixed the issues with leaking your current website on navigation while you had the Boost editor open. We don’t log these requests anywhere, and if you didn’t have the Boosts editor open these requests were not made. Regardless this is against our privacy policy and should have never been in the product to begin with.
Given the context (boosts need to know the URL they apply to after all) this indeed was a "deliberate design choice" but not in the manner you appear to be suggesting. It's still very worrisome, I agree.
There isn't really anything you can do to convince me that your team has the expertise to maintain a browser after this. It doesn't matter that you have fixed it, your team is clearly not capable of writing a secure browser, now or ever.
I think this should be a resigning matter for the CTO.
And what, you’re going to find them a new CTO? What kind of magical world do you live in where problems are solved by leaders resigning, instead of stepping up and taking accountability?
CTO is simply a title, the proper response here would be to hire a head of security and build it into the culture from the ground up.
I'm looking at all of the Arc Max features which probably need to be architected correctly to be secure/privacy-preserving.
They could take a lot of inspiration from iCloud Private Relay and iOS security architectures in addition to really understanding the Chrome security model.
because sometimes it's a deadline pushed by management so a change could result in allow more time for design, programming, review, or even full time security personnel. Nobody writes the best most secure software under deadline
Yeah, I also think that asking someone to resign for this does not look like a proportionate response
They are owning up to their mistakes and making sure such things don't happen again (and increasing the amount from 2K :-)) seems like the right approach to me
Surprise surprise, turns out it takes a looong time for every software startup to finally strip out all the hacky stuff from their MVP days. Apparently nobody on this startup community forum has ever built a startup before.
Pro tip: if stuff like this violently upsets you, never be an early adopter of anything. Wait 5-10 years and then make your move.
Personally, I expect stuff like this from challenger alternatives, this is the way it should be. There is no such thing as a new, bug-free software product. Software gets good by gaining adoption and going through battle testing, it’s never the other way around like some big company worker would imagine.
I don't think you understood the severity or the noobiness of the error. This is a browser not a crud app or electron app. A browser is a complex system level piece of software not a hacky mvp and this kind of error shows that maybe they don't have the competence to be building something like this. It makes you wonder what other basic flaws are there just waiting to be exploited, even if its built on top of chromium. Would you fly in an mvp airplane built by bicycle engineers? (maybe not the best analogy since the first airplane was built by bicycle engineers)
Agreed, I wouldn’t have hopped on the first airplane with some bicyclist named Wilbur. That would involve risk of immediate physical harm.
On the other hand, we’re talking about a 2 year old browser leaking what websites you visit. Do you also think Firefox in 2006 was bulletproof? The entire internet and every single OS & browser was a leaky bucket back then.
The current safety-ism, paranoia and risk-aversion around consumer software on this forum is hilarious to me. Maybe they shouldn’t have called this place “Hacker” news, because it’s now full of people LARPing as international intelligence agency targets from a 90s movie. If the prying Five Eyes are such a concern for you, maybe use a fake email when signing up for stuff and your browser history is instantly anonymized.
Yes, startups involve lots of risk (to everyone involved, users/employees/founders/investors). But risk is the only way we get new things. If you those risks are too scary for you, stay far away startups.
You're speaking in bland hand-wavy generalities and like I said before I'm not sure you understood the issue or even read the write-up since you're not really addressing it specifically (it's a whole lot more than 'leaking'). To extend the analogy, this is like having bike engineers build an mvp supersonic jet and you find out they are using bike brakes to stop the thing. Its not even just merely an error its about some very questionable architecture. This is not a mozilla innovating the browser and making the mistakes you get when you're experimenting-and-innovating-something-new type situation at all and it has nothing to do with paranoia or five-eyes lol.
> $2,000 is a tiny fraction of what this bug is worth
The Browser Company raises $50mm at a $550mm post-money valuation in March [1]. They’ve raised $125mm altogether.
Unless they’re absolute asshats, they’ll increase the bug payout. But people act truly when they don’t think they’re being watched—a vulnerability of this magnitude was worth $2k to this company. That’s…eyebrow raising.
"We will let anyone run arbitrary JavaScript on all your web pages if you send them a referral link" is surely a 6-7 figure vulnerability for a web browser. That this vulnerability was discoverable using about two steps of analysis tools suggests many more issues are in the product.
It is very strange to me that their attitude is "no one was impacted" and this is "hypothetical". Any serious company would immediately consider this to be a case where everyone was impacted! This is like coming home to the worst neighborhood on the planet to find your door wide open, and immediately putting on a blindfold so you can continue to pretend nothing's changed.
Can you explain? How are they able to check whether someone did a quick “in and out” keylogger or cookie extraction? I doubt they can, because I doubt they store every request (that would go against what they claim for privacy) and I also doubt their DB backup happens on such a high frequency that they could catch this (e.g. minute-to-minute).
So…how? Are you claiming they have oodles of logs and a perfect dork* to find suspicious JavaScript? If they had the latter wouldn’t they already be using it for security?
I don't think you're using "dorking" correctly here, since web crawlers aren't anywhere in the picture. Server log queries aren't "dorks." Besides, if you can reproduce the issue and _if_ it's somehow logged in the database, it's usually not too hard to figure out how to query for other occurrences.
With that said, I think you're probably right. I doubt Firebase audit logs contain update contents, and based on the bug report, your "in and out" proposal is as simple as:
I know a lot of different people who do independent security research and have submitted vulns to bounty programs. Not a single one would even come close to saying "well, the bounty is low so I'll sell this on the black market."
Low bounties might mean that somebody doesn't bother to look at a product or doesn't bother to disclose beyond firing off an email or maybe even just publishes details on their blog on their own.
Bounties aren't really meant to compete with black markets. This is true even for the major tech companies that have large bounties.
Most of the vulnerabilities I've disclosed, and I've seen disclosed, were disclosed for free, with no expectation of getting anything. Why do you think every researcher is an amoral penny pincher who will just sell exploits without caring for the consequences?
Firebase is not to blame here. It's a solid technology which just has to be used properly. Google highlights the fact that setting up ACLs is critical and provides examples on how to set them up correctly.
If none of the developers who were integrating the product into Arc bothered about dealing with the ACLs, then they are either noobs or simply didn't care about security.
Until this individual comes back and responds to at least a few of the questions/comments, I don't think we should even pay attention to this marketing-dept-written post. They basically want this to go away, and answering any questions would raise more issues most likely, so they just seemed to have done the bare minimum and left it at that. It's 3 hours later now, they might as well have not even posted anything here.
50k or 100k would be far more appropriate given the severity of this issue. But overall, this makes me think there's probably a lot more vulnerabilities in Arc that are undiscovered/unpatched.
Also, there's the whole notion of every URL you visit being sent to Firebase -- were these logged? Awful for a browser.
Ya this is fair! Honestly this was our first bounty ever awarded and we could have been more thoughtful. We’re currently setting up a proper program and based on that rubric will adjust accordingly.
So when there are near weekly reports of websites being compromised due to horrid Firebase configuration, did absolutely no one on your teams raise a red flag? Is there some super low-pri ticket that says "actually make sure we use ACLs on Firebase"?
I think the bigger question is: Why are you violating your own security policy by keeping track on what we browse. I though my browsing is private and hidden away from you but if you store my browsing data in your firebase this is not acceptable at all.
> "...the hypothetical depth of this vulnerability is unacceptable."
What is also unacceptable is to pay 2000 dollars for something like this AND have to create user accounts to use your browser. Will definitely stay away from it.
I like Arc, and I don’t want to pile on: God knows I’ve written vulnerable code.
To explore a constructive angle both for the industry generally and the Browser Company specifically: hire this clever hacker who pwned your shit in a well-remunerated and high-profile way.
The Browser Company is trying to break tradition with a lot of obsolete Web norms, how about paying bullshit bounties under pressure rather than posting the underground experts to guard the henhouse.
If the Browser Company started a small but aggressive internal red team on the biohazard that is the modern web?
I’ll learn some new keyboard shortcuts and I bet a lot of people will.
Hursh / ha470, where did you go? There are lots of good questions in the replies to your thread, yet you went dark immediately after posting more than 8 hours ago. It's hard to imagine what could be more pressing than addressing people's concerns after a major security incident such as this.
To be honest, I'm a bit disappointed. For future reference, this doesn't seem like a good strategy to contain reputational damage.
> This kind of bug could be sold for 100-200k easily
Maybe not. If the browser is that buggy, there may be plenty of these lying around. The company itself is pricing the vulnerability at $2k. That should speak volumes to their internal view of their product.
Many engineers at SV startups use Arc on a daily basis. This bug could've resulted in the compromise of multiple companies, probably including crypto exchanges. A browser bug of this severity is extremely valuable, even for a niche browser like Arc.
> Many engineers at SV startups use Arc on a daily basis
Do we have adoption statistics?
It would seem prudent for the browser to be banned in professional environments. (I use Kagi's Orion browser as a personal browser on MacOS. My work is done in Firefox.)
> browser bug of this severity is extremely valuable, even for a niche browser like Arc
Absolutely. (Even if it were in beta.)
What I'm trying to say is the $2k payout sends a message. One, that The Browser Company doesn't take security seriously. And/or two, that they don't think they could pay out a larger number given the state of their codebase.
Side note: my favourite content on crisis management is this 2-minute video by Scott Galloway [1]. (Ignore the political colour.)
There is also 3: putting a big bounty out signals other very smart and ingenious security researchers that Arc is a lucrative opportunity to make money. Till now it's been "safe" in relative obscurity so not a lot of people focused on hacking it or gave it a lot of effort because it wasn't worth their time.
It’s already going to be under the microscope now from black hats, so unless they want a catastrophic issue to result in user harm, they better get their act together.
I think OP mean to say "this bug could let an attacker gain $200k of value easily", though you are right the market clearing price for such a vulnerability is probably low due to huge supply.
The CTO and co-founder didn't check in on any of the concerns, completely disappeared after leaving a heartfelt comment.
This comes off as incredibly disingenuous.
I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually know about (I don't use firebase, I have tried it out in the past though). This isn't some edge case or hard to solve thing in firebase, this is the easy stuff.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).
As someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
Security rules are meant to be taken seriously, and it's your only line of defense.
Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists.
Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever.
How many tutorials, community answers, and gists do you think conveyed that warning?
Reading/watching random tutorials and asking basic questions on SO __instead of reading the official docs__ is a trend I've observed for the last 10 years. Even for stuff pretty well documented like Python, Postgres, React, etc.
Most official documentation is awful, and just an API reference. It's (almost) like asking someone to learn english and then pointing them to a dictionary.
And that's because a lot of devs think it's perfectly dandy to just put perfunctory docstrings in their methods, point it at whatever "doc generation" tool, wire it up to a github.io domain and call it a day.
There is a reason people crave, want and seek things like SO and blog-posts. They're packed full of insight, working examples and just plain old "how TF do you use this thing". Oh and of course, the "this problem A didn't work when using setup B and C, and that's because of reasons X,Y,Z. Here, try H,I & K and it'll work.
This goes doubly so for google cloud documentation. Firebase docs are decent, but if you're a developer who's gotten used to google's documentation style I could see skipping right over it.
For many years entire sections across multiple pages of firebase's documentation were missing after the site contents had been migrated from one system to another.
Multiple years of sample code and examples just cut out from the middle of pages.
When I was building on firebase it took me a long time to reconstruct exactly how certain aspects of the system were supposed to work just because of those missing docs.
I remember writing a Twitter library when that was a thing, and being severely disappointed at the quality of the API documentation. There seemed to be little choice other than to experiment to see what responses you’d receive (and hope that it wouldn’t change underneath you). Same was often true with some of the GitHub APIs, although it’s been a few years since I’ve spent time with them.
I often wonder how much this can be attributed to the pretty awful SEO of most documentation. I write mostly Python at work and it's infuriating how often GeeksForGeeks, W3Schools, Programiz, or RealPython pop up when I'm just trying to reference like, the arg order of a builtin, or the particular behavior. Django is worse, I often feel like I can't even find the doc when I know it's there and read it before.
Documentation is largely static content. It isn't their job to play SEO games to convince search engines to surface it in the query results. Documentation is not a revenue generator for Google so it gets buried below the sites with Doubleclick ads.
Attempting to find the relevant docs page via search engines is generally not a good way to go, you should go to the documentation and search from there. Bookmark the landing page of the documentation.
People have already given many ideas, but if you use DuckDuckGo they have bangs for searching various python docs. Here's a page that lets you search which ones are available: https://duckduckgo.com/bangs
It points to a deeper issue in the Browser Company imo. Clearly, an inexperienced dev wrote that api, a senior approved the PR and no one in the wider team picked it up. And that's a team building the fundamental unit of your digital experience. If they failed at something this basic, I would be terrified to know what else they are missing in terms of security
For sure, I think the issue is – at what point in an engineer's development is that fact hammered home? For me it was hanging out with friends and learning fundamentals together, and then even more reinforced in the security course I took in college. For others, they might skip that elective in school (or their bootcamp will gloss over it), and they learn it the hard way later on the job?
That said, ideally code review/peer review/design review would catch things like this. If this was a feature implemented by an engineer that wouldn't know any better, they should have at least some help from others around them.
The issue is not about supporting engineers, this isn’t a pile-on to some poor engineer. It’s about choosing secure software, and avoiding software (particularly critical and vulnerable software like a web browser) from orgs that have built severe vulnerabilities into their software by incorrectly implementing something foundational to computer security.
There are many smart engineers who I would not trust to build my web browser because they lack the domain knowledge to do so. That’s not a slight on them. But if a company hired those people to make a web browser, I wouldn’t trust that org’s software.
This wasn't really a problem that required domain-specific knowledge to get right. Whoever designed an API that allows the client to bypass auth like that can't be trusted to design software that takes user input. At least not without some additional training that was missed along the way.
This may or may not be fair, but in my view, the type of person that would opt for a firebase solution is probably the type of person most vulnerable to foot guns.
Sadly true, but Firestore has a security rules emulator and encourages you to write unit tests for it! There's just so many levels of "ignored all reasonable practices" here. Where's the code review? Where's the security/privacy audit?
I am glad to put engineers in quotes because many people here and elsewhere will use that word with a straight face while also believing that you can call yourself that while learning your job from watching youtube vids and pasting code you don't understand. We need to stop using the word "engineer" for "software developer".
I shall watch the downvotes come from these so called "engineers".
I think a system that makes it this easy to shoot yourself in the foot is probably not a great system. Documentation is important, and I'm glad it's clear and obvious, but humans make mistakes. You'd hope that the mistakes have less dire consequences.
> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access.
What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
Nobody reads docs dude. They copy and paste stack overflow answers, and now, copilot answers, which is going to be based on stack overflow ultimately anyway.
I have heard this said by many people: “I don’t look at documentation because it usually is inaccurate/out of date”
There’s plenty of people sharing anecdata about bad docs, and I’ve dealt with my fair share. But my anecdata is that engineers who habitually go to the docs directly and read them gain a better understanding and write better software than those who do not. I believe that most software for engineers has documentation that is more informative than stack overflow and blog posts.
I support reading docs first for questions, but man some truly are terrible.
Like cmake. This just vomits a dissertation at you for each function without really ever saying what it does or how to use it. That’s why there’s so many different sites and GitHub repos with samples. 95% of which are completely out of date (which is a problem cause people looking for these samples probably aren’t on the ups with being able to tell if they’re out of date)
It's interesting to see software engineers going from rolling their own auth, to not rolling their own auth, to not even noticing this quite blatant security problem.
It doesn't matter if you roll your own auth or not, you need to understand a very basic fundamental of it all: never trust the client.
Coworker implies paid work, and therefore they are not amateurs. They very well may make the same mistakes, but those mistakes would be professional mistakes.
Why this level of pedantry when the meaning is absolutely clear? A professional can make an amateur mistake. This makes perfect sense. That isn't implying the professional is actually an amateur, but that he made a mistake that an amateur would make.
For some added pedantry: aren't all the mistakes that a professional might make, also ones an amateur would make?
In fact, it seems like an amateur is likely to run into all mistakes more often, thereby making all mistakes amateur mistakes; unless there some class of mistake that amateurs are better at avoiding?
YES!!! You need auth to prevent employees from looking up sensitive user data without a good reason, or it'll be a stalker's haven. And to prevent possible intruders from gaining more data/access. Defense in depth. And for preventing an experiment from wiping use data. And for so many other reasons!
> If it's internal, did they really need to have auth?
Nothing on a network is truly internal. The moment you break the physical link between metal and man you're in an unintuitive, and thus insecure, state.
Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101:
```
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
Unclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point.
Which then leads me to the next question, what is the practical way to write rules against that operation?
This is what happens when you hire solely based on leetcode skill. A shit-tier engineer can master leetcode within months, but a good engineer will probably struggle at Find Nth Smallest Sum problem because he spends more time reading and thinking about code.
Leetcode is a fucking joke to the industry, gone are the days when you actually had good code with devs who spent time thinking about information architecture. In my experience boomer devs are actually the only ones who write idiomatic code. Millennial and Gen-z devs are the worst, they have no understanding beyond basic function calling.
the whole idea of firebase is flawed as logic that belongs to a server is now on the client side. I don't know much about security but that sounds like making any centralized rule (eg security) hard to implement. It also tends to expose more internal logic than the client needs to know, which is bad in both software design and security.
I just wanted to say, I enjoyed the little pixel art cat that runs towards wherever you click immensely. It’s one of those fun, whimsical little touches that I don’t see all that often. A reminder that the internet can be a fun, whimsical place if we want it to be :)
As I didn’t get that, it seems like the dev honors prefers-reduced-motion, and doesn’t display it in that case. Excellent of them, give joy to those who want it, prevent annoyances for those who hate them.
I don't, but I run the same system configuration, so I can compile it on my computer, transfer it and run it.
Alternatively, if a compiler such as gcc is available, you could also run
# https seems to be broken on this website currently
wget http://www.daidouji.com/oneko/distfiles/oneko-1.2.sakura.5.tar.gz
tar -xf oneko-1.2.sakura.5.tar.gz
cd oneko-1.2.sakura.5/
gcc oneko.c -lX11 -lm -o oneko
./oneko &
cd ..
# remove all traces
rm -r oneko-1.2.sakura.5 oneko-1.2.sakura.5.tar.gz
Not the person you're responding to but my workplace has a special internal link precisely to "remind" coworkers to not leave unlocked laptops unattended.
It's cute but I just can't focus on the article knowing the cat is gonna move every time I move my mouse or scroll. I popped open my console and deleted him. Sorry, kitty
And here I was wishing it would go away and trying to find a way to hide it because on my phone it was always covering text. Firefox reader mode worked.
I thought it just ran around on the top line of the header, and was quite taken with it. I then scrolled and it followed me right into the middle of a paragraph. Less taken, but cat's gonna cat.
According to this article, Arc requires an account and sends Google's Firebase the hostname of every page you visit along with your user ID. Does this make Arc the least private web browser currently being used?
I trashed Arc immediately after install when I found out having an account was mandatory. That seemed so silly, like toothbrushes-requiring-wifi absurd. How much moreso now.
Truly. I was looking for a privacy respecting Chromium-based browser to use for Web MiniDisc (https://web.minidisc.wiki/) and came across some enthusiastic praise for Arc. I downloaded it and it immediately wanted me to create an account to even use it. How can that possibly respect my privacy? It went right in the trash.
What is also strange that I only found out about account after download. Like it was standard thing for the browser. (Sure there are optional accounts in others but login-walled browser?)
Hilariously (in the absurd way), this affects my girlfriend, who prefers and uses the Microsoft account feature AND onedrive exactly how Microsoft would hope she would, and STILL gets fucked by their stupidity.
Her laptop has a mediatek wifi card that doesn't have built in Windows drivers. Re-installing Windows requires you play the above game, so you can get into Windows, install the driver, and then immediately log into Microsoft.com.
In 2024 it is considered normal for an _operating_system_ to require an account, an information that is potentially passed around to any app running on it.
I had doubts already when submissions promoting the browser were added on hn while there was no way to see how it looks like or even test it out - for quite some time there was nothing but mail singup on their page.
I guess it's relatively easy to test, add the Firebase domain to your host file and point it to 127.0.0.1 and try to use the browser.
Sometimes things like this handle connection failures better than "never-ending connection attempts", so you might want to try to add a throttle or something too for the traffic between the domain and the browser, might also trip it up.
Chrome does not require an account to use. And Chrome by default doesn't send sites you visit to Google, unless you turn on the "make searches and browsing better" feature or the "enhanced safe browsing" feature.
So the OP is right. Arc's privacy is worse than Chrome.
This is such a fantastic bug. Firebase security rules (like with other BaaS systems like Firebase) have this weird default that is hard to describe. Basically, if I write my own API, I will set the userId of the record (a 'boost' in this case) to the userId from the session, rather than passing it in the request payload. It would never even occur to a developer writing their own API past a certain level of experience to let the client pass (what is supposed to be) their own userId to a protected API route.
On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.
> On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.
Tbh you're doing it wrong if you go that way.
Default deny, and then you only have to imagine the legitimate uses.
Fair enough, but my point is more conceptual, in that you still have to write `boost.userId == auth.userId` as an allowed pattern rather than making that pattern the only technically possible result, which is the convention in a traditional API.
The failure modes are much clearer: when you write the API in a default-deny context & forget to add that allowed pattern, it never works, so you notice & figure out the bug.
The same story with default-allow means the system looks like it works fine, and you end up with no security at all.
And then when you imagine the legitimate uses you have to imagine how allowing those legitimate uses could be misused. You always need to think red and blue.
For inserts yes, but for updates I've frequently seen cases where people just stuff the whole request into their ORM or document store. It is pretty easy to think "the owner can update the document" without realizing that there are some fields (that the official client doesn't set) that shouldn't be updated (like the owner or created timestamp).
The correct solution is likely default-deny auth for every single field. Then you at least have to explicitly make the owner field writable, and hopefully consider the impact of transfering this object to another user.
I'm amazed by how profoundly stupid this vulnerability is. To get arbitrary code execution, you literally just send somebody else's user ID, which is fairly trivial to obtain.
I don't work at FAANG. I just work at some company that makes crap products you don't actually need, and even I would never build this kind of bug.
But these people want to build a web browser, with all the security expertise and moral duty that implies?! Wow.
Can you explain how you could get someone else's user id? I get that this is still a big vulnerability but am trying to understand how that would happen.
There are a lot of major security vulnerabilities in the world that were made understandably, and can be forgiven if they're handled responsibly and fixed.
This is not one of them. In my opinion, this shows a kind of reputation-ruining incompetency that would convince me to never use Arc ever again.
aug 25 5:48pm: got initial contact over signal (encrypted) with arc co-founder hursh
aug 25 6:02pm: vulnerability poc executed on hursh's arc account
aug 25 6:13pm: added to slack channel after details disclosed over encrypted format
aug 26 9:41pm: vulnerability patched, bounty awarded
sep 6 7:49pm: cve assigned (CVE-2024-45489)
Four hours from out-of-the-blue initial contact until a fix pushed is pretty good, even given how simple this fix probably was.
EDIT: Oh, the date changed; so it was 28 hours until fix. Still decent; and half an hour from initial contact to "Join our slack channel" is incredibly fast response time.
Reacting fast is the least the vendor could do. Bare minimum. This should not be applauded. It should be treated as "well, at least they reacted at a reasonable speed so the root cause was probably not malice".
In other words, a quick turnaround with a fix does not lessen the impact of being negligent about security when designing the product.
It's certainly the least a vendor should do, but it's absolutely not the least a vendor could do, as we see the vast majority of vendors do far, far less. It's worth holding people up and saying, "This is how you should be doing it."
You’re technically correct, given a literal reading of the post you quoted, but the use of “could” there was idiomatic - let me explain:
There’s a (fairly dated) idiom, “it’s the least I can do”, used when you are offering to do something to make up for a mistake or offense, but the person you hurt says your offer of compensation is unnecessary. For example:
Situation: Person A bumps into Person B in the cafe, causing B to drop their coffee cup.
A: I’m so sorry! Let me buy you another coffee.
B: That’s not necessary - it was an accident, and I had almost finished my drink anyway.
A: It’s the least I can do!
B: Oh, thank you so much!
Buying B a new coffee is not _literally_ the least A could have done - the least A could have done is nothing - but that’s the English idiom. “Can” is acting more like “should” here. You could read it as “It’s the least I can do (if I’m a good person, which I am)”.
Thank you for the explanation -- when I'm speaking foreign languages I appreciate this sort of explanation. But in this case, as a native English speaker, I was well aware of the idiom, and was trying to subvert it. :-)
The original idiom is said in the first person, and as you say means essentially, "Justice and equity compel me to do this; I don't find myself able to do less".
GGP was actually using a derivative of the idiom in the second person. What the derivative literally says is, "Justice and equity compel them to do this; they don't find themselves able to do less". But idiomatically, what it actually means is, "Justice and equity ought to compel them to do this; they ought not to find themselves able to do any less".
Which is true; but it's still the case that the vast majority of companies find themselves very much able to do far less. Justice and equity should compel companies to do this bare minimum, but in the vast majority of cases it doesn't. And so we should still commend those who do find themselves so compelled, and hold them up as an example.
No Linux version prevented me from trying it, didn't even get to the account wall, who knows if there's a pay wall. Perhaps the "moat" concept was misunderstood.
Honestly I’ve always considered Arc to be a wolf in sheep’s clothing, especially when it comes to privacy.
50-60mm cash at 500mm (!) valuation and no business model is a big red flag when it comes to something as important, as personal as a browser. This is not a charity. Someone, somehow will have to pay for that.
Yeah I’m so torn. It’s honestly the best browser UX I’ve seen, the right combination of vertical tabs, auto archiving, spaces/collections, sync, etc. I don’t care for Easels, but the core is good.
Except… the growth hacks have started to creep in. They overlay an advert for their own AI services on top of regular Google search results pages in their mobile app. Not even a browser chrome UI element, it’s literally over the page content. That feels like a huge violation of what it means to be a browser.
I don’t want their AI features. I don’t want growth hacks. I don’t want to sign in except for sync. I’d happily pay $40 a year for Arc as a product-focused-product, but as a VC-focused-product it’s heading downhill.
It does get a lot right and feels smooth in ways that Chrome, the various Chrome-clones, and Firefox just don't. It's also ironically the only browser even trying to feel native on Windows, using WinUI/WinAppSDK for its UI there, despite originally being Mac only.
It's unfortunate that other cross platform browsers have such a strong tendency to phone in these little things, because they really do add up to make for a nicer experience.
I'm torn for the same reason: The UX hits all the right notes for me and I've tried every MacOS browser under the sun. I'm an ADHD sufferer and there's something about their combination of features and UI that just lets me get stuff done. And I don't even touch their AI features.
Thanks for the recommendation. I just had a quick try, it's nice, seems like a very polished Firefox. It seems to have a bunch of features I don't want in a browser so not sure if they'll get in the way.
Vivaldi feels like a cross platform port in all the ways I try to avoid. I understand the feature set is good, but it doesn't feel nice to use. Hard to state exactly why though.
Lots of developers and power users make a good chunk of Arc's use base. If you're after some interesting credentials then "every Arc user" is a perfect group with little noise.
If I had to guess, the typical Arc user is a Mac user in tech. It doesn't run on Linux, most windows users wouldn't run it, and non-tech people haven't heard of it.
Then most engineering IC people will most likely run Firefox or Chrome, so you're probably looking at designers/founders/managers as your target.
Probably some interesting targets there, but not the type that the NSA cares about. Just pure conjecture on my part of course ;).
I've seen quite a few. In one of my clients's Slack there are at least a couple people advocating for it all the time. They're mostly DLs or in similar roles. I also know at least one developer who uses it.
I used it for a while for a very limited use case. Some interesting concepts. Mostly I found it annoying though. I also didn't like the sign-in thing but still wanted to experiment. I have dropped it altogether and kept Firefox as main browser (as it's been for many years) and Safari as a secondary. Both work much better overall for my needs.
my brother uses arc browser , he is a developer .
I think he saw it from somebody using it (maybe theo t3 or some other creator he watches) , and he found it cool (plus there were lot of videos flooded with saying arc is really great IDK)
If someone finds something cool on the internet. They are going to try it , given that they are capable to do so.
He had a mac so he was able to do so , Even I tried to run arc on windows once when it was really beta and only available to mac (I think now it supports windows not sure)
I just kindly want to state that if the nsa could've bought this exploit , they could've simply waited and maybe even promote arc themselves (seems unlikely)
Maybe they could've tried to promote the numbers of arc users by trying to force google and microsoft search engine through some secret shady company advertising / writing blog posts for arc / giving arch funding or like how we know that there are secret courts in america
( and since these search engines basically constitutes for a high percentage of discovery of stuff by search engine by users)
People could've credited the success to arc in that case for getting more users but the real winner would've been NSA.
no I meant that
though you need to login , i think arc isn't available on linux , only mac (or maybe windows though not sure , I see some issues + the security issue)
Ye it required login and my brother logged in (just see ! , the amount of friction to login etc. yet my brother , whom I would consider to be a little conscious of security still gave to try it in the first place)
Everyone else at work likes it, so I signed up with my work e-mail address and use it for work. All of my complicated browsing needs are done for work, so there's a good fit there.
Firestore rules are in "lock mode" (no read or write allowed) by default since a long time. Then, everything is ultra well explained in the docs.
I was already aware of it when being a noob dev 10 years ago, and could easily write a rule to enforce auth + ownership in the rules. No way, seasoned devs can miss that.
yes. I feel sad that now we have created an incentive where selling to the govt.'s is often much lucrative than telling to the vulnerable party (arc in this case)
(just imagine , this author was great for telling the company , this is also a cross platform exploit with very serious issues (I think arc is available on ios as well))
how many of such huge vulnerabilities exist but we just don't know about it , because the author hasn't disclosed it to the public or vulnerable party but rather nsa or some govt. agency
Also, firebase? seriously? this is a company with like, low level software engineers on payroll, and they are using a CRUD backend in a box. cost effective I guess? I wouldn't even have firebase on the long list for a backend if I were architecting something like this. Especially when feature-parity competitors like Supabase just wrap a normal DBMS and auth model.
Well, it's an app that users access all their online info through - bank, email, search, work, social - everything. Even an open-source, decentralized, blockchain, grass-fed, organic, extra virgin, written in nothing but HTML, released by W3C itself browser could monetize just ~5% of market share if users are downloading their build (or if its baked into the source), considering how much a browser reveals about its user and to the extent the user can be retargeted for: Ads, marketing, surveillance, analytics.
The biggest opportunity has to be driving search traffic to the major search providers all these browsers partner with.
Could also get acquired by a major browser vendor if you have a better product and people are downloading it more than the major ones, especially if both are based on the same underlying engine. Even Firefox still sucks to this day. I'm using it right now (Waterfox) the product still sucks! I know of some browser vendors acquiring others, especially as mobile took off and it was hard to get it right.
Seems like the opportunity is similar to that of social media but slightly more modern because nobody uses new social media anymore but people are trying out new browsers (and you get richer user/usage data).
It’s the “chrome replacement we have been waiting for”, but (if I read this right), my data is still sent to Firebase? Also it’s a browser, not a “tinder but for cats” startup idea I’m writing for my cousin for a beer.
It’s not only not a smart engineering decision, it’s also a terrible product, reputation and marketing decision.
I'm not disagreeing about the severity of the security vulnerability that has been uncovered – to be clear, it's an absolute shocker of a bug. It's really disappointing to see.
But I still disagree that the use of Firebase, in and of itself, is a bad engineering decision. It's just a tool, and it's up to you how you use it.
Firebase gives you all features needed to secure your backend. But if you configure it incorrectly, then _that's_ where the poor engineering comes into play. It should have been tested more comprehensively.
Sure. You could build your own backend rather than using a Backend-as-a-Service platform. But for what gain? If you don't test it properly, you'll still be at risk of security holes.
TL;DR: it's not possible to export data from Arc, but it's possible to copy-paste the folder to a Chrome profile, and Firefox and other browsers will detect&import it.
Unfortunately, Zen Browser simply isn't an alternative. If you like Arc, then Zen's UI for tabs and splitting views isn't really anywhere close to satisfying the same needs.
Firefox seems to be borrowing some of the UI features slowly (at least the vertical tabs). And at least the Mozilla Foundation is very public with their wants and goals.
Browsers are very important part of our life. If someone compromises our browsers , they basically compromise every single aspect of privacy and can lead to insane scams.
And because arc browser is new , they wanted to build fast and so they used tools like firebase / firestore to be capable of moving faster (they are a startup)
Now I have read the article but I am still not sure how much of this can be contributed to firebase or arc
- Firebase allows for easy misconfiguration of security rules with zero warnings
- This has resulted in hundreds of sites exposing a total of ~125 Million user records, including plaintext passwords & sensitive billing information
So because firebase advocates itself to the developers as being safe yet not being safe , I think arc succumbed to it.
firestore has a tendency to not abide by the system proxy settings in the Swift SDK for firebase, so going off my hunch,
Also , you say that you have been convinced to never use arc again.
Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
this is just recently discovered , just imagine if something more serious is also just waiting in the shadows
Couldn't this also be considered a major security vulnerability just waiting to be happen if some other exploit like this can be discovered / google.com is leaked and now your cpu information and way more other stuff which browsers shouldn't know is with a malicious threat actor ?
I very much agree with the idea that browsers are security-sensitive software, unlike, say, a picture editor, and more like an ssh server. It should be assumed to be constantly under attack.
And browser development is exactly not the area where I would like to see the "move fast, break things" attitude. While firebase may be sloppy with security and thus unfit for certain purposes, I would expect competent developers of a browser to do due diligence before considering to use it, or whatever else, for anything even remotely related to security. Or, if they want to experiment, I'd rather that be opt-in, and come with a big banner: "This is experimental software. DO NOT attempt to access your bank account, or your real email account, or your social media accounts".
With that, I don't see much exploit potential in learning stats like the number of cores on your machine. Maybe slightly more chances of fingerprinting, but nothing comparable to the leak through improper usage of firebase.
hmm interesting.
Other thing to add is if we treat it as a ssh server , we actually won't try to go out and break things.
But I think that was the whole point of arc , to break the convention and be something completely new
and I have a reason why
They were competing with the giants called google , safari , firefox which have insanely large funding and their whole point was trying to sell something later built on this arc browser.
and since chrome , firefox etc. don't try to come up with these ideas because well security reasons (which I agree to / as seen in the post)
I think arc wanted to seperate itself from chrome / firefox and that's why they became a bit reckless you could say since this exploit was available.
Also the other thing I want to convey , is that "With that, I don't see much exploit potential in learning stats like the number of cores on your machine"
this was only recently discovered. Just imagine the true amount of exploits in these proprietory solutions which we don't know about.
Yeh. Just like a ssh server , I would personally like the source code to be available but developing browsers is time consuming and money intensive for developers but ladybird exists , but its in beta.
that being said , not open source is also that private , (xz) , but atleast it got discovered way quickly and was able to mitigate it quickly
> Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
That's pretty interesting. Where can I learn more about this?
I recall there being a thread with way more discussion at the time, but I can't put my finger on that thread right now. This post has some information:
>>Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
Yeah so using chrome based browsers like Arc is giving more power to Google to do shady stuff while also being a victim of the third party unsafe code.
I'm in the same boat as GP. Was invited early, loved the Arc UX far more than any other browser. I've recommended it to many people.
As many other comments have pointed out, this vulnerability is such a rookie mistake that I don't think I can trust them again after this without understanding what factors in their security/engineering culture led to it. Patching this one issue isn't enough.
>Them acknowledging the issue, then fixing it within 28 hours isn't good enough for you?
Are you not concerned with the yet to be discovered vulnerabilities?
What is concerning is the nature of the vulnerability and how it speaks to their security culture (which is obviously non-existent).
This also revealed that their privacy policy is pure marketing fluff, completely disconnected from (and, in fact, counter to) their actions.
If you are comfortable using a browser (probably the software with the largest risk and attack surface on your device) that had an embarrassingly rudimentary vulnerability, made by a company who lie about the most important promise of their privacy policy, then I've got a calculator app for you.
They only acknowledged the issue after the write up from the researcher and claimed they thought they didn't need to include it in the release notes because it was a "backend fix".
That's how you ruin a company reputation. Not saying it is or not deserved, but how could anyone trust a browser that had such a big security fail.
And what about all the other that have not been reported or may be exploited ?
From now on, every time someone is going to suggest arc browser, there will be another one to remind everyone of that. That's going to be very difficult to overcome when your software already doesn't have that big of a market share.
Judging by blog posts on HN, I got the impression that these vulnerabilities are often not rewarded at all, or rewarded by a minuscule amount. It almost seems like companies are begging hackers to sell these exploits. Perhaps because they aren't penalized by the regulator for breaches?
They offer a low price because the risk of tanking your career, landing yourself in jail, and the fact that the researcher probably doesn't know how to line up a sale means the company is the only buyer.
I would go the other way, companies offer low bug bounties because they don't want researchers to discover them in the first place. This looks terrible for Arc despite the fact if left undisclosed it probably would have continued to be unexploited for years to come.
Am I too optimistic? I feel like most regular people I know wouldn’t sell this off. Most people are not antisocial criminals by nature, and also wouldn’t know how to contact a “state actor” even if they wanted to.
> Am I too optimistic? I feel like most regular people I know wouldn’t sell this off.
Probably you're just used to a relatively good life, not a bad thing :)
Image being able to sell this off for $20,000 (although I think you could ask for more, seems to be a really bad vulnerability) in a marketplace, for >90% of the world that's a pretty good amount of money that you could survive a long time on or add a lot of additional quality to your life.
How does this work in practice? What systems are in place to prevent someone selling an exploit and then turning around and disclosing it properly as soon as they have the money, potentially getting even more money through legal channels? Is there some sort of escrow?
Arc is used disproportionately by users who work in tech which tend to be paid quite well.
Am I wrong in thinking that with this vuln you could drain any financial accounts that they log into Arc with? Or, if they use Arc at work, that you now have a way to exfiltrate whatever data you want?
A browser vuln is about as bad as an OS vuln considering how much we use browsers for.
Young people (like me) use lowercaps like that all the time. Around 50% of the young people I know purposefully turn off auto-caps on their phone.
Why? I really couldn't say. I think we just like the feel of it. The only reason I type with proper capitalization on HN and my blog is because I know older people read it.
I’m middle-aged. I’ve noticed in the last few months more and more articles with this style. Something I’ve never seen before in blogging or article writing.
I usually notice the style at some point but this time I had no idea until this other commenter pointed it out. I guess I am getting acclimatized.
I was similarly fascinated by the stylistic choices made here. No capitalisation of even any names, no hyphen in a compound adjective, but dots and commas and spaces are deemed necessary, also before "and" where the word clearly acts as separator already. If you look at the waveform of speech, we have no spaces between regular words so, if they want to eliminate unnecessary flourishes... though perhaps (since text largely lacks intonation markers) that makes it too unreadable compared to the other changes. All this is somehow at least as fascinating to me as the vulnerability being described!
It’s just another dumb social media trend, like tYpiNg LiKe tHiS. Hopefully it too will phase out. Search for “lowercase trend” and you’ll find reports of it going years back, there’s nothing worth being fascinated about.
It has seeped into HN as well. Look closely and you’ll notice several commenters type like that.
It's extremely irritating, distracting, and breaks focus on the content instead of the annoying stylistic choice, just an fyi..but I imagine you probably like that this is true and purposely try to annoy the people that aren't in the little club. If not, then I suggest not doing it. The tone I perceive from it is "F**** the reader"
> ... you probably like that this is true and purposely try to annoy ...
I don't know if you meant to direct this at the person you're replying to but I'm convinced the overwhelming majority of people don't get out of bed in the morning with any of that in mind
It's comments like these that make me reconsider what hateful meanings others might read into my communications or mistakes
Yes I mean this to anyone repeatedly, consciously fighting natural convention and muscle memory to purposely type every letter in lowercase, knowing that this produces in the reader a slight dissonance and distraction constantly, and choosing to do this instead of using convention that everyone understands so that "syntax" does not become the focus and instead the content of the message does.
Otherwise they're "drawing attention" to the style and themselves for narcissistic reasons. I would simply assume they'd have to know the annoyance this brings to the reader, so I assume it's on purpose.
I would feel the same about someone writing code in a consistently purposeful unorthodox style and against convention in such an obvious and effortful way that no one is used to. Personally, and YMMV, I like to try to write in as clear a way as I can to get my point across as much as possible. Useless stylistic fluff in something that isn't poetry, seems counter to that purpose.
>mistakes
It's not a mistake though to ensure every letter one writes is not following convention and English syntax. Accidents and mistakes are a different thing.
That's really interesting, I personally don't read those tone differences based on the casing. Neither approach carries different warmth or formality to me at all.
I wonder if this is a regional or generational thing?
It's definitely primarily generational. In my experience, capitalization-as-tone is used by many Generation Z people. On the other hand, it is not widely used by older generations, or the younger Generation Alpha.
In my experience, that isn't the case. Among people who "have gotten used to" it, using capitalization to indicate the formality and/or tone of your message allows the reader to understand the writer's intention better. I have not observed any correlation between political leanings and this.
I'm not sure what you dispute or your point is here. If people slightly or strongly start aping Trump's writing style in various forms I'd say there's a good chance those people are right wing or simply "not the same people writing in all lowercase" you know?
You highlight stylistic choices. I'd say we can observe the differences in different styles and see how uses them. Is Trump writing in all lowercase? No. Is this poster writing like Trump? No. Do a lot of left-wing people use the all-lowercase style? I see it all the time, yes.
> lowercase without caps reads with a warmer, informal tone
Personally, and I’m certain I’m not alone on this, it reads as annoying. It’s harder to follow and looks as if the writer didn’t care to do the bare minimum to make the text accessible and clear to the reader.
> there’s a Tom Scott Language Files video documenting it
Per that video (thank you for sharing), capital letters “make a paragraph easier to read” and “context matters” and “the conventions change fairly quickly” and typing in all lowercase is “sometimes okay”.
This is a post documenting a serious browser vulnerability, shared to the wide internet, not an informal conversation between buddies. Clarity matters. I don’t fully buy the tone argument and find words and sentence structure are more important. Take the following two examples:
> Just heard about your promotion, you beautiful bastard! Let’s go get pissed to celebrate, on me!
And:
> good afternoon mrs bartlet. the limousine will be available in twenty minutes. i would also like to apologise for my behaviour yesterday when i inadvertently insulted your husband it was a faux pas i promise will not be repeated. my resignation will be on your desk by noon.
I get that language evolves. You do you. Personally I hope this trend subsides like so many others before it. Maybe you don’t like to read properly structured text and prefer all lowercase. My preference is the reverse. And that’s OK, we don’t all have to be the same. I merely wish that people who prefer a certain style understand not everyone will see it the same way they do (and I’m including myself).
That's true. I agree with you that anything less than a formal tone would be, and is, inappropriate for this context. I also respect that you prefer standard capitalization and punctuation at all times. Being aware of the audience is critical for any writer.
> lowercase without caps reads with a warmer, informal tone
No, it reads as "I'm uneducated and don't know how to write the English language properly". It's incredibly obnoxious for people to use as an affectation.
To me, proper capitalization is easier to parse - not massively so, but a little bit. So writing without caps is a bit of a jerk move. You're making it harder for me to read, either because you're lazy or because you want to affect a style. In either case it's a bit of a jerk move.
It's more of a jerk move when it's done on a discussion board, because what you write once is read multiple times. So the cost multiplies, but (if due to laziness) the benefit only occurs once.
Now, in something like texting, I understand, when you're trying to type on that teeny phone keyboard. It's harder to hit the shift key when you don't have a spare finger because you're only using one. But for something like here, take the time and the effort to make it better for your readers.
On a formal discussion board like this, I don't believe an informal tone is correct. To me, it doesn't make it harder to read, but it does come across as mildly disrespectful of the environment.
When texting on a phone, the default is to automatically capitalize. Using all-lowercase requires more work than doing nothing. It isn't lazy or even more efficient to go back and replace your "I"s with "i"s. With the right reader, it's done to give them a better idea of the tone you wish to deliver.
With that said, it requires a certain degree of audience awareness. Many people do not interpret lack of capitalization the same way I do, as evidenced by this thread. On my phone, I have auto-capitalization disabled. When texting someone for the first time, I tend to use proper capitalization, even if I want a casual tone. I just did a typing test with capitalization and punctuation and scored 55 wpm on my phone. It's a choice I make and it varies based on audience, and intended tone. Effort, on the other hand, is not a factor.
I use lowercase in most places precisely because it forces me to use shorter sentences and split text into paragraphs. The result is easier on the reader.
It's just a habit from chat rooms and instant messengers of the beginning of this century. Most of my mates who write like that are well over 30.
This whole subthread is one projection after another.
How does lower case force you to do that? It seems to me that it's completely orthogonal to sentence length and paragraph splitting. (But then, I use uppercase, so maybe I don't understand the dynamic.)
> Now, in something like texting, I understand, when you're trying to type on that teeny phone keyboard. It's harder to hit the shift key when you don't have a spare finger because you're only using one.
Mobile operating systems (or is it just iOS?) by default turn the shift on automatically when starting a new sentence and are pretty consistently fast and right. It’s more surprising to me when someone doesn’t use proper capitalisation from mobile.
Strange to label a failure to capitalize words as a "dumb social media trend", as I'm sure people have been doing that for many years prior to social media.
And nobody tYpEs lIkE tHiS except when making a joke.
> as I'm sure people have been doing that for many years prior to social media.
But now it’s happening more frequently. That’s what “trend” means. It doesn’t mean it never happened before.
> And nobody tYpEs lIkE tHiS except when making a joke.
Just because you don’t know people like that, does not mean they don’t exist. The world is bigger than one person’s knowledge. I personally knew several teenagers who did it for all their communication, before smartphones. The speed at which they were able to do it was astounding.
What do you mean by "before" social media here? Surely not handwritten or typewritered letters, I guess you mean like 2005-2010ish?
The term wasn't popular then but with reddit's and Facebook's infancies being twenty years ago, "social media" (which I understand to refer to platforms where you can talk to people and post things about different topics, so broader and more person-oriented than an SMF forum but narrower than the WWW) have been around for a while
The first time I saw lowercase writing like this was two years ago on the Discord guild/community of a game which got popular on tiktok. I don't know the average age but the (statistical) mode was probably in the range of 13–16
If you were using Arc you could add a Boost for "Case: toggle between different capitalization settings - they will apply to all text on the webpage" [1]
Instead of knee jerk firebase is bad, can we discuss how this could be abated properly with firebase rules for firestore?
Is this the rule that was missing for arcs boosts or whatever object?
```
match /objects/{object} {
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
}
Arc was recommended to me by a friend. I deleted upon finding out I needed an account to use it. The excuse Arc gives is in case you want to sync. I'm capable of opting into that.
Great research. As I've said elsewhere, Firebase's authentication model is inherently broken and causes loads of issues, and people would be better off writing a small microservice or serverless function that fronts Firebase.
Also, for anyone trying to read the article, they should put `/oneko.js` in their adblocker.
Im dyslexic and I tend to use the pointer to follow what I am reading to help me. The cat was annoying as hell. I just had to hide the element in the DOM before i could read more than a few lines. Infuriating design choice to make it follow the pointer.
Too late to edit... i just got around to checking and I do have system wide reduced motion and reduced transparency on this laptop. I'm sure I didn't set it up on there, just on the phone.
That seems like a perfectly reasonable thing to sync. Accessibility settings are exactly the type of thing you shouldn’t have to configure again and again on every device.
Either way, you can disable syncing of system settings.
> That seems like a perfectly reasonable thing to sync. Accessibility settings are exactly the type of thing you shouldn’t have to configure again and again on every device.
No, because I disabled motion on my phone because the wiggling of icons on the main screen annoyed me, not because I have motion sickness. Nothing wiggles on the desktop (yet). This option doesn't even belong in accessibility IMO, it should be a "stop annoying me" section.
> Either way, you can disable syncing of system settings.
Where? The same spot where I can disable syncing the clipboard? I.e. somewhere deep in an undocumented file?
Gotta be honest, the aggressive and unreasonable snark completely turns me off from helping you. It feels that regardless of the obviousness of the setting, you’ll find some nitpick to shout back at me about it. Since I don’t work for Apple or yourself, I don’t have to justify their choices or be the recipient of your unjustified and unprompted bad humour. I’m making a conscious choice to not soil my Friday on account of some internet rando. You’re on your own for this one.
I genuinely wish you a calm weekend and peaceful start of the week.
Thanks for the martyrdom but last time I checked clipboard syncing it was a package with everything that gets synced, including sms forwarding etc on Apple. If there is a way to disable syncing granularly it’s not documented anywhere.
It's really not hard to build this safely in firebase, this could've been authored the same way in node too. I think whoever authored this either majorly cut corners or just isn't experienced enough to understand how to write authenticated controllers like this. This should scare people away from this browser, it's such a basic thing to mess up and it shouldn't have happened.
As a person that recently started using it: it has something like "tree style tabs", and sort of a hybrid merge of the concepts of tabs and bookmarks. In other words, the tabs work more like files on disk -- open/closed, sorted into folders. I'm probably not explaining it well either, but I encourage you to try it if you ever wanted to experiment with alternative tab management (tree style tab, tab groups etc). It's a concept that clicked for me quickly once I started using it, and now I'm angry since I want to use Firefox for philosophical reasons but don't want to go back to regular tabs.
The “what makes Arc different from other browsers” section is particularly funny.
> Arc is to your ex-browser what the iPhone was to cellphones. Or as one of our members said “like moving from a PC to a Mac.” It’s from the future — and just feels great.
It's a browser (chromium based) with a really nice UI that people love, I am intrigued but haven't used it because I find the requirement to create an account off-putting.
I roasted them on HN when they announced their product: Browsing the interest should not require an account. Its an "HTML Client", absolutely absurd. Hopefully they sit down and reconsider their choices.
It is remarkable that Arc has taken billions of dollars in VC cash but makes these rookie mistakes in securing their own backend that all of their users are accessing. Where are those billions of dollars going? Is it all just in marketing?
Probably the line of thinking is that security can be a back burner issue until product market fit is achieved.
Doesn't matter if you build the most secure product if nobody is using it, right? Where that breaks down is that a browser MUST be relatively secure, otherwise you've given up the whole ballgame.
I really enjoy Arc's approach to the browser interface, but I am kind of shocked that it requires firebase at all. It touts privacy, but we have to log in, and our data is being stored in a BAAS owned by Google. It would have been SO much simpler to make it so that data is owned by the user and stored on disk. At MOST, maybe a paid syncing feature would require an external database. A takeover path like this is a big deal, but as the author pointed out, you stored URL browsing data for boosts. "Privacy first" browser's are marketing jargon today, and that sucks.
> "Privacy first" browser's are marketing jargon today
A glance at Arc's privacy policy makes it clear they aren't privacy anything [1]. (Contrast their device and product usage data sections with Kagi's [2].)
It would be nice if I could download a version of the Arc browser with the cloud bits removed. I use it because of the UI/UX and pretty much ignore everything else. Really if there was a browser that let me keep organized spaces in a left panel plus create split screen views then it would immediately convince me to switch from Arc.
I know about Zen and Floorp. For my day to day browsing Arc has:
# Split screen tabs
Zen and Floorp both have this but the UX for both is really clunky. Surely they'll improve but Arc felt like second nature.
# Little Arcs
As far as I know, neither Zen or Floorp have this feature and if they do then the UX is not as obvious as Arc. The UX around Little Arcs is almost perfect. If I click on a link, it opens as a modal that I can expand to its own tab if I need or dismiss by just clicking away. The same things happens in other apps so I don't lose context just because I wanted to look at a link quick. If I do want to bring that tab into a space then it's 1-2 clicks away. My only gripe with this is that the Little Arcs that are created from clicking links in other apps don't auto dismiss if you change focus but this might just be a setting I don't have configured.
# Inset meetings/videos
AFAIK neither has this feature either. Having videos that are playing just seamlessly pop-up picture-in-picture when navigating away from the video tab is useful enough but the meeting feature is key for me because my company uses Google Meet. I can navigate away from meetings to look-up info/check Slack/etc without losing focus on the meeting itself and getting back to the meeting tab or unmuting myself is 1 click away.
Sure all of these things could probably be accomplished by browser extensions but I think the UI/UX within Arc is pretty tough to compete with.
the developers working with firebase should enforce common-sense document crud restrictions in the rules. that's just how firebase is. everyone knows it.
now, when talking about ARC BROWSER, i am seriously starting to doubt the competence of the team. I mean, if the rules are broken (no tests? no rules whatsoever?), what else is broken with ARC? are we to await a data leak from ARC?
any browser recommendations with proper vertical tabs and basically everything working like it does in ARC?
I did. It’s like 20 % an Arc clone, and 80 % of UX papercuts. Like, you can’t have ‘add tab’ button on top when the new tab gets added to the bottom. Or that one sidebar button opens a side window to the right of the sidebar, while another below it opens the favorites to the left and moves the whole sidebar from underneath your mouse.
Looks like a minimal effort css restyle of Firefox.
but the for-some-reason-not-obvious revelation that it's just a product that some team somewhere is working on and the fact that a browser is an important piece of software brought me back to safari (not sure if joke's on me, but in this case I trust apple engineers to do a more thorough job in ensuring my data is secure).
i'm rooting for them to succeed, but if the concern is security, switching your daily driver browser to a brand-new browser that's still in alpha is unfortunately not a good idea.
Vivaldi may also be worth a look. Similar setup: User-oriented team, vertical tabs, e2ee sync. If you like a thorough browser history, I think Vivaldi keeps a more detailed browsing history than most other Chromium browsers.
while researching, i saw some data being sent over to the server, like this query everytime you visit a site
I'm not surprised in the least --- basically the vast majority of software these days is spyware. Looking at Arc's privacy page, it appears to be mainly marketing fluff similar to what I've seen from other companies. I have yet to find a privacy policy that says frankly "we only know your IP and time you downloaded the software, for the few weeks before the server logs are overwritten."
> I have yet to find a privacy policy that says frankly "we only know your IP and time you downloaded the software, for the few weeks before the server logs are overwritten."
Not with those exact words, but that’s Alfred. Server connections are done only to validate the license and check for updates, and you can even disable that.
> Alfred only contacts our server when activating your Powerpack license in order to validate it, as well as periodically checking for new software updates. You can disable the software update check in the Update preferences, but we recommend keeping this enabled to ensure that you always have the latest version for security reasons and to make the most of the awesome new features!
> We’ve fixed the issues with leaking your current website on navigation while you had the Boost editor open. We don’t log these requests anywhere, and if you didn’t have the Boosts editor open these requests were not made. Regardless this is against our privacy policy and should have never been in the product to begin with.
We looked into supporting Arc at work, unfortunately Arc is missing lots of basic security controls which are available in many other Chromium and non-Chromium browsers, these include:
+ The ability to enforce automatic updates
+ Ability to control which sites extensions/boots are installed on
On top of this there seems to be no way to remove the requirement to have an account to use the browser, selectively choose what data is sent/sync'd from Arc, or disable basic features like Easel through which staff accidentally leak data.
The UI for the browser is great, but Arc really needs to lay the groundwork for strong security controls or it'll struggle to gain (or even maintain) a foothold in the enterprise space.
I’ve been using Arc since it was private, and I really like the browser. The company’s posture on this topic has pretty much made me drop it entirely. It’s beyond abysmal.
> i discovered that there was a arc featured called easels, easels
> are a whiteboard like interface, and you can share them with people,
> and they can view them on the web. when i clicked the share button
> however, there was no requests in my mitmproxy instance, so whats
> happening here?
I first noticed this on a flight to Paris. I was building a Flutter app using Firestore, and tho I had not paid for the onboard wifi (I was doing local development) I was connected and all of my Firestore calls were succeeding.
I thought this was novel, and assumed it was just something to do with websockets, so I switched to another, non-firebase-but-yes-websockets project and noticed it didn't work.
At the time, I debated moving calls to Firebase just so that I could work for free while I was on flights, but realized the ROI wasn't remotely there. Glad to finally have someone else acknowledge it happening, and give some insight as to why.
Some flights have a free tier of wifi that allows messaging apps. Google Voice and Google Hangouts usually work on those so wouldn't be surprised if some other Google services make it through.
Apparently the company had contracted with one Latacora for "regular outside security reviews and trainings across a wide range of different systems".
Elsewhere on the page, it says "Arc uses GCP Firebase for user authentication, storage for Notes & Easels, and Cloud Functions for certain application features like referral code generation. All data stored in Firebase is encrypted-at-rest by default."
The security page explicitly claims that Arc doesn't log what you're doing, giving URLs as an example, but this vulnerability claims every URL is being sent up to Firebase.
User identity must be derived from security context, typically at the edge of the system.
But it’s so much easier for developers to think of userid as just another parameter, and they forget, and oops now they trust a random user-supplied parameter.
The firebases and the supabases of the world are crazy to me to build your company on. You are asking for trouble and anchoring your entire company on the health of one saas that is hooked into the foundational aspects of your application!
also it's so incredibly easy to really fuck up and build something exploitable.
are javascript devs really that afraid of doing things themselves to this extreme level?
What about S3, you don't really need a file storage provider either?
> are javascript devs really that afraid
You might be afraid of JS devs :P Anyway has nothing to do with language, even if it was a super c0ol Ruby-on-Rails app with Active Record and SQL db on a server you manage it's still common to have some stuff in NoSQL for fast access to live data, caches, logs, etc. Most companies at scale will have both SQL and NoSQL dbs in areas. So if you're already using S3 for files, code on GitHub, storing keys in 1Pass, why not use a Firebase or MongoDB for high traffic live data? Especially if they offer built-in scaling and geo deploy options.
This scenario I laid out is kinda to your point of "don't anchor your entire company on it" - the only point I'm trying to add is that you can also use these tools without the company being "anchored" on it, and they could have still ran into the same issue as Arc.
Vercel too?! What are you using for SSR + serverless, Amplify?
Vercel seems pretty great for a React-centric app with a couple of one-off backend calls to cloud services, super convenient, deploy previews in GitHub etc. why not?
This is a nice investigation and a great read. Sad that they don't normally do bug bounties. $2000 seems small considering the severity of this vulnerability. Though I guess the size and finances of the company is a factor. It takes some serious skills, effort and luck to discover something like that. It should be well compensated.
It is troubling that the browser that cannot be used anonymously displayed questionable behavior adjacent to the mechanism that tells The Browser Company every time you are watching porn
I know Firebase is awesome for plenty of reasons. And I’m not disparaging anyone who works hard on it. There’s a ton of great software behind the product.
Unfortunately it’s at the root of almost all of my career’s worst bugs and mistakes (not necessarily caused by me), and it seems like a bit of train wreck in the wrong hands. I’ve had to rescue several clients from it, and have migrated three pretty huge applications off of it now.
I’m not sure what it is exactly. People really abuse the hell out of it.
> firestore has a tendency to not abide by the system proxy settings in the Swift SDK for firebase, so going off my hunch, i wrote a frida script to dump the relevant calls.
As someone who has done some reverse engineering of macOS apps but haven't used anything beyond Charles' macOS proxy feature, this looks very painful. Is there a proxy app that maybe acts as a VPN so that basically every HTTP request is guaranteed to go through it, so that you don't need to write a hundred lines of bespoke Frida just to capture requests?
Edit: On second thought Proxifier should work for this purpose.
I just want to say that Firebase security rules deny every operation by default. An empty rules file allows nothing.
The devs that wrote these rules had to intentionally allow overly broad reads/writes to this part of their database in order to create this vulnerability. And this had to pass code review and automated testing.
That’s not good, and it has nothing to do with their choice of tools.
Oop and I just convinced my wife and brother to move over :o
Props to her, she asked about the security and privacy of the browser and I played it off with some fanboy propaganda. Lesson learned on that one. If I only care about the vertical tabs, workspaces, and a (decent) mobile app are there any good equivalents right now?
> If I only care about the vertical tabs, workspaces, and a (decent) mobile app are there any good equivalents right now?
I use Firefox mostly because of Sideberry (which does vertical tree-style tabs) which also integrates with "containers", so you can have something similar to workspaces but more isolation. Otherwise there is also "profiles" that probably offer even more isolation between the different profiles.
Firefox with extensions? The current vertical tabs extensions are not nearly as nice, but Mozilla is working on native vertical tabs. Syncing and Workspaces are already better with Firefox then with Arc.
I just use Brave with a shitton of profiles. That does cause problems for mobile use since no Android browser dev has bothered with proper profiles or ability to install multiple copies of the browser, except for Google I guess.
I use Firefox with Sidebery for vertical (specifically, tree style) tabs, plus a userChrome.css to hide the native horizontal tabs. Firefox has mobile apps, and the Android app supports (some) browser extensions.
It works, it's boring, and it doesn't try to shove gimmicky features in my face.
…Firefox as an alternative to Chrome!? Am I really that old!?
I used Chrome for years and years, right from when it first came out. Since then, I switched back to Firefox, and have used it for years. It works perfectly fine.
hmm gee I wonder was it worth to value the bug bounty at $2500 given the severity of both the bug and sheer lack skills of the browser company staff...it might even be a reputation destroyed event...
Yeah with this and the privacy zinger at the end its definitely time my monthlong experiment with arc comes to a close. Too bad that the thing theyre actually proud of, the tabbing UX, was actually really good.
Maybe I am just stupid, but this *super* smells of arc being able to inject whatever they want in to literally any of your websites and this dude just figured out that he could also do that.
This does not seem like a browser capability I want.
The super promise died with crypto, now you have to add no backsies. My site uses No Backsies Proofs (NBPs) which are encrypted to prove that all my super promises are backed by a no backsie which is stored in the no backsie vault in Antarctica.
Later on moxie ends up writing a quick review of NBPs
> Instead of storing the data on-chain, NBPs instead contain a URL that points to the data. What surprised me about the standards was that there’s no hash commitment for the data located at the URL. Looking at many of the NBPs on popular marketplaces being sold for tens, hundreds, or millions of dollars, that URL often just points to some VPS running Apache somewhere. Anyone with access to that machine, anyone who buys that domain name in the future, or anyone who compromises that machine can change the image, title, description, etc for the NBP to whatever they’d like at any time (regardless of whether or not they “own” the token). There’s nothing in the NBP spec that tells you what the image “should” be, or even allows you to confirm whether something is the “correct” image.
this is why my startup is launching backsies rollups for the blob, with null-effect prebacksies. this way everyone can be assured that any backsies issued are technically equivalent to just not making the original agreement! if you can discover a post-agreement backsie within the availability period of 0 days, and we can confirm it, we'll pay you $2,000 no backsies. so we have a market incentive not to lie to you. it's very efficient
I would feel more comfortable if your super promises were all on a blockchain, and we made No Backsie NFTs so people could clearly see these were legitimate and bid on them.
Yea if everything else is not enough of a red flag here, the fact that they are sending every single website you visit to Firebase — against stated privacy policies — is the mother of all red flags.
People say they like arc for the UI and there are all alternatives, but do you really want to risk someone stealing your bank creds and stealing all your money for some fancy UI?
I've got a different take. If they're in the VC phase, that means they are not self sufficient. The amount of funding that they've raised is no indication what-so-ever of a) how much of that funding has actually been realized / received b) what their overhead is and c) what their overall financial picture looks like.
I do wish that more companies would take privacy and security seriously. And bug bounty programs are great. But they're not always within the budget of companies and the fact that they decided to award this security researcher regardless of having no such program is a massive win in my opinion and shows how much they value this particular contribution.
Thanks for the reply! I think I disagree with you, mostly because it seems like this particular bug could have been company-destroying because of the potential reputation hit if it was exploited on a wide scale.
But regardless, I appreciate your perspective and it gives me some stuff to consider I hadn't previously.
I think we all know that tech debt often lives forever, so if you're going to start a browser company, you simply must be thinking about security/privacy from day one. If the VC model doesn't make that possible, then the only reasonable conclusion is that browsers shouldn't be a thing that VC funded startups work on.
I appreciate your response, and largely agree with you. But you can take security seriously without having a program in place to pay non employees for work they did without you asking them to.
Also, while I love companies that have bug bounty programs... I don't think any company without such a program is under any obligation to pay someone just because they volunteered their time without the company knowing about it or soliciting the work in any way.
So the fact that they did in this case, despite having no program, is what I'm choosing to focus on.
I want to share a personal anecdote to put my opinion into more perspective. I owned a small business operating a for-profit website for 18 years, for 15 of those years it was my primary source of income. I had no employees other than myself. It was just me on my own working from home. I earned enough to pay the bills, but I'm currently earning 2x what my business earned at its peak traffic by being an employee. So it's not like I had money to be paying people... it was pretty much an average software engineer's salary in terms of what I brought in.
Anyway, over those 18 years I had a few dealings with some white-hats who were very nice and clued me in to some issues. I thanked them and when they politely asked if "we" (because they didn't know any better) had a program it was a non-issue when I explained that I'm too broke as a one-person shop trying to feed a family to be paying out anything substantial but I could PayPal a cup of coffee or something for their trouble. But then I had a few dealings with complete shady assholes who tried to extort money out of me by threatening to exploit what they had found and go public and basically drag my reputation through the mud.
Experiences with the latter group make me sympathize a lot more with companies that decide to have a policy of just blanket not dealing with outside security researchers, to take the information and then deal with the fixes internally and quietly.
Arc is a great product, it's the nicest web browser to use, you can tell these people are really good at their jobs in many respects (though apparently not security?!?). probably a lot of investors saw that too and are willing to fund a very strong team with the hope of eventual product-market fit.
They claim so much and their browsers' code is 100% proprietary so it's impossiblen to verify their lies. This is what triggered the bullshit detector in my head
> They claim so much and their browsers' code is 100% proprietary
Far from me to defend Arc (I dislike it for several reasons) but it’s based on Chromium so it’s far from 100% proprietary. Don’t Edge, Vivaldi, and even Chrome have proprietary layers on top of the open-source Chromium?
HN tends to be a little hard on brief comments. My current understanding is that comments with little substance are totally acceptable provided they're good natured.
Also from the guidelines "Comments should get more thoughtful and substantive, not less, as a topic gets more divisive": this post's topic doesn't likely qualify as divisive.
Damn, that is bad. While I enjoyed reading through the write-up, I think a "summary section" at the top would have benefited me lol.
Someone recently recommended Arc to me, I installed it on my macbook and then never actually used it when I realized there's no Linux version available, and I like a consistent browser experience across all my devices.
I’m Hursh, cofounder and CTO of The Browser Company (the company that makes Arc). Even though no users were affected and we patched it right away, the hypothetical depth of this vulnerability is unacceptable. We’ve written up some technical details and how we’ll improve in the future (including moving off Firebase and setting up a proper bug bounty program) here: https://arc.net/blog/CVE-2024-45489-incident-response.
I'm really sorry about this, both the vuln itself and the delayed comms around it, and really appreciate all the feedback here – everything from disappointment to outrage to encouragement. It holds us accountable to do better, and makes sure we prioritize this moving forward. Thank you so much.
Was the post written for HN users only? I cannot see it on your blog page (https://arc.net/blog). It’s not posted on your twitter either. Your whole handling seems to be responding only if there is enough noise about it.
Hursh, can you please respond to the above commenter? As an early adopter, I find it fairly troubling to see a company that touts transparency hide the blog post and only publicly "own up to it" within the confines of a single HN thread.
We’re working on a proper security bulletin site that will have these front and center! This was a bit of a stopgap for now.
Security bulletin is posted up top on the blog page now, but I have to say it doesn't exactly give me a warm and fuzzy feeling.
It falls a bit flat for me where you address the tracking of domains visited by users, I don't think this accurately addresses or identifies the core issues. When you say "this is against our privacy policy and should have never been in the product to begin with"--okay, so how did get there? This wasn't a data leak due to a bug it was an intentionally designed feature that made its way through any review process which might be in place to production without being challenged. What processes will you put in place to prevent future hidden violations of your stated policies?
Edit just to say, dubious as I am I sincerely hope Arc can overcome these issues and succeed. We desparately need more browsers, badly enough that I'll even settle for a Chromium-based one as long as it isn't made by Microsoft.
Right now You and Arc are advertising it's ideal to position posts such as "Hidden Features in Arc Search" to users but security bulletins and remediations are something that need a hidden stopgap until you've scrambled to build an alternative site to hide them away at instead.
Browser security is more than finding the best PR strategy, it's a mindset that prioritizes the user's well being over the product's image. I've deleted my account and uninstalled Arc. Not because of the issue in itself, but because it's clear what the response has been aiming to protect (not my data).
The sibling comment to this by sieabahlpark is already dead but to respond in case they get a chance to read the thread again anways:
The engineers already closed the hole, the blog post was already published, more work was (/is still?) going to be done to make a new site to hide them in. I wasn't asking for them to move engineers off patching to blog posting, I was asking for the already created blog posting to be made as visible in the blog the same as the posts were (which is now the case, so at least there is that).
In regards to whether or not they did analysis to show it wasn't exploited that was indeed nice to see but you still have to make the post visible anyways because you're not always right, even if you're one of the biggest companies in the world https://www.theregister.com/2024/09/17/microsoft_zero_day_sp... The measure to meet here is transparency, not perfection.
And no, I wasn't really sitting around waiting for a good opportunity to delete my account and uninstall my main browser. That would be... very odd? I'm free to change browser without a reason to blame haha. I didn't say what I was switching to either (it's quite irrelevant to the topic), which can certainly be more than one of 2 options you have quips for. Regardless which option, the measure to meet here is again not perfection but transparency and yes, others do meet that well and above how Arc did in this case.
More than anything, the reason for responding is less to argue about most of those points (I even debate just removing them now as they may detract from the point) and more to point out "real" transparency on security incidents (not just what a PR person would say gives the best image) is as big a factor in trusting a company with your data as their actual response to vulnerabilities. It doesn't matter that a company looks great 100% of the time they tell you about things if you know they are being intentionally stingy on showing you anything about it since you now have no way to trust they'd show you the bad anyways.
(repeat of the above response type. Sorry if this breaks a rule or something Dang, but it's a pretty tame/decent conversation)
This is still responding to a different complaint. The operational performance of "optimally distributing" the message, or however you want to word it, on was/is both imperfect and perfectly fine at the same time. Where the ball was dropped was in responding to a complaint about how the posting was specially hidden where the communicated action was how it will be shown on a different site in the future in place of acknowledging it should be visible as a normal post currently.
When the alarms are going off you're going to be slow, you're going to make the wrong decision on something minor, you're going to wish you had done x by y point in time looking back, you're going to have been imperfect. All that kind of stuff was handled fine (from what I can tell) here. The disappointment in transparency was in deflecting a presented highlight in how to fix a visibility issue instead of outright acknowledging it was a miss.
My message was/is about how that's not cool. Not that their handling of the issue itself was bad or an expectation of apology or expectation more resources should have been put on doing x, y, or z. Just that deflecting callouts on security communication issues with deferrals and redirection is not a cool way to handle security communication. They've since changed it, which is cool of them, but the damage was done with me (and maybe some others) in the meantime. Maybe in the future they handle that differently, maybe they don't, but for now I lost the trust I had that they always will, even when nobody is looking, since they didn't even when they knew people were.
[dead]
why would even use a browser that requires you to have an account to use it? It screamed security vector and was the only reason I chose not to use it
[dead]
Pretty obvious now that Arc will only share security alerts with the people who "catch" them at it - as few as possible
Leaves no choice but for this community to make the rest of the Arc community aware of it as they refuse the transparency
Not a good look it not being on the main page! I personally use [zen browser](https://github.com/zen-browser/desktop); I like the ideas of Arc, but it always seemed sketchy to me, especially it being Chromium-based and closed-source.
Heads up: HN doesn't support link naming markdown and some of the extra characters broke the hyperlink.
In case the parent can't fix it in time for the edit window: https://github.com/zen-browser/desktop
I wouldn't be surprised if some HN client apps support markdown.
I use the Octal app on iOS which does, though it seems the trailing ; broke the link for this md renderer.
I think GP is my most downvoted comment ever. Of all things haha.
I used Arc for a while because despite my misgivings about using a browser that requires an account etc the workflow was very good for me
I started moving to Zen about a week ago, hearing about this vulnerability yesterday and especially seeing their reaction to it I know I made the right choice in leaving Arc.
The only feature Zen browser missing is tab folders, once they implement it I really don't have a reason to have Arc browser anymore.
Hell despite missing tab groups, Zen browser is the only browser that finally had a "good enough" vertical tabs implementation, which allowed me to finally drop Edge as my main browser.
I'd be curious for your comparison to Waterfox, which added vertical tab integration a while ago.
What do you not like about Firefox's Tree Style Tabs? I might be open to an alternative.
I Cant't hide the tab bar without some userProfile.css hacks, while in Zen it has first class support.
It's more a matter of saving precious vertical space.
I see. Yes, I already hid the stock tab bar years ago and forgot about it.
zen looks really nice! thanks for the pointer.
Hi Hursh, I'm Tom. A couple friends use Arc and they like it, so I had considered switching to it myself. Now, I won't, not really because of this vulnerability itself (startups make mistakes), but because you paid a measly $2k bounty for a bug that owns, in a dangerous way, all of your users. I won't use a browser made by a vendor who takes the security of their users this unseriously.
By the way, I don't know for sure, but given the severity I suspect on the black market this bug would have gone for a _lot_ more than $2k.
Selling vulnerability on the black market is immoral and may be illegal. The goal of bug bounty programs was initially to signal "we won't sue white hat researchers who disclose their findings to us", when did it evolve into "pay me more than criminals would, or else"?
Let's set aside morality for a second. There is a reason low payouts are bad without even having to consider the black market: it pushes people to search for bugs in a competitor's app that pays more instead of in your app!
If your app is paying out $2K and a competing app pays out $100K, why would anyone bother searching for bugs in your app? Every minute spent researching your app pay 1/50th of what you'd get searching in the competing app (unless your app has 50x more bugs I suppose, but perhaps then you have bigger problems...).
I'm always so confused by the negative responses to people asking for higher bug bounties. It feels like it still comes from this weird entitlement that researchers owe you the bug report. Perhaps they do. But you know what they definitely don't owe you? Looking for new bugs! Ultimately this attitude always leads to the same place: the places that pay more protect their users better. It is thus completely reasonable to decide not to use a product as a user if the company that makes the product isn't paying high bug bounties. It's the same as discovering that a restaurant is cheeping out on health inspections and deciding to no longer eat there.
Bug bounties are always in relation to severity, number of users potentially at risk, and market cap. A browser operating at a deficit from a small company with a small market share cannot pay 100k even if they wanted to.
If you and a couple friends released an app that had 50k users and you’d not even broken even, can I claim my 100k by finding a critical RCE?
No, because you probably haven’t bothered to find said CVE. There’s a strange refusal to understand the simplest market considerations here. I understand it sucks and you may not be able to afford it, but the consequence, regardless of all the reasons you can give, is that you will get less of the right kind of attention (security researchers). Now, you can hope that you will also get less of the wrong kind of attention too, and if you’re lucky all of these will scale together. Or, alternatively, you can for example not start by introducing features like Boosts that have a higher probability of adding security vulnerabilities, counter-acting the initial benefit of riding in Chrome’s security by using the same engine. Browsers are particularly sensitive products. It’s a tough space because you’re asking users to live their life in there. In theory using Chromium as a base should be a good hack to be able to do this while plausibly offering comparable security to the well established players.
Long story short, there are ways to creatively solve this problem, or avoid it, but simply exclaiming “well it would be too hard to do the necessary thing” is probably not a good solution.
lol, that’s not how this works, that’s not how any of this works…
you cannot demand more than someone is willing to or able to pay, either a researcher out there will spend some time on it because it’s a relatively new contender to the market and they’re hoping for low hanging fruit, or they won’t.
obviously the bounty was enough for someone to look at it and get paid out for a find, otherwise we wouldn’t be having this conversation. trying to argue that they should set a bounty high enough to make it worth your time is pointless and a funny stance to take. feel free to ignore it or be upset that they aren’t offering enough to make you feel secure, it’s not going to make 100k appear out of thin air.
I’m not a security researcher, so it’s really not about me. You seem to be confused about what we’re even arguing about, this discussion started because someone said they wouldn’t use this browser because the low bug bounty amount represents that the company isn’t taking security seriously. My posts simply defend why this is a perfectly reasonable stance to take. They are not me demanding an increase in bug bounties so that I will work on them. A good trick if you’re ever confused about a discussion is to simply scroll up and read the posts, I’ll make it even easier for you, this is where it starts: https://news.ycombinator.com/item?id=41606272
Secondly, in a true demonstration of confusion, if you read my posts they demand nothing. They simply state what are likely outcomes of certain choices. I’m not sure how to possibly make the stance of “if you pay smaller bug bounties in a market that has other offerings, you will get less research focused on your product” any simpler. It seems fairly straightforward… and the existence of one bug report does not somehow “disprove” this. Why not make the bug bounty $1 otherwise? Oh, is that a ridiculous suggestion? Because that might not be a worthwhile enough incentive perhaps? But who are you to dictate what is and isn’t a worthwhile incentive. “That’s not how this works. That’s not how any of this works…”
> “either a researcher out there will spend some time on it […] or they won’t.”
Yes, I agree with this truism that they either will spend time on it or they won’t. Interestingly, this is true in all scenarios. My point is how to optimize researchers spending time on your product (which in theory you are inclined to do if your are offering a bounty), and I then separately even make suggestions for how to possibly require less attention by making safer choices and being able to “ride” on another project’s bug bounties.
But again, the simplest point here is that the position of “we offer low bug bounties because that is what we can afford” is fine, it’s just also absolutely defensible to be completely turned off by it as a potential user of that product, for the likely security implications of that position.
[dead]
Put it this way. If someone got hold of the vuln and exploited all the users and they all sued you, how much would it cost to defend yourself in court (not even considering winning or losing)
Right, part of the idea is to close the gap in incentives for white hats looking for vulnerabilities to report and black hats looking for the same to exploit. You don't have to beat the black market price of a vuln because that route is much riskier, but somewhere at least in the same order of magnitude sounds decent.
It's not about viewing security researchers as sociopaths who will always sell to the highest bidder, the fact is there will always be criminals going for exploits and bug bounties can help not just by paying off someone that would have otherwise abused a bug but also by attracting an equally motivated team who would otherwise be entirely uninvolved to play defense.
> because you paid a measly $2k bounty for a bug that owns, in a dangerous way, all of your users
The case is redeemable. It may still be an opportunity if handled deftly. But it would require an almost theatrical display of generosity to the white hat (together, likely, with a re-constituting of the engineering team).
You have no idea but you suspect someone could have made more?
After thinking about it for a good long ten seconds, yeah. It would be very easy to steal users' banking information with this. If you crack into one single bank account you have a decent shot at making over $2k right there, a skilled hacker could do a lot more.
That is generally how suspicions work
So you're not going to use Arc. How much do you pay for the browser you do use?
Statistically, Tom is using a browser that cost him $0. Why are you asking?
Thousands
Should have at least paid €1 per user. Eh, maybe that’s what they did?
Comments further down are concerned that on each page load, you're sending both the URL and a(n identifiable?) user ID to TBC. You may want to comment on that, since I think it's reasonable to say that those of us using not-Chrome (I don't use Arc personally, but I'm definitely in the 1% of browser users) are likely to also be the sort of person concerned with privacy. Vulnerabilities happen, but sending browsing data seems like a deliberate design choice.
I think that is addressed in the post. Apparently the URL was only sent under certain conditions and has since been addressed:
>We’ve fixed the issues with leaking your current website on navigation while you had the Boost editor open. We don’t log these requests anywhere, and if you didn’t have the Boosts editor open these requests were not made. Regardless this is against our privacy policy and should have never been in the product to begin with.
Given the context (boosts need to know the URL they apply to after all) this indeed was a "deliberate design choice" but not in the manner you appear to be suggesting. It's still very worrisome, I agree.
There isn't really anything you can do to convince me that your team has the expertise to maintain a browser after this. It doesn't matter that you have fixed it, your team is clearly not capable of writing a secure browser, now or ever.
I think this should be a resigning matter for the CTO.
And what, you’re going to find them a new CTO? What kind of magical world do you live in where problems are solved by leaders resigning, instead of stepping up and taking accountability?
Taking accountability can and should include admitting you're the wrong person for the job and resigning.
CTO is simply a title, the proper response here would be to hire a head of security and build it into the culture from the ground up.
I'm looking at all of the Arc Max features which probably need to be architected correctly to be secure/privacy-preserving.
They could take a lot of inspiration from iCloud Private Relay and iOS security architectures in addition to really understanding the Chrome security model.
If the devs didn't take security seriously before, why would another node in the communication graph change anything?
because sometimes it's a deadline pushed by management so a change could result in allow more time for design, programming, review, or even full time security personnel. Nobody writes the best most secure software under deadline
Yes, the right person maybe can change the culture in the company (plus contribute lots of technical skills)
What kind of accountability is it when there's no personal consequences?
Yeah, I also think that asking someone to resign for this does not look like a proportionate response
They are owning up to their mistakes and making sure such things don't happen again (and increasing the amount from 2K :-)) seems like the right approach to me
Surprise surprise, turns out it takes a looong time for every software startup to finally strip out all the hacky stuff from their MVP days. Apparently nobody on this startup community forum has ever built a startup before.
Pro tip: if stuff like this violently upsets you, never be an early adopter of anything. Wait 5-10 years and then make your move.
Personally, I expect stuff like this from challenger alternatives, this is the way it should be. There is no such thing as a new, bug-free software product. Software gets good by gaining adoption and going through battle testing, it’s never the other way around like some big company worker would imagine.
I don't think you understood the severity or the noobiness of the error. This is a browser not a crud app or electron app. A browser is a complex system level piece of software not a hacky mvp and this kind of error shows that maybe they don't have the competence to be building something like this. It makes you wonder what other basic flaws are there just waiting to be exploited, even if its built on top of chromium. Would you fly in an mvp airplane built by bicycle engineers? (maybe not the best analogy since the first airplane was built by bicycle engineers)
Agreed, I wouldn’t have hopped on the first airplane with some bicyclist named Wilbur. That would involve risk of immediate physical harm.
On the other hand, we’re talking about a 2 year old browser leaking what websites you visit. Do you also think Firefox in 2006 was bulletproof? The entire internet and every single OS & browser was a leaky bucket back then.
The current safety-ism, paranoia and risk-aversion around consumer software on this forum is hilarious to me. Maybe they shouldn’t have called this place “Hacker” news, because it’s now full of people LARPing as international intelligence agency targets from a 90s movie. If the prying Five Eyes are such a concern for you, maybe use a fake email when signing up for stuff and your browser history is instantly anonymized.
Yes, startups involve lots of risk (to everyone involved, users/employees/founders/investors). But risk is the only way we get new things. If you those risks are too scary for you, stay far away startups.
You're speaking in bland hand-wavy generalities and like I said before I'm not sure you understood the issue or even read the write-up since you're not really addressing it specifically (it's a whole lot more than 'leaking'). To extend the analogy, this is like having bike engineers build an mvp supersonic jet and you find out they are using bike brakes to stop the thing. Its not even just merely an error its about some very questionable architecture. This is not a mozilla innovating the browser and making the mistakes you get when you're experimenting-and-innovating-something-new type situation at all and it has nothing to do with paranoia or five-eyes lol.
[flagged]
Well, the current team perhaps.
But it's also likely part of the startup mentally of "move fast and break things", which is not entirely compatible with the goal of the browser.
Will you be increasing the bug bounty payout? $2,000 is a tiny fraction of what this bug is worth, I hope you will pay the discoverer a proper bounty.
You've been handed a golden opportunity to set the right course.
> $2,000 is a tiny fraction of what this bug is worth
The Browser Company raises $50mm at a $550mm post-money valuation in March [1]. They’ve raised $125mm altogether.
Unless they’re absolute asshats, they’ll increase the bug payout. But people act truly when they don’t think they’re being watched—a vulnerability of this magnitude was worth $2k to this company. That’s…eyebrow raising.
[1] https://techcrunch.com/2024/03/21/the-browser-company-raises...
"We will let anyone run arbitrary JavaScript on all your web pages if you send them a referral link" is surely a 6-7 figure vulnerability for a web browser. That this vulnerability was discoverable using about two steps of analysis tools suggests many more issues are in the product.
Not just that - seems like it allowed running privileged JavaScript (full access to your system) on the preferences page as well.
It is very strange to me that their attitude is "no one was impacted" and this is "hypothetical". Any serious company would immediately consider this to be a case where everyone was impacted! This is like coming home to the worst neighborhood on the planet to find your door wide open, and immediately putting on a blindfold so you can continue to pretend nothing's changed.
Since everything is stored in their DB, they supposedly can audit logs and sources for boosts themselves to confirm if anyone was actually impacted.
Can you explain? How are they able to check whether someone did a quick “in and out” keylogger or cookie extraction? I doubt they can, because I doubt they store every request (that would go against what they claim for privacy) and I also doubt their DB backup happens on such a high frequency that they could catch this (e.g. minute-to-minute).
So…how? Are you claiming they have oodles of logs and a perfect dork* to find suspicious JavaScript? If they had the latter wouldn’t they already be using it for security?
If you have some method that works do tell.
* https://www.alibabacloud.com/blog/what-is-dork_600025
I don't think you're using "dorking" correctly here, since web crawlers aren't anywhere in the picture. Server log queries aren't "dorks." Besides, if you can reproduce the issue and _if_ it's somehow logged in the database, it's usually not too hard to figure out how to query for other occurrences.
With that said, I think you're probably right. I doubt Firebase audit logs contain update contents, and based on the bug report, your "in and out" proposal is as simple as:
firebase.collection("boosts").where("creatorID", "==", "attackers_user_id").update({"creatorId": "victims_user_id" });
sleep(time);
firebase.collection("boosts").where("creatorID", "==", "victims_user_id").update({"creatorId": "attackers_user_id" });
(okay, not exactly, because this would also set the ownership of the victim's legitimate Boosts, but the actual code isn't much more difficult).
They have more users than what I could have guessed:
> As of July 2023, The Browser Company has 100,000+ users
https://www.boringbusinessnerd.com/startups/the-browser-comp....
It doesn't matter what bug bounty pay pay. If it was 200k people would say it's not enough.
Any new vulnerability will be sold to the highest bidder and/or exploited instead of being reported for the bug bounty because of this.
I know a lot of different people who do independent security research and have submitted vulns to bounty programs. Not a single one would even come close to saying "well, the bounty is low so I'll sell this on the black market."
Low bounties might mean that somebody doesn't bother to look at a product or doesn't bother to disclose beyond firing off an email or maybe even just publishes details on their blog on their own.
Bounties aren't really meant to compete with black markets. This is true even for the major tech companies that have large bounties.
Most of the vulnerabilities I've disclosed, and I've seen disclosed, were disclosed for free, with no expectation of getting anything. Why do you think every researcher is an amoral penny pincher who will just sell exploits without caring for the consequences?
Wanting money to live = penny pinching. Very cool.
Projecting?
Hursh responded elsewhere on the thread:
https://news.ycombinator.com/item?id=41606219
> including moving off Firebase
Firebase is not to blame here. It's a solid technology which just has to be used properly. Google highlights the fact that setting up ACLs is critical and provides examples on how to set them up correctly.
If none of the developers who were integrating the product into Arc bothered about dealing with the ACLs, then they are either noobs or simply didn't care about security.
Saying Google provides examples of being rather nice about it.
Firebase ACLs are a constant source of vulnerabilities largely because they are confusing and don't have enough documentation around them.
> We’re also bolstering our security team, and have hired a new senior security engineer.
Is there a reason why you don’t have any security-specific positions open on your careers site?
We did but we closed the roles by hiring folks. They just haven’t joined yet.
Until this individual comes back and responds to at least a few of the questions/comments, I don't think we should even pay attention to this marketing-dept-written post. They basically want this to go away, and answering any questions would raise more issues most likely, so they just seemed to have done the bare minimum and left it at that. It's 3 hours later now, they might as well have not even posted anything here.
$2000 is an absurdly small bounty here - you should up that
50k or 100k would be far more appropriate given the severity of this issue. But overall, this makes me think there's probably a lot more vulnerabilities in Arc that are undiscovered/unpatched.
Also, there's the whole notion of every URL you visit being sent to Firebase -- were these logged? Awful for a browser.
Ya this is fair! Honestly this was our first bounty ever awarded and we could have been more thoughtful. We’re currently setting up a proper program and based on that rubric will adjust accordingly.
> Honestly this was our first bounty ever awarded and we could have been more thoughtful
That’s corporate speak for “no, we won’t pay the researcher any more money.”
$200k for this big bug.
My comment has been downvoted twice, but I don't see it grayed out, I wonder why.
So when there are near weekly reports of websites being compromised due to horrid Firebase configuration, did absolutely no one on your teams raise a red flag? Is there some super low-pri ticket that says "actually make sure we use ACLs on Firebase"?
I think the bigger question is: Why are you violating your own security policy by keeping track on what we browse. I though my browsing is private and hidden away from you but if you store my browsing data in your firebase this is not acceptable at all.
> "...the hypothetical depth of this vulnerability is unacceptable."
What is also unacceptable is to pay 2000 dollars for something like this AND have to create user accounts to use your browser. Will definitely stay away from it.
no mention of the pitiful bounty reward (2000 usd). only sorry and thanks. Please award this person a proper bounty.
Are you going to address the part where you send visited websites to Firebase which goes against your privacy policy of not tracking visited URLs?
Only $2k for an exploit like this?
I like Arc, and I don’t want to pile on: God knows I’ve written vulnerable code.
To explore a constructive angle both for the industry generally and the Browser Company specifically: hire this clever hacker who pwned your shit in a well-remunerated and high-profile way.
The Browser Company is trying to break tradition with a lot of obsolete Web norms, how about paying bullshit bounties under pressure rather than posting the underground experts to guard the henhouse.
If the Browser Company started a small but aggressive internal red team on the biohazard that is the modern web?
I’ll learn some new keyboard shortcuts and I bet a lot of people will.
>Arc brought order to the chaos that was my online life. There’s no going back.
Bringing the chaos back like it's 1999.
I misread your name as Hush which is kind of fitting considering how you're trying to make this go away
Hursh / ha470, where did you go? There are lots of good questions in the replies to your thread, yet you went dark immediately after posting more than 8 hours ago. It's hard to imagine what could be more pressing than addressing people's concerns after a major security incident such as this.
To be honest, I'm a bit disappointed. For future reference, this doesn't seem like a good strategy to contain reputational damage.
ngl this is pretty pathetic. the massive security hole is one thing but you're just gonna gloss over violating your own privacy policy?
remember when reading this that this guy's company is valued at a billion dollars and his comp is 10x yours if not more. we live in a meritocracy
Bro you should be requiring accounts to download HTML. Come on man.
Pay the guy properly. $2000 is an insult. It should be $50k. This kind of bug could be sold for 100-200k easily.
> This kind of bug could be sold for 100-200k easily
Maybe not. If the browser is that buggy, there may be plenty of these lying around. The company itself is pricing the vulnerability at $2k. That should speak volumes to their internal view of their product.
Many engineers at SV startups use Arc on a daily basis. This bug could've resulted in the compromise of multiple companies, probably including crypto exchanges. A browser bug of this severity is extremely valuable, even for a niche browser like Arc.
> Many engineers at SV startups use Arc on a daily basis
Do we have adoption statistics?
It would seem prudent for the browser to be banned in professional environments. (I use Kagi's Orion browser as a personal browser on MacOS. My work is done in Firefox.)
> browser bug of this severity is extremely valuable, even for a niche browser like Arc
Absolutely. (Even if it were in beta.)
What I'm trying to say is the $2k payout sends a message. One, that The Browser Company doesn't take security seriously. And/or two, that they don't think they could pay out a larger number given the state of their codebase.
Side note: my favourite content on crisis management is this 2-minute video by Scott Galloway [1]. (Ignore the political colour.)
[1] https://www.youtube.com/watch?v=PB-AyvgE8Ns
There is also 3: putting a big bounty out signals other very smart and ingenious security researchers that Arc is a lucrative opportunity to make money. Till now it's been "safe" in relative obscurity so not a lot of people focused on hacking it or gave it a lot of effort because it wasn't worth their time.
It’s already going to be under the microscope now from black hats, so unless they want a catastrophic issue to result in user harm, they better get their act together.
I think OP mean to say "this bug could let an attacker gain $200k of value easily", though you are right the market clearing price for such a vulnerability is probably low due to huge supply.
[flagged]
Thanks for the response.
While people might nitpick on how things were handled, the fact that you checked if anyone was affected and fixed it promptly is a good thing.
It is not really nitpicking, given the severity.
Being prompt on a vulnerability of this magnitude should be considered "meeting the standard" at best.
The CTO and co-founder didn't check in on any of the concerns, completely disappeared after leaving a heartfelt comment. This comes off as incredibly disingenuous.
I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually know about (I don't use firebase, I have tried it out in the past though). This isn't some edge case or hard to solve thing in firebase, this is the easy stuff.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).
As someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
Security rules are meant to be taken seriously, and it's your only line of defense.
> bold warning text in the Firebase docs.
Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists.
Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever.
How many tutorials, community answers, and gists do you think conveyed that warning?
Reading/watching random tutorials and asking basic questions on SO __instead of reading the official docs__ is a trend I've observed for the last 10 years. Even for stuff pretty well documented like Python, Postgres, React, etc.
Most official documentation is awful, and just an API reference. It's (almost) like asking someone to learn english and then pointing them to a dictionary.
And that's because a lot of devs think it's perfectly dandy to just put perfunctory docstrings in their methods, point it at whatever "doc generation" tool, wire it up to a github.io domain and call it a day.
There is a reason people crave, want and seek things like SO and blog-posts. They're packed full of insight, working examples and just plain old "how TF do you use this thing". Oh and of course, the "this problem A didn't work when using setup B and C, and that's because of reasons X,Y,Z. Here, try H,I & K and it'll work.
> Most official documentation is awful
This goes doubly so for google cloud documentation. Firebase docs are decent, but if you're a developer who's gotten used to google's documentation style I could see skipping right over it.
For many years entire sections across multiple pages of firebase's documentation were missing after the site contents had been migrated from one system to another.
Multiple years of sample code and examples just cut out from the middle of pages.
When I was building on firebase it took me a long time to reconstruct exactly how certain aspects of the system were supposed to work just because of those missing docs.
That's true but people still do it for well documented stuff like Vue, Svelte and the R that shall not be named. Two wrongs that don't make a right
I remember writing a Twitter library when that was a thing, and being severely disappointed at the quality of the API documentation. There seemed to be little choice other than to experiment to see what responses you’d receive (and hope that it wouldn’t change underneath you). Same was often true with some of the GitHub APIs, although it’s been a few years since I’ve spent time with them.
I often wonder how much this can be attributed to the pretty awful SEO of most documentation. I write mostly Python at work and it's infuriating how often GeeksForGeeks, W3Schools, Programiz, or RealPython pop up when I'm just trying to reference like, the arg order of a builtin, or the particular behavior. Django is worse, I often feel like I can't even find the doc when I know it's there and read it before.
Documentation is largely static content. It isn't their job to play SEO games to convince search engines to surface it in the query results. Documentation is not a revenue generator for Google so it gets buried below the sites with Doubleclick ads.
For native documentation, why not just search the official docs at https://docs.python.org/ ?
I find it to be very discoverable if you are looking for docs about a specific function or module.
This is why I switched to Kagi.com it gives me results that are much more sane for things I'm looking for when it comes to a programming stance
Attempting to find the relevant docs page via search engines is generally not a good way to go, you should go to the documentation and search from there. Bookmark the landing page of the documentation.
People have already given many ideas, but if you use DuckDuckGo they have bangs for searching various python docs. Here's a page that lets you search which ones are available: https://duckduckgo.com/bangs
Also, many pieces of software whose "documentation" is just some examples of its use.
Yeah, the official docs for python rarely if ever show up on the first two pages of search unless I do `from: python.org`.
Google is really good at surfacing random blogs and SO questions instead of the official docs.
"don't trust the client / validate inputs" is software security 101
It points to a deeper issue in the Browser Company imo. Clearly, an inexperienced dev wrote that api, a senior approved the PR and no one in the wider team picked it up. And that's a team building the fundamental unit of your digital experience. If they failed at something this basic, I would be terrified to know what else they are missing in terms of security
For sure, I think the issue is – at what point in an engineer's development is that fact hammered home? For me it was hanging out with friends and learning fundamentals together, and then even more reinforced in the security course I took in college. For others, they might skip that elective in school (or their bootcamp will gloss over it), and they learn it the hard way later on the job?
That said, ideally code review/peer review/design review would catch things like this. If this was a feature implemented by an engineer that wouldn't know any better, they should have at least some help from others around them.
The issue is not about supporting engineers, this isn’t a pile-on to some poor engineer. It’s about choosing secure software, and avoiding software (particularly critical and vulnerable software like a web browser) from orgs that have built severe vulnerabilities into their software by incorrectly implementing something foundational to computer security.
There are many smart engineers who I would not trust to build my web browser because they lack the domain knowledge to do so. That’s not a slight on them. But if a company hired those people to make a web browser, I wouldn’t trust that org’s software.
This wasn't really a problem that required domain-specific knowledge to get right. Whoever designed an API that allows the client to bypass auth like that can't be trusted to design software that takes user input. At least not without some additional training that was missed along the way.
This may or may not be fair, but in my view, the type of person that would opt for a firebase solution is probably the type of person most vulnerable to foot guns.
Sadly true, but Firestore has a security rules emulator and encourages you to write unit tests for it! There's just so many levels of "ignored all reasonable practices" here. Where's the code review? Where's the security/privacy audit?
I am glad to put engineers in quotes because many people here and elsewhere will use that word with a straight face while also believing that you can call yourself that while learning your job from watching youtube vids and pasting code you don't understand. We need to stop using the word "engineer" for "software developer".
I shall watch the downvotes come from these so called "engineers".
Nah, just ask ChatGPT.
ChatGPT would have probably parrotted the bold text. It is always super concerned about risks.
I think a system that makes it this easy to shoot yourself in the foot is probably not a great system. Documentation is important, and I'm glad it's clear and obvious, but humans make mistakes. You'd hope that the mistakes have less dire consequences.
> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access.
What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
Also how does this work legally with regards to data sovereignty? Is it just a case of hoping nobody notices/complains?
Nobody reads docs dude. They copy and paste stack overflow answers, and now, copilot answers, which is going to be based on stack overflow ultimately anyway.
Just with less context and review.
Maybe docs should try to be consistently more accurate, up to date, and legible than (even) stack overflow answers ¯ \ _ ( ツ ) _ / ¯
I have heard this said by many people: “I don’t look at documentation because it usually is inaccurate/out of date”
There’s plenty of people sharing anecdata about bad docs, and I’ve dealt with my fair share. But my anecdata is that engineers who habitually go to the docs directly and read them gain a better understanding and write better software than those who do not. I believe that most software for engineers has documentation that is more informative than stack overflow and blog posts.
I support reading docs first for questions, but man some truly are terrible.
Like cmake. This just vomits a dissertation at you for each function without really ever saying what it does or how to use it. That’s why there’s so many different sites and GitHub repos with samples. 95% of which are completely out of date (which is a problem cause people looking for these samples probably aren’t on the ups with being able to tell if they’re out of date)
None of that matters if it doesn't show up first or second in Google results.
It's interesting to see software engineers going from rolling their own auth, to not rolling their own auth, to not even noticing this quite blatant security problem.
It doesn't matter if you roll your own auth or not, you need to understand a very basic fundamental of it all: never trust the client.
At the end of the day this is an amateur mistake
God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.
I guess we're not always professionals at all the work that we do, if that makes sense
Are you defining amateurs as people who are not your coworkers? It can still be an amateur mistake.
Coworker implies paid work, and therefore they are not amateurs. They very well may make the same mistakes, but those mistakes would be professional mistakes.
Why this level of pedantry when the meaning is absolutely clear? A professional can make an amateur mistake. This makes perfect sense. That isn't implying the professional is actually an amateur, but that he made a mistake that an amateur would make.
For some added pedantry: aren't all the mistakes that a professional might make, also ones an amateur would make?
In fact, it seems like an amateur is likely to run into all mistakes more often, thereby making all mistakes amateur mistakes; unless there some class of mistake that amateurs are better at avoiding?
There are probably mistakes an amateur cannot make because they can't penetrate the problems where the mistakes would be made.
That is some next-level bad faith. Impressive.
If it's internal, did they really need to have auth?
YES!!! You need auth to prevent employees from looking up sensitive user data without a good reason, or it'll be a stalker's haven. And to prevent possible intruders from gaining more data/access. Defense in depth. And for preventing an experiment from wiping use data. And for so many other reasons!
The term of art is "Friendly fraud".
A significant amount of product stolen from retail stores actually goes out the back door.
> If it's internal, did they really need to have auth?
Nothing on a network is truly internal. The moment you break the physical link between metal and man you're in an unintuitive, and thus insecure, state.
A security plan which depends on any person never making an amateur mistake, is an amateur mistake.
Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101:
```
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
```
Didn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?
Unclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point.
Which then leads me to the next question, what is the practical way to write rules against that operation?
Is there no Allow-read? Edit: Yes,
This is what happens when you hire solely based on leetcode skill. A shit-tier engineer can master leetcode within months, but a good engineer will probably struggle at Find Nth Smallest Sum problem because he spends more time reading and thinking about code.
Leetcode is a fucking joke to the industry, gone are the days when you actually had good code with devs who spent time thinking about information architecture. In my experience boomer devs are actually the only ones who write idiomatic code. Millennial and Gen-z devs are the worst, they have no understanding beyond basic function calling.
the whole idea of firebase is flawed as logic that belongs to a server is now on the client side. I don't know much about security but that sounds like making any centralized rule (eg security) hard to implement. It also tends to expose more internal logic than the client needs to know, which is bad in both software design and security.
I just wanted to say, I enjoyed the little pixel art cat that runs towards wherever you click immensely. It’s one of those fun, whimsical little touches that I don’t see all that often. A reminder that the internet can be a fun, whimsical place if we want it to be :)
As I didn’t get that, it seems like the dev honors prefers-reduced-motion, and doesn’t display it in that case. Excellent of them, give joy to those who want it, prevent annoyances for those who hate them.
It does: https://github.com/adryd325/oneko.js/blob/main/oneko.js
Simple but effective. More websites should include this check. Well done, adryd325!Same for me, on FF you can override it with:
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...It's doing great for being a 35-year-old cat!
https://en.wikipedia.org/wiki/Neko_(software)
On Debian, you can install and run the cat with
Makes a great gift for colleagues who leave their computer unattended.Well that was a rabbit hole.
Current version is hard to even see with high-res screens. A few checks shows endless ports, code from the 90s and before, and all sorts of other fun.
Wonder if the author will reply.
You have sudo access to your colleagues computers?
I don't, but I run the same system configuration, so I can compile it on my computer, transfer it and run it.
Alternatively, if a compiler such as gcc is available, you could also run
so, to remind your coworkers that they should securely lock their computer, you download some software from http and run it on it?
Not the person you're responding to but my workplace has a special internal link precisely to "remind" coworkers to not leave unlocked laptops unattended.
Don't worry, it's https ;)
No. As mentioned before, I have a precompiled binary. But you are right about security, so here is how to verify the SHA-256 hash of this file:
It's cute but I just can't focus on the article knowing the cat is gonna move every time I move my mouse or scroll. I popped open my console and deleted him. Sorry, kitty
And here I was wishing it would go away and trying to find a way to hide it because on my phone it was always covering text. Firefox reader mode worked.
I found it, like an actual cat, extremely distracting.
it sits when it's next to pointer. just don't move your mouse.
For the curious, that specific cat goes back to 1989:
https://en.wikipedia.org/wiki/Neko_(software)
On desktop it follows the mouse no need to click.
I did not. On the firefox mobile browser it was just using screen space.
It is distracting and annoyed me, I stopped reading because of it.
I thought it just ran around on the top line of the header, and was quite taken with it. I then scrolled and it followed me right into the middle of a paragraph. Less taken, but cat's gonna cat.
I guess it's removed? I don't see it. On Windows Chrome.
According to this article, Arc requires an account and sends Google's Firebase the hostname of every page you visit along with your user ID. Does this make Arc the least private web browser currently being used?
I trashed Arc immediately after install when I found out having an account was mandatory. That seemed so silly, like toothbrushes-requiring-wifi absurd. How much moreso now.
Truly. I was looking for a privacy respecting Chromium-based browser to use for Web MiniDisc (https://web.minidisc.wiki/) and came across some enthusiastic praise for Arc. I downloaded it and it immediately wanted me to create an account to even use it. How can that possibly respect my privacy? It went right in the trash.
What is also strange that I only found out about account after download. Like it was standard thing for the browser. (Sure there are optional accounts in others but login-walled browser?)
Another strange thing about the account... They have a little section under "Security" FAQ (lol) that says:
>"Why does Arc require an account to use?"
The answer is:
>"Here's a link to our forum that explains the rationale behind requiring an account to use Arc: Why do I need an account?"
That link goes to here: https://resources.arc.net/hc/en-us/articles/19401542261911-B...
Which... Doesn't explain why you need an account!
They want an easy path to onboard you into paying for stuff.
Windows is practically login-walled[0] at this point so I imagine people are slowly getting to expect it.
[0] witness the magic incantations needed https://www.tomshardware.com/how-to/install-windows-11-witho...
Hilariously (in the absurd way), this affects my girlfriend, who prefers and uses the Microsoft account feature AND onedrive exactly how Microsoft would hope she would, and STILL gets fucked by their stupidity.
Her laptop has a mediatek wifi card that doesn't have built in Windows drivers. Re-installing Windows requires you play the above game, so you can get into Windows, install the driver, and then immediately log into Microsoft.com.
This is so super annoying for shared lab computers
A while back they required login before download. That's when I noped out.
I had the same response when I downloaded Dart and discovered that a programming language thought it was acceptable to send telemetry.
In 2024 it is considered normal for an _operating_system_ to require an account, an information that is potentially passed around to any app running on it.
I had doubts already when submissions promoting the browser were added on hn while there was no way to see how it looks like or even test it out - for quite some time there was nothing but mail singup on their page.
https://news.ycombinator.com/item?id=35801529
I did the same. Requiring an account for a browser is immediately disqualifying. I don't care how many features it has.
Even Chrome wouldn't dare
When I downloaded it a few months ago and it required an account to even use it, my gut feeling was that I should just stick with Firefox.
I think OperaGX wins that award
I'm also left wondering: How broken would Arc be, if Firebase was to go down?
I guess it's relatively easy to test, add the Firebase domain to your host file and point it to 127.0.0.1 and try to use the browser.
Sometimes things like this handle connection failures better than "never-ending connection attempts", so you might want to try to add a throttle or something too for the traffic between the domain and the browser, might also trip it up.
They don't encrypt the data they send via Firebase?
I mean, even Google suggests doing this with sensitive data.
"Arc is the Chrome replacement I’ve been waiting for." [1]
> https://arc.net/
I guess now we know why they frame it that way.
Chrome does not require an account to use. And Chrome by default doesn't send sites you visit to Google, unless you turn on the "make searches and browsing better" feature or the "enhanced safe browsing" feature.
So the OP is right. Arc's privacy is worse than Chrome.
This is such a fantastic bug. Firebase security rules (like with other BaaS systems like Firebase) have this weird default that is hard to describe. Basically, if I write my own API, I will set the userId of the record (a 'boost' in this case) to the userId from the session, rather than passing it in the request payload. It would never even occur to a developer writing their own API past a certain level of experience to let the client pass (what is supposed to be) their own userId to a protected API route.
On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.
> On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.
Tbh you're doing it wrong if you go that way.
Default deny, and then you only have to imagine the legitimate uses.
Fair enough, but my point is more conceptual, in that you still have to write `boost.userId == auth.userId` as an allowed pattern rather than making that pattern the only technically possible result, which is the convention in a traditional API.
The failure modes are much clearer: when you write the API in a default-deny context & forget to add that allowed pattern, it never works, so you notice & figure out the bug.
The same story with default-allow means the system looks like it works fine, and you end up with no security at all.
And then when you imagine the legitimate uses you have to imagine how allowing those legitimate uses could be misused. You always need to think red and blue.
For inserts yes, but for updates I've frequently seen cases where people just stuff the whole request into their ORM or document store. It is pretty easy to think "the owner can update the document" without realizing that there are some fields (that the official client doesn't set) that shouldn't be updated (like the owner or created timestamp).
The correct solution is likely default-deny auth for every single field. Then you at least have to explicitly make the owner field writable, and hopefully consider the impact of transfering this object to another user.
I'm amazed by how profoundly stupid this vulnerability is. To get arbitrary code execution, you literally just send somebody else's user ID, which is fairly trivial to obtain.
I don't work at FAANG. I just work at some company that makes crap products you don't actually need, and even I would never build this kind of bug.
But these people want to build a web browser, with all the security expertise and moral duty that implies?! Wow.
Can you explain how you could get someone else's user id? I get that this is still a big vulnerability but am trying to understand how that would happen.
It says in the article. If you share one of your snippets, or make/accept a friend request, that all uses the same id
Can we have Arc added to the title of the post to better alert people who use or know people who use the browser?
Huge agree. I didn’t realize this applied to me the first time I saw this story yesterday. It was the rename that got me to click.
Honestly I strongly feel the title should be “fundamental bug in Arc browser (CVE 123-4567)” or similar.
There are a lot of major security vulnerabilities in the world that were made understandably, and can be forgiven if they're handled responsibly and fixed.
This is not one of them. In my opinion, this shows a kind of reputation-ruining incompetency that would convince me to never use Arc ever again.
On the other hand, this is pretty impressive:
Four hours from out-of-the-blue initial contact until a fix pushed is pretty good, even given how simple this fix probably was.EDIT: Oh, the date changed; so it was 28 hours until fix. Still decent; and half an hour from initial contact to "Join our slack channel" is incredibly fast response time.
Reacting fast is the least the vendor could do. Bare minimum. This should not be applauded. It should be treated as "well, at least they reacted at a reasonable speed so the root cause was probably not malice".
In other words, a quick turnaround with a fix does not lessen the impact of being negligent about security when designing the product.
> Reacting fast is the least the vendor could do.
It's certainly the least a vendor should do, but it's absolutely not the least a vendor could do, as we see the vast majority of vendors do far, far less. It's worth holding people up and saying, "This is how you should be doing it."
You’re technically correct, given a literal reading of the post you quoted, but the use of “could” there was idiomatic - let me explain:
There’s a (fairly dated) idiom, “it’s the least I can do”, used when you are offering to do something to make up for a mistake or offense, but the person you hurt says your offer of compensation is unnecessary. For example:
Situation: Person A bumps into Person B in the cafe, causing B to drop their coffee cup.
A: I’m so sorry! Let me buy you another coffee.
B: That’s not necessary - it was an accident, and I had almost finished my drink anyway.
A: It’s the least I can do!
B: Oh, thank you so much!
Buying B a new coffee is not _literally_ the least A could have done - the least A could have done is nothing - but that’s the English idiom. “Can” is acting more like “should” here. You could read it as “It’s the least I can do (if I’m a good person, which I am)”.
Thank you for the explanation -- when I'm speaking foreign languages I appreciate this sort of explanation. But in this case, as a native English speaker, I was well aware of the idiom, and was trying to subvert it. :-)
The original idiom is said in the first person, and as you say means essentially, "Justice and equity compel me to do this; I don't find myself able to do less".
GGP was actually using a derivative of the idiom in the second person. What the derivative literally says is, "Justice and equity compel them to do this; they don't find themselves able to do less". But idiomatically, what it actually means is, "Justice and equity ought to compel them to do this; they ought not to find themselves able to do any less".
Which is true; but it's still the case that the vast majority of companies find themselves very much able to do far less. Justice and equity should compel companies to do this bare minimum, but in the vast majority of cases it doesn't. And so we should still commend those who do find themselves so compelled, and hold them up as an example.
[some edits]
Agreed!
> Reacting fast is the least the vendor could do.
And yet, so few do. Let's remind ourselves the bar sank into the floor a long time ago.
[dead]
"They put the bandaid over the wound caused by a flagrant disregard for the users privacy, security, and safety."
Phew, glad that's over and will never happen again.
28 hours (note the date), but still
28 hours for a 1 line fix is impressive?
The mandatory account just to try Arc was always a massive red flag to me - and led to me never trying it. Now I’m glad I didn’t!
You could have just borrowed someone else’s, it appears.
Ironically, that would help the privacy concerns since it would intermingle all traffic in their analytics system. Win-win!
No Linux version prevented me from trying it, didn't even get to the account wall, who knows if there's a pay wall. Perhaps the "moat" concept was misunderstood.
Same
Honestly I’ve always considered Arc to be a wolf in sheep’s clothing, especially when it comes to privacy.
50-60mm cash at 500mm (!) valuation and no business model is a big red flag when it comes to something as important, as personal as a browser. This is not a charity. Someone, somehow will have to pay for that.
Yeah I’m so torn. It’s honestly the best browser UX I’ve seen, the right combination of vertical tabs, auto archiving, spaces/collections, sync, etc. I don’t care for Easels, but the core is good.
Except… the growth hacks have started to creep in. They overlay an advert for their own AI services on top of regular Google search results pages in their mobile app. Not even a browser chrome UI element, it’s literally over the page content. That feels like a huge violation of what it means to be a browser.
I don’t want their AI features. I don’t want growth hacks. I don’t want to sign in except for sync. I’d happily pay $40 a year for Arc as a product-focused-product, but as a VC-focused-product it’s heading downhill.
It does get a lot right and feels smooth in ways that Chrome, the various Chrome-clones, and Firefox just don't. It's also ironically the only browser even trying to feel native on Windows, using WinUI/WinAppSDK for its UI there, despite originally being Mac only.
It's unfortunate that other cross platform browsers have such a strong tendency to phone in these little things, because they really do add up to make for a nicer experience.
I'm torn for the same reason: The UX hits all the right notes for me and I've tried every MacOS browser under the sun. I'm an ADHD sufferer and there's something about their combination of features and UI that just lets me get stuff done. And I don't even touch their AI features.
This is all really sad news.
You might like Zen Browser https://zen-browser.app/
Thanks for the recommendation. I just had a quick try, it's nice, seems like a very polished Firefox. It seems to have a bunch of features I don't want in a browser so not sure if they'll get in the way.
Or Floorp: https://floorp.app
Have you tried Vivaldi? It's really customizable and has a lot of features.
Vivaldi feels like a cross platform port in all the ways I try to avoid. I understand the feature set is good, but it doesn't feel nice to use. Hard to state exactly why though.
You’d think that a company shipping a browser would pay a little more attention to security rules.
Also, shame on firebase for not making this a bit more idiot proof.
And really? $2500? That’s it? You could’ve owned literally every user of Arc… The NSA would’ve paid a couple more zeros on that.
> You could’ve owned literally every user of Arc… The NSA would’ve paid a couple more zeros on that.
only the 17 users they have.
Shouldn't a government sue you if you try to sell him out vuln unless you personally know people in charge?
Arc has a lot more than 17 users. It’s surprisingly popular.
I guess not since they used the services of a company that could exploit vulns in ios
Are there a lot of Arc users? It seems like a pretty niche browser even compared to other niches.
Lots of developers and power users make a good chunk of Arc's use base. If you're after some interesting credentials then "every Arc user" is a perfect group with little noise.
> power users
Not that many. Most power users don't like to be forced for logging in, before they are able to use the browser.
If I had to guess, the typical Arc user is a Mac user in tech. It doesn't run on Linux, most windows users wouldn't run it, and non-tech people haven't heard of it.
Then most engineering IC people will most likely run Firefox or Chrome, so you're probably looking at designers/founders/managers as your target.
Probably some interesting targets there, but not the type that the NSA cares about. Just pure conjecture on my part of course ;).
The only person I ever saw using Arc was a designer at a tech startup, so this checks out.
I've seen quite a few. In one of my clients's Slack there are at least a couple people advocating for it all the time. They're mostly DLs or in similar roles. I also know at least one developer who uses it.
I used it for a while for a very limited use case. Some interesting concepts. Mostly I found it annoying though. I also didn't like the sign-in thing but still wanted to experiment. I have dropped it altogether and kept Firefox as main browser (as it's been for many years) and Safari as a secondary. Both work much better overall for my needs.
confirmed
i don't even like logging in WHILE using the browser and have never heard of arc
I've only heard of ARC the obsolete archive format ...
Having arbitrary browser access would be pretty valuable, even for just a small number of users.
> As of July 2023, The Browser Company has 100,000+ users
https://www.boringbusinessnerd.com/startups/the-browser-comp...
That's a year ago. Looking at how upvoted this bug has been, they do have many users
my brother uses arc browser , he is a developer . I think he saw it from somebody using it (maybe theo t3 or some other creator he watches) , and he found it cool (plus there were lot of videos flooded with saying arc is really great IDK)
If someone finds something cool on the internet. They are going to try it , given that they are capable to do so.
He had a mac so he was able to do so , Even I tried to run arc on windows once when it was really beta and only available to mac (I think now it supports windows not sure)
I just kindly want to state that if the nsa could've bought this exploit , they could've simply waited and maybe even promote arc themselves (seems unlikely)
Maybe they could've tried to promote the numbers of arc users by trying to force google and microsoft search engine through some secret shady company advertising / writing blog posts for arc / giving arch funding or like how we know that there are secret courts in america
( and since these search engines basically constitutes for a high percentage of discovery of stuff by search engine by users)
People could've credited the success to arc in that case for getting more users but the real winner would've been NSA.
> He had a mac so he was able to do so
How? I have mac as well but when I've download it some time ago it required login. Has that changed?
no I meant that though you need to login , i think arc isn't available on linux , only mac (or maybe windows though not sure , I see some issues + the security issue)
Ye it required login and my brother logged in (just see ! , the amount of friction to login etc. yet my brother , whom I would consider to be a little conscious of security still gave to try it in the first place)
sry if I didn't respond correctly
No. You still need to create a login.
Everyone else at work likes it, so I signed up with my work e-mail address and use it for work. All of my complicated browsing needs are done for work, so there's a good fit there.
Firestore rules are in "lock mode" (no read or write allowed) by default since a long time. Then, everything is ultra well explained in the docs.
I was already aware of it when being a noob dev 10 years ago, and could easily write a rule to enforce auth + ownership in the rules. No way, seasoned devs can miss that.
The page says $2,000.
A couple? A vuln like this is worth >$1M very easily on the market.
yes. I feel sad that now we have created an incentive where selling to the govt.'s is often much lucrative than telling to the vulnerable party (arc in this case)
(just imagine , this author was great for telling the company , this is also a cross platform exploit with very serious issues (I think arc is available on ios as well))
how many of such huge vulnerabilities exist but we just don't know about it , because the author hasn't disclosed it to the public or vulnerable party but rather nsa or some govt. agency
Also, firebase? seriously? this is a company with like, low level software engineers on payroll, and they are using a CRUD backend in a box. cost effective I guess? I wouldn't even have firebase on the long list for a backend if I were architecting something like this. Especially when feature-parity competitors like Supabase just wrap a normal DBMS and auth model.
> low level software engineers on payroll
How does The Browser Company make money? They're giving their product away for free.
Browsers are complicated. It doesn't inspire confidence that the folks in charge of that complexity can't get their heads around a business model.
(Aside: none of their stated company values have anything to do with the product or engineering [1]. They're all about how people feel.)
[1] https://thebrowser.company/values/
They don't have a business model yet, is the thing.
Well, it's an app that users access all their online info through - bank, email, search, work, social - everything. Even an open-source, decentralized, blockchain, grass-fed, organic, extra virgin, written in nothing but HTML, released by W3C itself browser could monetize just ~5% of market share if users are downloading their build (or if its baked into the source), considering how much a browser reveals about its user and to the extent the user can be retargeted for: Ads, marketing, surveillance, analytics.
The biggest opportunity has to be driving search traffic to the major search providers all these browsers partner with.
Could also get acquired by a major browser vendor if you have a better product and people are downloading it more than the major ones, especially if both are based on the same underlying engine. Even Firefox still sucks to this day. I'm using it right now (Waterfox) the product still sucks! I know of some browser vendors acquiring others, especially as mobile took off and it was hard to get it right.
Seems like the opportunity is similar to that of social media but slightly more modern because nobody uses new social media anymore but people are trying out new browsers (and you get richer user/usage data).
> Browsers are complicated. It doesn't inspire confidence that the folks in charge of that complexity can't get their heads around a business model.
Unfortunately you are also describing Mozilla here.
I don't see an issue, using something like Firebase is what a smart engineer would do. Just this one piece of logic is a problem.
I tend to agree with this. Why re-invent the wheel by spending engineering effort building a CRUD backend?
If you're trying to bring value to market, focus on your core differentiator and use existing tooling for your boilerplate stuff.
It’s the “chrome replacement we have been waiting for”, but (if I read this right), my data is still sent to Firebase? Also it’s a browser, not a “tinder but for cats” startup idea I’m writing for my cousin for a beer.
It’s not only not a smart engineering decision, it’s also a terrible product, reputation and marketing decision.
I'm not disagreeing about the severity of the security vulnerability that has been uncovered – to be clear, it's an absolute shocker of a bug. It's really disappointing to see.
But I still disagree that the use of Firebase, in and of itself, is a bad engineering decision. It's just a tool, and it's up to you how you use it.
Firebase gives you all features needed to secure your backend. But if you configure it incorrectly, then _that's_ where the poor engineering comes into play. It should have been tested more comprehensively.
Sure. You could build your own backend rather than using a Backend-as-a-Service platform. But for what gain? If you don't test it properly, you'll still be at risk of security holes.
> a “tinder but for cats” startup idea
Needs a name. Meowr? Hissr?
Yowlr. (Which is apparently a dubstep musician.)
(Dubstep isn't music.)
My cats would use Yowlr.
This convinced me to never use Arc again. I created a small guide to migrate from it to an open-source alternative: https://gist.github.com/clouedoc/4acc8355782f394152d8ce19cea...
TL;DR: it's not possible to export data from Arc, but it's possible to copy-paste the folder to a Chrome profile, and Firefox and other browsers will detect&import it.
Unfortunately, Zen Browser simply isn't an alternative. If you like Arc, then Zen's UI for tabs and splitting views isn't really anywhere close to satisfying the same needs.
At least Firefox seems to be borrowing some of the UI features slowly. At least the Mozilla Foundation is very public with their wants and goals.
Firefox seems to be borrowing some of the UI features slowly (at least the vertical tabs). And at least the Mozilla Foundation is very public with their wants and goals.
I also wrote a guide on ARC features that work better on Firefox: https://thannymack.com/#Arc%20features%20that%20work%20bette...
What is Arc?
https://news.ycombinator.com/item?id=36862546
I agree & disagree.
Browsers are very important part of our life. If someone compromises our browsers , they basically compromise every single aspect of privacy and can lead to insane scams.
And because arc browser is new , they wanted to build fast and so they used tools like firebase / firestore to be capable of moving faster (they are a startup)
Now I have read the article but I am still not sure how much of this can be contributed to firebase or arc
On the following page from same author (I think) https://env.fail/posts/firewreck-1 , tldr states
- Firebase allows for easy misconfiguration of security rules with zero warnings
- This has resulted in hundreds of sites exposing a total of ~125 Million user records, including plaintext passwords & sensitive billing information
So because firebase advocates itself to the developers as being safe yet not being safe , I think arc succumbed to it.
firestore has a tendency to not abide by the system proxy settings in the Swift SDK for firebase, so going off my hunch,
Also , you say that you have been convinced to never use arc again.
Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
this is just recently discovered , just imagine if something more serious is also just waiting in the shadows Couldn't this also be considered a major security vulnerability just waiting to be happen if some other exploit like this can be discovered / google.com is leaked and now your cpu information and way more other stuff which browsers shouldn't know is with a malicious threat actor ?
I very much agree with the idea that browsers are security-sensitive software, unlike, say, a picture editor, and more like an ssh server. It should be assumed to be constantly under attack.
And browser development is exactly not the area where I would like to see the "move fast, break things" attitude. While firebase may be sloppy with security and thus unfit for certain purposes, I would expect competent developers of a browser to do due diligence before considering to use it, or whatever else, for anything even remotely related to security. Or, if they want to experiment, I'd rather that be opt-in, and come with a big banner: "This is experimental software. DO NOT attempt to access your bank account, or your real email account, or your social media accounts".
With that, I don't see much exploit potential in learning stats like the number of cores on your machine. Maybe slightly more chances of fingerprinting, but nothing comparable to the leak through improper usage of firebase.
hmm interesting. Other thing to add is if we treat it as a ssh server , we actually won't try to go out and break things.
But I think that was the whole point of arc , to break the convention and be something completely new
and I have a reason why
They were competing with the giants called google , safari , firefox which have insanely large funding and their whole point was trying to sell something later built on this arc browser.
and since chrome , firefox etc. don't try to come up with these ideas because well security reasons (which I agree to / as seen in the post)
I think arc wanted to seperate itself from chrome / firefox and that's why they became a bit reckless you could say since this exploit was available.
Also the other thing I want to convey , is that "With that, I don't see much exploit potential in learning stats like the number of cores on your machine"
this was only recently discovered. Just imagine the true amount of exploits in these proprietory solutions which we don't know about.
Yeh. Just like a ssh server , I would personally like the source code to be available but developing browsers is time consuming and money intensive for developers but ladybird exists , but its in beta.
that being said , not open source is also that private , (xz) , but atleast it got discovered way quickly and was able to mitigate it quickly
You do know that there are more than chrome and arc right?
I understand. I use firefox / earlier used librewolf
But a lot of people use chrome so I wanted to atleast try to give justification on why / how arc messed up so hard.
> Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
That's pretty interesting. Where can I learn more about this?
I recall there being a thread with way more discussion at the time, but I can't put my finger on that thread right now. This post has some information:
https://news.ycombinator.com/item?id=35152419
>>Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
Yeah so using chrome based browsers like Arc is giving more power to Google to do shady stuff while also being a victim of the third party unsafe code.
Thank you for sharing this. I have been using Arc since the first week of beta.
The fact that they don't even mentioned this bug/fix on any of their social media is quite alarming.
I enjoyed my time with Arc, but I can't possibly see myself continuing to use it after the way they handled this.
Them acknowledging the issue, then fixing it within 28 hours isn't good enough for you? That kind of response makes me happy to continue using Arc.
I'm in the same boat as GP. Was invited early, loved the Arc UX far more than any other browser. I've recommended it to many people.
As many other comments have pointed out, this vulnerability is such a rookie mistake that I don't think I can trust them again after this without understanding what factors in their security/engineering culture led to it. Patching this one issue isn't enough.
>Them acknowledging the issue, then fixing it within 28 hours isn't good enough for you?
Are you not concerned with the yet to be discovered vulnerabilities?
What is concerning is the nature of the vulnerability and how it speaks to their security culture (which is obviously non-existent). This also revealed that their privacy policy is pure marketing fluff, completely disconnected from (and, in fact, counter to) their actions.
If you are comfortable using a browser (probably the software with the largest risk and attack surface on your device) that had an embarrassingly rudimentary vulnerability, made by a company who lie about the most important promise of their privacy policy, then I've got a calculator app for you.
They afaik never said that they ‘fixed’ the issue where they’re sending Google your every visited url.
Where did they acknowledge the issue? There’s nothing about this issue on their website or their Twitter feed.
They only acknowledged the issue after the write up from the researcher and claimed they thought they didn't need to include it in the release notes because it was a "backend fix".
[flagged]
1) What's with the hostility?
2) What exactly do I deserve?
A pleasant user experience?
That's how you ruin a company reputation. Not saying it is or not deserved, but how could anyone trust a browser that had such a big security fail.
And what about all the other that have not been reported or may be exploited ?
From now on, every time someone is going to suggest arc browser, there will be another one to remind everyone of that. That's going to be very difficult to overcome when your software already doesn't have that big of a market share.
It's a little worse than that. From now on, blackhats will have a favorite #1 browser to pentest, at least for the next few weeks.
And who's going to take the bet that they'll find nothing? Not me.
$2000 is an insulting amount for such a huge vuln
Judging by blog posts on HN, I got the impression that these vulnerabilities are often not rewarded at all, or rewarded by a minuscule amount. It almost seems like companies are begging hackers to sell these exploits. Perhaps because they aren't penalized by the regulator for breaches?
They offer a low price because the risk of tanking your career, landing yourself in jail, and the fact that the researcher probably doesn't know how to line up a sale means the company is the only buyer.
I would go the other way, companies offer low bug bounties because they don't want researchers to discover them in the first place. This looks terrible for Arc despite the fact if left undisclosed it probably would have continued to be unexploited for years to come.
Yeah, that was my first reaction. I'm really surprised they were cheap on this
Yeah, you have to have some solid backbone not to sell this off to some malicious party for 20-50x that amount...
Am I too optimistic? I feel like most regular people I know wouldn’t sell this off. Most people are not antisocial criminals by nature, and also wouldn’t know how to contact a “state actor” even if they wanted to.
> Am I too optimistic? I feel like most regular people I know wouldn’t sell this off.
Probably you're just used to a relatively good life, not a bad thing :)
Image being able to sell this off for $20,000 (although I think you could ask for more, seems to be a really bad vulnerability) in a marketplace, for >90% of the world that's a pretty good amount of money that you could survive a long time on or add a lot of additional quality to your life.
> also wouldn’t know how to contact a “state actor” even if they wanted to.
That's why brokerages like Zerodium exist - you can sell it to them, and they'll sell it onto state actors.
How does this work in practice? What systems are in place to prevent someone selling an exploit and then turning around and disclosing it properly as soon as they have the money, potentially getting even more money through legal channels? Is there some sort of escrow?
Opportunity makes a thief. Most people does not have the opportunity even if they have skill.
A malicious party who wants a vulnerability in a browser effectively nobody uses?
Arc is used disproportionately by users who work in tech which tend to be paid quite well.
Am I wrong in thinking that with this vuln you could drain any financial accounts that they log into Arc with? Or, if they use Arc at work, that you now have a way to exfiltrate whatever data you want?
A browser vuln is about as bad as an OS vuln considering how much we use browsers for.
Nice article, but this is hard to read without proper capitalization. My brain uses capitals to scan beginning and ending of text.
Young people (like me) use lowercaps like that all the time. Around 50% of the young people I know purposefully turn off auto-caps on their phone.
Why? I really couldn't say. I think we just like the feel of it. The only reason I type with proper capitalization on HN and my blog is because I know older people read it.
Using uppercase is for writing (more formal).
using lowercase is for chat (less formal)
I’m middle-aged. I’ve noticed in the last few months more and more articles with this style. Something I’ve never seen before in blogging or article writing.
I usually notice the style at some point but this time I had no idea until this other commenter pointed it out. I guess I am getting acclimatized.
I was similarly fascinated by the stylistic choices made here. No capitalisation of even any names, no hyphen in a compound adjective, but dots and commas and spaces are deemed necessary, also before "and" where the word clearly acts as separator already. If you look at the waveform of speech, we have no spaces between regular words so, if they want to eliminate unnecessary flourishes... though perhaps (since text largely lacks intonation markers) that makes it too unreadable compared to the other changes. All this is somehow at least as fascinating to me as the vulnerability being described!
It’s just another dumb social media trend, like tYpiNg LiKe tHiS. Hopefully it too will phase out. Search for “lowercase trend” and you’ll find reports of it going years back, there’s nothing worth being fascinated about.
It has seeped into HN as well. Look closely and you’ll notice several commenters type like that.
I use it to indicate tone. Proper capitalization and punctuation reads with a formal, cold tone.
lowercase without caps reads with a warmer, informal tone
there’s a Tom Scott Language Files video documenting it: https://www.youtube.com/watch?v=fS4X1JfX6_Q
It's extremely irritating, distracting, and breaks focus on the content instead of the annoying stylistic choice, just an fyi..but I imagine you probably like that this is true and purposely try to annoy the people that aren't in the little club. If not, then I suggest not doing it. The tone I perceive from it is "F**** the reader"
> ... you probably like that this is true and purposely try to annoy ...
I don't know if you meant to direct this at the person you're replying to but I'm convinced the overwhelming majority of people don't get out of bed in the morning with any of that in mind
It's comments like these that make me reconsider what hateful meanings others might read into my communications or mistakes
Yes I mean this to anyone repeatedly, consciously fighting natural convention and muscle memory to purposely type every letter in lowercase, knowing that this produces in the reader a slight dissonance and distraction constantly, and choosing to do this instead of using convention that everyone understands so that "syntax" does not become the focus and instead the content of the message does.
Otherwise they're "drawing attention" to the style and themselves for narcissistic reasons. I would simply assume they'd have to know the annoyance this brings to the reader, so I assume it's on purpose.
I would feel the same about someone writing code in a consistently purposeful unorthodox style and against convention in such an obvious and effortful way that no one is used to. Personally, and YMMV, I like to try to write in as clear a way as I can to get my point across as much as possible. Useless stylistic fluff in something that isn't poetry, seems counter to that purpose.
>mistakes
It's not a mistake though to ensure every letter one writes is not following convention and English syntax. Accidents and mistakes are a different thing.
That's really interesting, I personally don't read those tone differences based on the casing. Neither approach carries different warmth or formality to me at all.
I wonder if this is a regional or generational thing?
> I wonder if this is a regional or generational thing?
Generational is a good bet:
https://news.ycombinator.com/item?id=41537994
It's definitely primarily generational. In my experience, capitalization-as-tone is used by many Generation Z people. On the other hand, it is not widely used by older generations, or the younger Generation Alpha.
[flagged]
In my experience, that isn't the case. Among people who "have gotten used to" it, using capitalization to indicate the formality and/or tone of your message allows the reader to understand the writer's intention better. I have not observed any correlation between political leanings and this.
That seems dubious. Consider the "stylistic choices" of the former president in social media posts.
I'm not sure what you dispute or your point is here. If people slightly or strongly start aping Trump's writing style in various forms I'd say there's a good chance those people are right wing or simply "not the same people writing in all lowercase" you know?
You highlight stylistic choices. I'd say we can observe the differences in different styles and see how uses them. Is Trump writing in all lowercase? No. Is this poster writing like Trump? No. Do a lot of left-wing people use the all-lowercase style? I see it all the time, yes.
> lowercase without caps reads with a warmer, informal tone
Personally, and I’m certain I’m not alone on this, it reads as annoying. It’s harder to follow and looks as if the writer didn’t care to do the bare minimum to make the text accessible and clear to the reader.
> there’s a Tom Scott Language Files video documenting it
Per that video (thank you for sharing), capital letters “make a paragraph easier to read” and “context matters” and “the conventions change fairly quickly” and typing in all lowercase is “sometimes okay”.
This is a post documenting a serious browser vulnerability, shared to the wide internet, not an informal conversation between buddies. Clarity matters. I don’t fully buy the tone argument and find words and sentence structure are more important. Take the following two examples:
> Just heard about your promotion, you beautiful bastard! Let’s go get pissed to celebrate, on me!
And:
> good afternoon mrs bartlet. the limousine will be available in twenty minutes. i would also like to apologise for my behaviour yesterday when i inadvertently insulted your husband it was a faux pas i promise will not be repeated. my resignation will be on your desk by noon.
I get that language evolves. You do you. Personally I hope this trend subsides like so many others before it. Maybe you don’t like to read properly structured text and prefer all lowercase. My preference is the reverse. And that’s OK, we don’t all have to be the same. I merely wish that people who prefer a certain style understand not everyone will see it the same way they do (and I’m including myself).
That's true. I agree with you that anything less than a formal tone would be, and is, inappropriate for this context. I also respect that you prefer standard capitalization and punctuation at all times. Being aware of the audience is critical for any writer.
> lowercase without caps reads with a warmer, informal tone
No, it reads as "I'm uneducated and don't know how to write the English language properly". It's incredibly obnoxious for people to use as an affectation.
To me, proper capitalization is easier to parse - not massively so, but a little bit. So writing without caps is a bit of a jerk move. You're making it harder for me to read, either because you're lazy or because you want to affect a style. In either case it's a bit of a jerk move.
It's more of a jerk move when it's done on a discussion board, because what you write once is read multiple times. So the cost multiplies, but (if due to laziness) the benefit only occurs once.
Now, in something like texting, I understand, when you're trying to type on that teeny phone keyboard. It's harder to hit the shift key when you don't have a spare finger because you're only using one. But for something like here, take the time and the effort to make it better for your readers.
On a formal discussion board like this, I don't believe an informal tone is correct. To me, it doesn't make it harder to read, but it does come across as mildly disrespectful of the environment.
When texting on a phone, the default is to automatically capitalize. Using all-lowercase requires more work than doing nothing. It isn't lazy or even more efficient to go back and replace your "I"s with "i"s. With the right reader, it's done to give them a better idea of the tone you wish to deliver.
With that said, it requires a certain degree of audience awareness. Many people do not interpret lack of capitalization the same way I do, as evidenced by this thread. On my phone, I have auto-capitalization disabled. When texting someone for the first time, I tend to use proper capitalization, even if I want a casual tone. I just did a typing test with capitalization and punctuation and scored 55 wpm on my phone. It's a choice I make and it varies based on audience, and intended tone. Effort, on the other hand, is not a factor.
I use lowercase in most places precisely because it forces me to use shorter sentences and split text into paragraphs. The result is easier on the reader.
It's just a habit from chat rooms and instant messengers of the beginning of this century. Most of my mates who write like that are well over 30.
This whole subthread is one projection after another.
How does lower case force you to do that? It seems to me that it's completely orthogonal to sentence length and paragraph splitting. (But then, I use uppercase, so maybe I don't understand the dynamic.)
> Now, in something like texting, I understand, when you're trying to type on that teeny phone keyboard. It's harder to hit the shift key when you don't have a spare finger because you're only using one.
Mobile operating systems (or is it just iOS?) by default turn the shift on automatically when starting a new sentence and are pretty consistently fast and right. It’s more surprising to me when someone doesn’t use proper capitalisation from mobile.
Relax, buddy.
Strange to label a failure to capitalize words as a "dumb social media trend", as I'm sure people have been doing that for many years prior to social media.
And nobody tYpEs lIkE tHiS except when making a joke.
> Strange to label a failure to capitalize words
It’s not a failure, it’s a conscious choice.
> as I'm sure people have been doing that for many years prior to social media.
But now it’s happening more frequently. That’s what “trend” means. It doesn’t mean it never happened before.
> And nobody tYpEs lIkE tHiS except when making a joke.
Just because you don’t know people like that, does not mean they don’t exist. The world is bigger than one person’s knowledge. I personally knew several teenagers who did it for all their communication, before smartphones. The speed at which they were able to do it was astounding.
What do you mean by "before" social media here? Surely not handwritten or typewritered letters, I guess you mean like 2005-2010ish?
The term wasn't popular then but with reddit's and Facebook's infancies being twenty years ago, "social media" (which I understand to refer to platforms where you can talk to people and post things about different topics, so broader and more person-oriented than an SMF forum but narrower than the WWW) have been around for a while
The first time I saw lowercase writing like this was two years ago on the Discord guild/community of a game which got popular on tiktok. I don't know the average age but the (statistical) mode was probably in the range of 13–16
[flagged]
Good luck with that. I'm sure people will respond the way you want when you call them dumb.
[flagged]
If you can't understand someone's typing without capital 'i's, maybe they're not the dumb one?
[flagged]
Kids these days, no respect.
Social media? I remember people doing the lowercase thing back on IRC. It was an indicator of informality and "coolness".
If you were using Arc you could add a Boost for "Case: toggle between different capitalization settings - they will apply to all text on the webpage" [1]
/s
[1] https://resources.arc.net/hc/en-us/articles/19212718608151-B...
Depending on the version you are using, you might not even need to add it, someone else might just add it for you!
this made me laugh. 10/10
Instead of knee jerk firebase is bad, can we discuss how this could be abated properly with firebase rules for firestore?
Is this the rule that was missing for arcs boosts or whatever object?
```
```Arc was recommended to me by a friend. I deleted upon finding out I needed an account to use it. The excuse Arc gives is in case you want to sync. I'm capable of opting into that.
"in case" is good excuse if the account is optional. Which is not case here.
Great research. As I've said elsewhere, Firebase's authentication model is inherently broken and causes loads of issues, and people would be better off writing a small microservice or serverless function that fronts Firebase.
Also, for anyone trying to read the article, they should put `/oneko.js` in their adblocker.
> Also, for anyone trying to read the article, they should put `/oneko.js` in their adblocker.
Only if you hate cats, pixel art, or are easily distracted.
Im dyslexic and I tend to use the pointer to follow what I am reading to help me. The cat was annoying as hell. I just had to hide the element in the DOM before i could read more than a few lines. Infuriating design choice to make it follow the pointer.
Looks like someone already added it to uBlock Origin since I see no cat.
Or maybe the cat doesn't support Firefox...
Did you enable the ui.prefersReducedMotion setting? That hides the cat from what I can tell
Hmm not that I remember. But I have reduced motion enabled on my phone system wide and maybe that synced to my desktop on its own.
Which is scary come to think of it.
Too late to edit... i just got around to checking and I do have system wide reduced motion and reduced transparency on this laptop. I'm sure I didn't set it up on there, just on the phone.
I think Apple is starting to sync too much...
That seems like a perfectly reasonable thing to sync. Accessibility settings are exactly the type of thing you shouldn’t have to configure again and again on every device.
Either way, you can disable syncing of system settings.
> That seems like a perfectly reasonable thing to sync. Accessibility settings are exactly the type of thing you shouldn’t have to configure again and again on every device.
No, because I disabled motion on my phone because the wiggling of icons on the main screen annoyed me, not because I have motion sickness. Nothing wiggles on the desktop (yet). This option doesn't even belong in accessibility IMO, it should be a "stop annoying me" section.
> Either way, you can disable syncing of system settings.
Where? The same spot where I can disable syncing the clipboard? I.e. somewhere deep in an undocumented file?
Gotta be honest, the aggressive and unreasonable snark completely turns me off from helping you. It feels that regardless of the obviousness of the setting, you’ll find some nitpick to shout back at me about it. Since I don’t work for Apple or yourself, I don’t have to justify their choices or be the recipient of your unjustified and unprompted bad humour. I’m making a conscious choice to not soil my Friday on account of some internet rando. You’re on your own for this one.
I genuinely wish you a calm weekend and peaceful start of the week.
Thanks for the martyrdom but last time I checked clipboard syncing it was a package with everything that gets synced, including sms forwarding etc on Apple. If there is a way to disable syncing granularly it’s not documented anywhere.
Ah thanks, that explains why I don't see the cat everybody mentions
I use uBlock Origin and Firefox (on Mac) and see the cat.
I suspect it's that they hate are easily distracted (if "hate" falls outside of the series, such that it applies beyond just "cats")!
It's really not hard to build this safely in firebase, this could've been authored the same way in node too. I think whoever authored this either majorly cut corners or just isn't experienced enough to understand how to write authenticated controllers like this. This should scare people away from this browser, it's such a basic thing to mess up and it shouldn't have happened.
> Firebase's authentication model is inherently broken
I'm not very familiar with Firebase. In what way is it broken and what issues does it cause?
The fact that clients write directly into the database and that it's widely encouraged.
There are security rules in Firebase to prevent this, but bolt-on security models that the user has to explicitly enable haven't shown to work.
OP is talking about the Arc browser, not the Arc language, the Arc "Atomic React" project, or any of scores of other projects with that name.
https://arc.net/faq
I'm definitely not the target audience... Even after reading the faq I have no idea what it does
As a person that recently started using it: it has something like "tree style tabs", and sort of a hybrid merge of the concepts of tabs and bookmarks. In other words, the tabs work more like files on disk -- open/closed, sorted into folders. I'm probably not explaining it well either, but I encourage you to try it if you ever wanted to experiment with alternative tab management (tree style tab, tab groups etc). It's a concept that clicked for me quickly once I started using it, and now I'm angry since I want to use Firefox for philosophical reasons but don't want to go back to regular tabs.
Firefox has a heavily customizable tree style tab extension.
Yeah, I tried it, but it does a fundamentally different thing than Arc
The “what makes Arc different from other browsers” section is particularly funny.
> Arc is to your ex-browser what the iPhone was to cellphones. Or as one of our members said “like moving from a PC to a Mac.” It’s from the future — and just feels great.
It's a browser (chromium based) with a really nice UI that people love, I am intrigued but haven't used it because I find the requirement to create an account off-putting.
I don't understand what you do not get. In the link you sent they claim to be a privacy oriented web browser based on chromium
[dead]
I roasted them on HN when they announced their product: Browsing the interest should not require an account. Its an "HTML Client", absolutely absurd. Hopefully they sit down and reconsider their choices.
It is remarkable that Arc has taken billions of dollars in VC cash but makes these rookie mistakes in securing their own backend that all of their users are accessing. Where are those billions of dollars going? Is it all just in marketing?
You seem surprised. This is the MO of many tech companies.
Probably the line of thinking is that security can be a back burner issue until product market fit is achieved.
Doesn't matter if you build the most secure product if nobody is using it, right? Where that breaks down is that a browser MUST be relatively secure, otherwise you've given up the whole ballgame.
I really enjoy Arc's approach to the browser interface, but I am kind of shocked that it requires firebase at all. It touts privacy, but we have to log in, and our data is being stored in a BAAS owned by Google. It would have been SO much simpler to make it so that data is owned by the user and stored on disk. At MOST, maybe a paid syncing feature would require an external database. A takeover path like this is a big deal, but as the author pointed out, you stored URL browsing data for boosts. "Privacy first" browser's are marketing jargon today, and that sucks.
> "Privacy first" browser's are marketing jargon today
A glance at Arc's privacy policy makes it clear they aren't privacy anything [1]. (Contrast their device and product usage data sections with Kagi's [2].)
[1] https://arc.net/privacy#what-personal-data-do-we-collect-and...
[2] https://help.kagi.com/orion/privacy-and-security/respecting-...
That has been the reason I've never given Arc a shot. It's unacceptable.
It would be nice if I could download a version of the Arc browser with the cloud bits removed. I use it because of the UI/UX and pretty much ignore everything else. Really if there was a browser that let me keep organized spaces in a left panel plus create split screen views then it would immediately convince me to switch from Arc.
https://zen-browser.app/
I know about Zen and Floorp. For my day to day browsing Arc has:
# Split screen tabs
Zen and Floorp both have this but the UX for both is really clunky. Surely they'll improve but Arc felt like second nature.
# Little Arcs
As far as I know, neither Zen or Floorp have this feature and if they do then the UX is not as obvious as Arc. The UX around Little Arcs is almost perfect. If I click on a link, it opens as a modal that I can expand to its own tab if I need or dismiss by just clicking away. The same things happens in other apps so I don't lose context just because I wanted to look at a link quick. If I do want to bring that tab into a space then it's 1-2 clicks away. My only gripe with this is that the Little Arcs that are created from clicking links in other apps don't auto dismiss if you change focus but this might just be a setting I don't have configured.
# Inset meetings/videos
AFAIK neither has this feature either. Having videos that are playing just seamlessly pop-up picture-in-picture when navigating away from the video tab is useful enough but the meeting feature is key for me because my company uses Google Meet. I can navigate away from meetings to look-up info/check Slack/etc without losing focus on the meeting itself and getting back to the meeting tab or unmuting myself is 1 click away.
Sure all of these things could probably be accomplished by browser extensions but I think the UI/UX within Arc is pretty tough to compete with.
the developers working with firebase should enforce common-sense document crud restrictions in the rules. that's just how firebase is. everyone knows it.
now, when talking about ARC BROWSER, i am seriously starting to doubt the competence of the team. I mean, if the rules are broken (no tests? no rules whatsoever?), what else is broken with ARC? are we to await a data leak from ARC?
any browser recommendations with proper vertical tabs and basically everything working like it does in ARC?
Did you took a look at the zen browser? It's an arc clone based on Firefox https://zen-browser.app/
I did. It’s like 20 % an Arc clone, and 80 % of UX papercuts. Like, you can’t have ‘add tab’ button on top when the new tab gets added to the bottom. Or that one sidebar button opens a side window to the right of the sidebar, while another below it opens the favorites to the left and moves the whole sidebar from underneath your mouse.
Looks like a minimal effort css restyle of Firefox.
nice. will probably try it in the future.
but the for-some-reason-not-obvious revelation that it's just a product that some team somewhere is working on and the fact that a browser is an important piece of software brought me back to safari (not sure if joke's on me, but in this case I trust apple engineers to do a more thorough job in ensuring my data is secure).
i'm rooting for them to succeed, but if the concern is security, switching your daily driver browser to a brand-new browser that's still in alpha is unfortunately not a good idea.
It's not in Alpha though, they've been around for years and have launched formally.
Try Firefox with Sideberry extension.
Zen and MS Edge have proper vertical tabs.
Brave. Vertical tabs, privacy, everything sync is e2ee (unlike eg. Edge).
Vivaldi may also be worth a look. Similar setup: User-oriented team, vertical tabs, e2ee sync. If you like a thorough browser history, I think Vivaldi keeps a more detailed browsing history than most other Chromium browsers.
Brave is VC funded and needing to extract a billion of value. Just like Arc.
while researching, i saw some data being sent over to the server, like this query everytime you visit a site
I'm not surprised in the least --- basically the vast majority of software these days is spyware. Looking at Arc's privacy page, it appears to be mainly marketing fluff similar to what I've seen from other companies. I have yet to find a privacy policy that says frankly "we only know your IP and time you downloaded the software, for the few weeks before the server logs are overwritten."
Seeing "privacy focused" in any sort of mission statement is almost becoming an indicator of the opposite (I'm sure there's a word for this)
I'd rather a company have simple goals that can be explained in a sentence or two. No hand wavey BS like "we care about your privacy"
> I have yet to find a privacy policy that says frankly "we only know your IP and time you downloaded the software, for the few weeks before the server logs are overwritten."
Not with those exact words, but that’s Alfred. Server connections are done only to validate the license and check for updates, and you can even disable that.
https://www.alfredapp.com/terms/
> Alfred only contacts our server when activating your Powerpack license in order to validate it, as well as periodically checking for new software updates. You can disable the software update check in the Update preferences, but we recommend keeping this enabled to ensure that you always have the latest version for security reasons and to make the most of the awesome new features!
Yeah, and no mention of if they addressed this.
According to their blog post https://arc.net/blog/CVE-2024-45489-incident-response they fixed it:
> We’ve fixed the issues with leaking your current website on navigation while you had the Boost editor open. We don’t log these requests anywhere, and if you didn’t have the Boosts editor open these requests were not made. Regardless this is against our privacy policy and should have never been in the product to begin with.
We looked into supporting Arc at work, unfortunately Arc is missing lots of basic security controls which are available in many other Chromium and non-Chromium browsers, these include:
+ The ability to enforce automatic updates + Ability to control which sites extensions/boots are installed on
On top of this there seems to be no way to remove the requirement to have an account to use the browser, selectively choose what data is sent/sync'd from Arc, or disable basic features like Easel through which staff accidentally leak data.
The UI for the browser is great, but Arc really needs to lay the groundwork for strong security controls or it'll struggle to gain (or even maintain) a foothold in the enterprise space.
Man I miss these kinds of detective posts on HN
Upvote them, definitely something that makes HN special.
I’ve been using Arc since it was private, and I really like the browser. The company’s posture on this topic has pretty much made me drop it entirely. It’s beyond abysmal.
I thought this was novel, and assumed it was just something to do with websockets, so I switched to another, non-firebase-but-yes-websockets project and noticed it didn't work.
At the time, I debated moving calls to Firebase just so that I could work for free while I was on flights, but realized the ROI wasn't remotely there. Glad to finally have someone else acknowledge it happening, and give some insight as to why.
Some flights have a free tier of wifi that allows messaging apps. Google Voice and Google Hangouts usually work on those so wouldn't be surprised if some other Google services make it through.
Fascinating vulnerability, and a fascinating way to catch it. Kudos.
BTW, on Arc's website on "Security" there still is no mention of this vulnerability (as of 20th Sep 2024, 2:32 pm PT)
Check it out - https://arc.net/security
Apparently the company had contracted with one Latacora for "regular outside security reviews and trainings across a wide range of different systems".
Elsewhere on the page, it says "Arc uses GCP Firebase for user authentication, storage for Notes & Easels, and Cloud Functions for certain application features like referral code generation. All data stored in Firebase is encrypted-at-rest by default."
The security page explicitly claims that Arc doesn't log what you're doing, giving URLs as an example, but this vulnerability claims every URL is being sent up to Firebase.
User identity must be derived from security context, typically at the edge of the system.
But it’s so much easier for developers to think of userid as just another parameter, and they forget, and oops now they trust a random user-supplied parameter.
Always been weird how this requires an account.
Also the forum shills are worse than Brave ones.
For some time I asked why doesn't Arc let me sync my passwords.
After seeing this level of incompetence, I am happy they didn't attempt that.
Yet.
The vulnerability has been patched, but I suppose the browser still makes a firebase query for every website you visit?
That's pretty bad, whether or not they track these requests, just seems wasteful.
The firebases and the supabases of the world are crazy to me to build your company on. You are asking for trouble and anchoring your entire company on the health of one saas that is hooked into the foundational aspects of your application!
also it's so incredibly easy to really fuck up and build something exploitable.
are javascript devs really that afraid of doing things themselves to this extreme level?
What about S3, you don't really need a file storage provider either?
> are javascript devs really that afraid
You might be afraid of JS devs :P Anyway has nothing to do with language, even if it was a super c0ol Ruby-on-Rails app with Active Record and SQL db on a server you manage it's still common to have some stuff in NoSQL for fast access to live data, caches, logs, etc. Most companies at scale will have both SQL and NoSQL dbs in areas. So if you're already using S3 for files, code on GitHub, storing keys in 1Pass, why not use a Firebase or MongoDB for high traffic live data? Especially if they offer built-in scaling and geo deploy options.
This scenario I laid out is kinda to your point of "don't anchor your entire company on it" - the only point I'm trying to add is that you can also use these tools without the company being "anchored" on it, and they could have still ran into the same issue as Arc.
I mentioned javascript because I mostly see that cohort jump feet first into services like firebase/supabase/clerk/vercel/etc.
Vercel too?! What are you using for SSR + serverless, Amplify?
Vercel seems pretty great for a React-centric app with a couple of one-off backend calls to cloud services, super convenient, deploy previews in GitHub etc. why not?
I wish we didn't have to sign up to use a browser in the future
just don't use browsers that do
With Brave you don't need to, even for sync.
Start -> Control Panel -> Programs and Features -> Search 'Arc' -> Uninstall.
...said Windows user.
Even worse, to write the comment I had to ask ChatGPT how it works for windows...
This is a nice investigation and a great read. Sad that they don't normally do bug bounties. $2000 seems small considering the severity of this vulnerability. Though I guess the size and finances of the company is a factor. It takes some serious skills, effort and luck to discover something like that. It should be well compensated.
It is troubling that the browser that cannot be used anonymously displayed questionable behavior adjacent to the mechanism that tells The Browser Company every time you are watching porn
I know Firebase is awesome for plenty of reasons. And I’m not disparaging anyone who works hard on it. There’s a ton of great software behind the product.
Unfortunately it’s at the root of almost all of my career’s worst bugs and mistakes (not necessarily caused by me), and it seems like a bit of train wreck in the wrong hands. I’ve had to rescue several clients from it, and have migrated three pretty huge applications off of it now.
I’m not sure what it is exactly. People really abuse the hell out of it.
> firestore has a tendency to not abide by the system proxy settings in the Swift SDK for firebase, so going off my hunch, i wrote a frida script to dump the relevant calls.
As someone who has done some reverse engineering of macOS apps but haven't used anything beyond Charles' macOS proxy feature, this looks very painful. Is there a proxy app that maybe acts as a VPN so that basically every HTTP request is guaranteed to go through it, so that you don't need to write a hundred lines of bespoke Frida just to capture requests?
Edit: On second thought Proxifier should work for this purpose.
To add to u/ibash's comment, mitmproxy correctly implements a macOS network extension: https://mitmproxy.org/posts/local-redirect/macos/
I assume you'll have to install a root cert in order to introspect HTTPS traffic though.
mitmproxy.org can act as a wireguard vpn iirc
I just want to say that Firebase security rules deny every operation by default. An empty rules file allows nothing.
The devs that wrote these rules had to intentionally allow overly broad reads/writes to this part of their database in order to create this vulnerability. And this had to pass code review and automated testing.
That’s not good, and it has nothing to do with their choice of tools.
For context: what is this 'arc' that the blog post mentions? I presumes it's not Paul Graham's Lisp dialect in this context?
EDIT: seems to be a browser or so?
Yes it's a new browser who tries to change the UX from traditional browsers: https://arc.net/
$2000 for remote exec on all their users even if it’s all 17 of them? Insultingly low.
How is this "Arc boost" system not just a more limited ad-hoc version of what WebExtensions already provide?
Oop and I just convinced my wife and brother to move over :o
Props to her, she asked about the security and privacy of the browser and I played it off with some fanboy propaganda. Lesson learned on that one. If I only care about the vertical tabs, workspaces, and a (decent) mobile app are there any good equivalents right now?
> If I only care about the vertical tabs, workspaces, and a (decent) mobile app are there any good equivalents right now?
I use Firefox mostly because of Sideberry (which does vertical tree-style tabs) which also integrates with "containers", so you can have something similar to workspaces but more isolation. Otherwise there is also "profiles" that probably offer even more isolation between the different profiles.
Firefox with extensions? The current vertical tabs extensions are not nearly as nice, but Mozilla is working on native vertical tabs. Syncing and Workspaces are already better with Firefox then with Arc.
I just use Brave with a shitton of profiles. That does cause problems for mobile use since no Android browser dev has bothered with proper profiles or ability to install multiple copies of the browser, except for Google I guess.
I use Firefox with Sidebery for vertical (specifically, tree style) tabs, plus a userChrome.css to hide the native horizontal tabs. Firefox has mobile apps, and the Android app supports (some) browser extensions.
It works, it's boring, and it doesn't try to shove gimmicky features in my face.
Even in Safari, you can remove tabs from toolbar (but it is not possible to hide toolbar itself) and have them in sidebar - there are also tab groups.
But experience is probably different.
Great catch ! Also very cool to know a bit more about the tech they are using.
Very small bounty, but I honestly believe this arc thing won’t last long…
Browsers are hard and my only choice has been chrome and will remain so for the long foreseeable future.
When I was younger I would enjoy switching to firefox, opera, etc..
But I always came back to chrome because it just worked and always performed when I needed.
Chrome/chromium is the safest browser.
People tend to fall for the shiny new thing and then realize it was just hype.
Please be very careful about what software you choose to perform most of your activities.
The same applies to these “new ai IDEs” that keep popping up every other say.
…Firefox as an alternative to Chrome!? Am I really that old!?
I used Chrome for years and years, right from when it first came out. Since then, I switched back to Firefox, and have used it for years. It works perfectly fine.
Browser is an user agent. Chrome is an advertisement company agent running on your PC, collecting data for that advertising company.
People often confuse these two, but they’re the polar opposites.
> Chrome/chromium is the safest browser.
Why do you say that?
1. Chrome's security team has a very good reputation.
2. I don't know how accurate it is in 2024, but there are comparisons like https://madaidans-insecurities.github.io/firefox-chromium.ht... out there.
>proprietary chromium fork with aislop on top No thanks
How could one sell a vulnerability like this to let's say Mossad? Write them an email?
https://www.mossad.gov.il/contact-us/en
Interestingly enough, contains a field for entering your Father's name (but not your mother's).
Page them :)
hmm gee I wonder was it worth to value the bug bounty at $2500 given the severity of both the bug and sheer lack skills of the browser company staff...it might even be a reputation destroyed event...
Yikes.
I tried Arc a while ago but switched back to Chrome. Quite glad I did now.
$2000 is an insult, good luck getting tips for your future vulns.
Breakthrough technology, indeed.
Yeah with this and the privacy zinger at the end its definitely time my monthlong experiment with arc comes to a close. Too bad that the thing theyre actually proud of, the tabbing UX, was actually really good.
eva (kibty.town) and mr. bruh never disappoint!
>privacy concerns >while researching, i saw some data being sent over to the server, like this query everytime you visit a site:
> firebase .collection("boosts") .where("creatorID", "==", "UvMIUnuxJ2h0E47fmZPpHLisHn12") .where("hostPattern", "==", "www.google.com");
> the hostPattern being the site you visit, this is against arc's privacy policy which clearly states arc does not know which sites you visit.
Maybe I am just stupid, but this *super* smells of arc being able to inject whatever they want in to literally any of your websites and this dude just figured out that he could also do that.
This does not seem like a browser capability I want.
seems like it is the case: https://news.ycombinator.com/item?id=41601332
What sort of data does Arc track? Our plain-english Privacy Policy summarizes it well:
We don’t know which websites you visit
From the quoted snippet, every page load is leaking both the domain and authed user’s ID to Firebase.
Yeah but if they super promise to not look at incoming Firebase queries they're not tracking you, right?
The super promise died with crypto, now you have to add no backsies. My site uses No Backsies Proofs (NBPs) which are encrypted to prove that all my super promises are backed by a no backsie which is stored in the no backsie vault in Antarctica.
Later on moxie ends up writing a quick review of NBPs
> Instead of storing the data on-chain, NBPs instead contain a URL that points to the data. What surprised me about the standards was that there’s no hash commitment for the data located at the URL. Looking at many of the NBPs on popular marketplaces being sold for tens, hundreds, or millions of dollars, that URL often just points to some VPS running Apache somewhere. Anyone with access to that machine, anyone who buys that domain name in the future, or anyone who compromises that machine can change the image, title, description, etc for the NBP to whatever they’d like at any time (regardless of whether or not they “own” the token). There’s nothing in the NBP spec that tells you what the image “should” be, or even allows you to confirm whether something is the “correct” image.
this is why my startup is launching backsies rollups for the blob, with null-effect prebacksies. this way everyone can be assured that any backsies issued are technically equivalent to just not making the original agreement! if you can discover a post-agreement backsie within the availability period of 0 days, and we can confirm it, we'll pay you $2,000 no backsies. so we have a market incentive not to lie to you. it's very efficient
indeed, the market efficiency of a house of cards built on sand and thin ice cannot be overstated
I would feel more comfortable if your super promises were all on a blockchain, and we made No Backsie NFTs so people could clearly see these were legitimate and bid on them.
Yea if everything else is not enough of a red flag here, the fact that they are sending every single website you visit to Firebase — against stated privacy policies — is the mother of all red flags.
People say they like arc for the UI and there are all alternatives, but do you really want to risk someone stealing your bank creds and stealing all your money for some fancy UI?
[dead]
https://www.crunchbase.com/organization/the-browser-company/...
> Total Funding Amount $68M
the browser company normally does not do bug bounties, but for this catastrophic of a vuln, they decided to award me with $2,000 USD
I'm struggling to put into words how disappointing I find this.
I've got a different take. If they're in the VC phase, that means they are not self sufficient. The amount of funding that they've raised is no indication what-so-ever of a) how much of that funding has actually been realized / received b) what their overhead is and c) what their overall financial picture looks like.
I do wish that more companies would take privacy and security seriously. And bug bounty programs are great. But they're not always within the budget of companies and the fact that they decided to award this security researcher regardless of having no such program is a massive win in my opinion and shows how much they value this particular contribution.
Thanks for the reply! I think I disagree with you, mostly because it seems like this particular bug could have been company-destroying because of the potential reputation hit if it was exploited on a wide scale.
But regardless, I appreciate your perspective and it gives me some stuff to consider I hadn't previously.
I think we all know that tech debt often lives forever, so if you're going to start a browser company, you simply must be thinking about security/privacy from day one. If the VC model doesn't make that possible, then the only reasonable conclusion is that browsers shouldn't be a thing that VC funded startups work on.
I appreciate your response, and largely agree with you. But you can take security seriously without having a program in place to pay non employees for work they did without you asking them to.
Also, while I love companies that have bug bounty programs... I don't think any company without such a program is under any obligation to pay someone just because they volunteered their time without the company knowing about it or soliciting the work in any way.
So the fact that they did in this case, despite having no program, is what I'm choosing to focus on.
I want to share a personal anecdote to put my opinion into more perspective. I owned a small business operating a for-profit website for 18 years, for 15 of those years it was my primary source of income. I had no employees other than myself. It was just me on my own working from home. I earned enough to pay the bills, but I'm currently earning 2x what my business earned at its peak traffic by being an employee. So it's not like I had money to be paying people... it was pretty much an average software engineer's salary in terms of what I brought in.
Anyway, over those 18 years I had a few dealings with some white-hats who were very nice and clued me in to some issues. I thanked them and when they politely asked if "we" (because they didn't know any better) had a program it was a non-issue when I explained that I'm too broke as a one-person shop trying to feed a family to be paying out anything substantial but I could PayPal a cup of coffee or something for their trouble. But then I had a few dealings with complete shady assholes who tried to extort money out of me by threatening to exploit what they had found and go public and basically drag my reputation through the mud.
Experiences with the latter group make me sympathize a lot more with companies that decide to have a policy of just blanket not dealing with outside security researchers, to take the information and then deal with the fixes internally and quietly.
This is 100% company culture, probably the ones that decide this kind of things are not technical or don't understand how important is this.
They disclosed the vulnerability directly to the co-founder CTO.
> the timeline for the vulnerability:
> aug 25 5:48pm: got initial contact over signal (encrypted) with arc co-founder hursh
> aug 25 6:02pm: vulnerability poc executed on hursh's arc account
[flagged]
Arc is a great product, it's the nicest web browser to use, you can tell these people are really good at their jobs in many respects (though apparently not security?!?). probably a lot of investors saw that too and are willing to fund a very strong team with the hope of eventual product-market fit.
That's one explanation.
Every single thing I've heard about Arc browser has been a massive red flag. Turns out it was even worse than I thought!
I’m ashamed I fell for Arc and even recommended it to my friends, as someone whose job is exactly this but with Android apps :(
They claim so much and their browsers' code is 100% proprietary so it's impossiblen to verify their lies. This is what triggered the bullshit detector in my head
> They claim so much and their browsers' code is 100% proprietary
Far from me to defend Arc (I dislike it for several reasons) but it’s based on Chromium so it’s far from 100% proprietary. Don’t Edge, Vivaldi, and even Chrome have proprietary layers on top of the open-source Chromium?
Vivaldi's inhouse UI code isn't open source, but is visible for users to verify AFAIK.
I read this from another source and I was a substantial way into it before it became obvious what Arc is.
Blog authors: stop assuming I know about the existence of every piece of software.
(also maybe occasionally consider using the Shift key on your keyboard so you can capitalise things :)
[flagged]
The dog is actually a cat named Neko.
https://en.wikipedia.org/wiki/Neko_(software)
To be clear, it's a cat named "cat" in Japanese.
I got downvoted for calling it a dog??
Now that's ruff!!
Good pun :)
HN tends to be a little hard on brief comments. My current understanding is that comments with little substance are totally acceptable provided they're good natured.
For example this comment by dang "There's nothing wrong with submitting a comment saying just "Thanks."" https://news.ycombinator.com/item?id=37251836.
Also from the guidelines "Comments should get more thoughtful and substantive, not less, as a topic gets more divisive": this post's topic doesn't likely qualify as divisive.
[flagged]
Damn, that is bad. While I enjoyed reading through the write-up, I think a "summary section" at the top would have benefited me lol.
Someone recently recommended Arc to me, I installed it on my macbook and then never actually used it when I realized there's no Linux version available, and I like a consistent browser experience across all my devices.
You can use some Arc AI features to summarize it for you :)