3 ms·

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 pos

by sushid 2y ago

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.

wahnfrieden 2y ago
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
ha470 2y ago
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.
- deleted 2y ago
  [deleted]
- zamadatix 2y ago
  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).
  - sieabahlpark 2y ago
    [dead]
  - zamadatix 2y ago
    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_spoofing_flaw/ 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.
    - sieabahlpark 2y ago
      Every comment I make is immediately dead upon me posting, it's been that way for about a year. I believe transparency is necessary, but also have been in the situation where the alarms are going off and you slip on making sure disclosures are optimally distributed. Generally I'm just concerned that it's documented at all. Now if they maintained not revealing the security issue over the following week I'd agree. Should they have had a bulletin stating when it occurred in August? Absolutely. I'm not disagreeing, and the distance from that event I would agree with you. However, considering just how fundamental the security vulnerability was there isn't exactly an immediate benefit to blast that to the world. It opens up the spotlight for more advanced attacks to take advantage of other unpatched holes. Taking the time to go through and _really_ make sure it's patched (as well as a general check around the codebase for other EZ vulns) is, in my opinion, the better option. Now if this had been a larger timeframe and repeated offense I'd agree the security hygiene for Arc should be bumped up in priority ASAP and until that probably happens Arc as a platform could not be trusted.
  - netdevnet 2y ago
    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
- xelamonster 2y ago
  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.

by sushid 2y ago

wahnfrieden 2y ago

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

ha470 2y ago

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.

deleted 2y ago
[deleted]
zamadatix 2y ago
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).
- sieabahlpark 2y ago
  [dead]
- zamadatix 2y ago
  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_spoofing_flaw/ 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.
  - sieabahlpark 2y ago
    Every comment I make is immediately dead upon me posting, it's been that way for about a year. I believe transparency is necessary, but also have been in the situation where the alarms are going off and you slip on making sure disclosures are optimally distributed. Generally I'm just concerned that it's documented at all. Now if they maintained not revealing the security issue over the following week I'd agree. Should they have had a bulletin stating when it occurred in August? Absolutely. I'm not disagreeing, and the distance from that event I would agree with you. However, considering just how fundamental the security vulnerability was there isn't exactly an immediate benefit to blast that to the world. It opens up the spotlight for more advanced attacks to take advantage of other unpatched holes. Taking the time to go through and _really_ make sure it's patched (as well as a general check around the codebase for other EZ vulns) is, in my opinion, the better option. Now if this had been a larger timeframe and repeated offense I'd agree the security hygiene for Arc should be bumped up in priority ASAP and until that probably happens Arc as a platform could not be trusted.
- netdevnet 2y ago
  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
xelamonster 2y ago
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.