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.

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.

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

Leaves no choice but for this community to make the rest of the Arc community aware of it as they refuse the transparency

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.

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.

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.

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?

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.

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.

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

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

You've been handed a golden opportunity to set the right course.

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 think this should be a resigning matter for the CTO.

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.

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

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.

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.

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.

Firebase ACLs are a constant source of vulnerabilities largely because they are confusing and don't have enough documentation around them.

Is there a reason why you don’t have any security-specific positions open on your careers site?

Also, there's the whole notion of every URL you visit being sent to Firebase -- were these logged? Awful for a browser.

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.

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.

To be honest, I'm a bit disappointed. For future reference, this doesn't seem like a good strategy to contain reputational damage.

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.

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

Being prompt on a vulnerability of this magnitude should be considered "meeting the standard" at best.

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

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?

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.

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

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.

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.

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.

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

God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.

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.

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?

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.

```

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

```

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.

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

    printf '2c2e05f1241e9b76f54475b5577cd4fb6670de058218d04a741a04ebd4a2b22f\t oneko-1.2.sakura.5.tar.gz' | sha256sum -c

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.

So the OP is right. Arc's privacy is worse than Chrome.

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.

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.

The same story with default-allow means the system looks like it works fine, and you end up with no security at all.

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.

Honestly I strongly feel the title should be “fundamental bug in Arc browser (CVE 123-4567)” or similar.

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.

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.

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.

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)

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.

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

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

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]

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.

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

This is all really sad news.

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/

Unfortunately you are also describing Mozilla here.

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

If you're trying to bring value to market, focus on your core differentiator and use existing tooling for your boilerplate stuff.

It’s not only not a smart engineering decision, it’s also a terrible product, reputation and marketing decision.

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.

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.

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?

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

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.

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

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.

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.

(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

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.

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

That's pretty interesting. Where can I learn more about this?

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.

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.

And who's going to take the bet that they'll find nothing? Not me.

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.

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.

That's why brokerages like Zerodium exist - you can sell it to them, and they'll sell it onto state actors.

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.

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

It has seeped into HN as well. Look closely and you’ll notice several commenters type like that.

I wonder if this is a regional or generational thing?

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.

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

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.

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.

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.

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.

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.

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

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.

And nobody tYpEs lIkE tHiS except when making a joke.

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.

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

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

  }

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.

Which is scary come to think of it.

I think Apple is starting to sync too much...

Either way, you can disable syncing of system settings.

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?

I genuinely wish you a calm weekend and peaceful start of the week.

I'm not very familiar with Firebase. In what way is it broken and what issues does it cause?

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.

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

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.

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?

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

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.

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

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

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!

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.

After seeing this level of incompetence, I am happy they didn't attempt that.

Yet.

That's pretty bad, whether or not they track these requests, just seems wasteful.

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.

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.

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

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.

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?

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.

It works, it's boring, and it doesn't try to shove gimmicky features in my face.

But experience is probably different.

EDIT: seems to be a browser or so?

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.

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.

People often confuse these two, but they’re the polar opposites.

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?

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

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

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?

> 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 does not seem like a browser capability I want.

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.

But regardless, I appreciate your perspective and it gives me some stuff to consider I hadn't previously.

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.

> 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

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?

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 :)

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.