Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kibty.town

Post reply on HN
Print view View original

431–440 of 538 posts

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

#431

Post by moosedev »

gwd wrote: post #303
Rygian wrote: post #117

Earlier quoted context omitted.

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)”.

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

#432

Post by gukkey »

titaniumtown wrote: post #288
ayhanfuat wrote: post #245

Earlier quoted context omitted.

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.

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.

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.

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

#433

Post by qwertox »

Borgz wrote: post #52

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?

They don't encrypt the data they send via Firebase?

I mean, even Google suggests doing this with sensitive data.

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

#434

Post by voiceblue »

rafram wrote: post #408
shuckles wrote: post #350

Earlier quoted context omitted.

"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.

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

#435

Post by rixed »

johndough wrote: post #320
0x1ceb00da wrote: post #146

Earlier quoted context omitted.

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

so, to remind your coworkers that they should securely lock their computer, you download some software from http and run it on it?

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

#436

Post by cutemonster »

kfarr wrote: post #211
zachrip wrote: post #143

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…

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

Is there no Allow-read? Edit: Yes,

    allow read, update, delete: if request.auth != null && request.auth.uid == userId;

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

#437

Post by rixed »

macintux wrote: post #333
causal wrote: post #132

Earlier quoted context omitted.

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.

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.

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

#438

Post by voiceblue »

aucisson_masque wrote: post #371

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

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.

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

#440

Post by kerkeslager »

zachrip wrote: post #143

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…

A security plan which depends on any person never making an amateur mistake, is an amateur mistake.
Post reply on HN