Hacker News new | past | comments | ask | show | jobs | submit | sushid's comments login

Aren't those types of prompts the MOST likely to generate hallucinations?

Not in the contexts that the author is talking about, when you have the canonical answers in your data set and know roughly where to look for them.

"Even if I was wrong by many orders of magnitude, I'm still correct!"

The article highlights that it’s not actually that hard for the ultra-wealthy to avoid a massive estate tax bill through proper tax planning and investment strategies. What’s striking here is that this individual wasn’t even the richest person to ever die, yet he paid the largest estate tax in history, likely by choice.

> likely by choice.

There is an element of competitiveness there. Some rich want to be known as rich and so they can brag about paying the most taxes that in turns implies they have the most money. Others want to be quieter about their wealth and so don't want you to know they have it and wouldn't tell you how much taxes they pay.


If he were doing it competitively, I don't understand the strategy. His name was leaked, not announced, and since he is dead he cannot feel like he won the competition.

Sometimes rich could not find a way out of paying a large tax, so instead they pull at least some good from their bad situation, and make it a PR.

And it's a good thing that government is strong enough to be able to collect large taxes. Contrary to popular opinion, rich people are mostly OK paying large taxes, but only as long as all other rich pay their share as well. The grudges they hold are only about unfairness, not about amounts.


That's because the "marketing industry" is filled with those using emails. It is absolutely just for old people at this point.

> And RAG has many, many issues with document permissions

Why can't these providers access all documents and when answers are prompted, self-censor if the reply has references to documents that the end users do not have access permissions? In fact, I'm pretty sure that's how existing RAGaaS providers are handling document/file permissions.


Would the texts of those documents be part of the LLM training data? If so, there's an reliable way to keep a determined user from fetching stuff back out.

RAGaas, didn’t know I needed that in my life

That's a pretty quick way to expose what information you're trying to keep secret.

Hasn't this always been Amazon's strategy? It's never been like Facebook or Google in its ethos.

It reads like the authors wants to rip apart MKBHD but is withholding some of his harsher words because he's... felt bad about doing the same before? That's fine but he's doing neither here by mentioning how he's resolving to be less critical.

IMHO, MKBHD's whole schtick is reviewing things critical (or positively), the way it's presented right now as opposed to how it might pan out down the road. And for a Youtuber with an eye for attention to detail, this Frankenstein app with a $50 price tag is truly terrible. I'd say why not give him the treatment he gives others?


People used to superblock via "apps" e.g. block this person and all those that follow this person, block everyone in this thread, etc.


This specific security vulnerability was the main reason you watched Youtube on a dedicated account?


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.


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.


(I've vouched for this comment, maybe that helps.)


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


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: