Live data from Hacker News

Gaining access to anyones Arc browser without them even visiting a website

kibty.town

231–240 of 538 posts

Re: Gaining access to anyones Arc browser without them even visiting a website

#231

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…

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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#232
post #194
post #179

Earlier quoted context omitted.

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 somewh…

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…

indeed, the market efficiency of a house of cards built on sand and thin ice cannot be overstated

Re: Gaining access to anyones Arc browser without them even visiting a website

#233

Earlier quoted context omitted.

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.

> a “tinder but for cats” startup idea Needs a name. Meowr? Hissr?

Yowlr. (Which is apparently a dubstep musician.)

Re: Gaining access to anyones Arc browser without them even visiting a website

#234
post #222

Earlier quoted context omitted.

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…

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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#235

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?

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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#236

Earlier quoted context omitted.

> 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…

"don't trust the client / validate inputs" is software security 101

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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#237
post #213

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…

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 dat…

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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#238
post #109
post #78

Earlier quoted context omitted.

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.

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.

[flagged]

Re: Gaining access to anyones Arc browser without them even visiting a website

#239
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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#240
post #198
post #181

Earlier quoted context omitted.

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.

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.

Maybe docs should try to be consistently more accurate, up to date, and legible than (even) stack overflow answers ¯ \ _ ( ツ ) _ / ¯
Post reply on HN