Hacker Newsnew | past | comments | ask | show | jobs | submit | iptq's commentslogin

The $50 million punishment feels so insubstantial to Microsoft that they probably wouldn't even think twice before doing similar things again or worse. Only things that could threaten the bottom line would actually make companies reconsider.


> The $50 million punishment feels so insubstantial

It's potentially quite a bit more. TFA mentions another two penalties: "three times the total benefits that have been obtained and are reasonably attributable" (~2.5 million customers times $40+ for the difference in subscrptions times three is $300 million), or "30 per cent of the corporation’s adjusted turnover during the breach turnover period" if the preceding can't be reasonably calculated (I'm not going to dig through Microsoft's financial statements, but it's probably substantial.) The greatest of three is taken.

If you still think it's pocket change, the point of fines is not to bankrupt the company, but to lead them to less shitty behavior by disincentivizing the alternative. It takes a persistent effort and time.


ah shoot wait i just realized "take the greatest" goes in the other direction. doh


No expert, but these fines are usually exponential. Usually they start with a slap on the wrist of $100,000s, then climb to the millions.

That the opening figure is so high it's clear that if MS ever do it again the fine will be in the billions.

So you might even say it's actually a moderately strong statement by the Australian government that they're not playing around.


If this can't run full-local, isn't that basically a botnet? You're talking about installing a kernel-level driver that receives instructions on what to do from a cloud service.


Great point! Yes you are correct in that the actual "agent" lives in the cloud and its actions are executed by a proxy running on the desktop. Hopefully at some point we can set up a straightforward installation procedure to have the AI models running entirely on the desktop, but that's constrained by desktop specs for now. VMs and desktops with the specs to handle that would be prohibitively expensive for a lot of teams trying to build these automations.


Out of curiosity, what would the minimum specs need to be in order to run this locally?

My PC is just good enough to run a DeepSeek distill. Is that on par with the requirements for your model?


There isn't a viable computer use model that can be ran locally yet unfortunately. Am extremely excited for the day that happens though. Essentially the key capability that makes a model a computer use model is precise coordinate generation.

So if you come across a local model that can do that well, let us know! We're also keeping a close watch.


Haven’t looked into them much but I thought the Chinese labs had released some for this kind of thing


You are correct in that ByteDance did releas UI-TARS which sounds like a really good open source computer use model according to some articles I read. You could run that locally. We haven't tested it so I wouldn't know how it performs, but sounds like it's definitely worth exploring!


What would it take to train your own?


I don't know too much about training your own computer use model other than it would probably be a very hefty, very expensive task.

However, I believe ByteDance released UI-TARS which is an excellent open source computer use model according to some articles I read. You could run that locally. We haven't tested it so I wouldn't know how it performs, but sounds like it's definitely worth exploring!


This headline seems misleading; the way I'm reading this, it's still just a request to the courts, who will make the final decision right?


Yes. This is the DOJ’s proposal for what should happen now that Google was found guilty.

Google will make their own proposal, I think. Then the judge will decide.

Then 50 years of appeals.


it indeed is. when I saw it in my mstdn feed, i too was shocked but upon reading, uh, no.


If companies are already willing to obscure chat logs, what's to say they won't begin manufacturing artificial logs (or editing existing logs) under this kind of pressure?


People are generally more willing to do slightly unethical things over really unethical things.

That's why in this case, I think it's much more likely that they will simply move to discussions to unlogged avenues like phone calls or speaking in person rather than edit logs.


This is that water cooler innovation thing you just can't without RTO. There's a pesky paper trail when you ask employees to do illegal things online!


Spoliation for $500 please.


This entire article feels like it was written by ChatGPT. For instance, it continuously makes vague claims about the value of open source without even citing the original bill.


The eagerness to summarize points in bulleted lists is a ChatGPT-ism as well.


Hey now, I like bullet points myself, as I'm easily distracted otherwise.


This is going to become one the the site no-nos. What does this assertion add to the discussion? Is there any argument that serves as refutation?


If an article is AI, it's essentially spam, because there could be a thousand more similar written.


Raising awareness so others too can flag TFA


The quality of the article is what should drive voting and flagging.

Your personal opinion as to what level of AI tooling was used in crafting the content is a low value signal and posting that speculation without meaningfully engaging in the content is as low value as commenting to say "this article sucks".

Personally, I think this would be a very strange place to find pute AI genetated content. This is a personal statement that was submitted to the state, and posted under a real name under a site the poster has a professional association with. I think that any "strangeness" in formating a wording comes from the role this text serves, as a public comment intended to affect policy.


Why would I want to read some AI-generated slop? It's no different to spam, other than techbros being okay shoving it everywhere and anywhere it doesn't belong.


Same experience here, React is actually very good about backwards compatibility, and for anything that is pervasive, codemods via jscodeshift works pretty well too.

I have had to make changes to the build system for the React system I maintain at work, but in no way would I consider it a "rewrite", as much as a "refactor" for a specific part of the codebase while leaving the rest relatively untouched.

In fact, JavaScript moving to ESM has broken MUCH more code than any of the React features listed in the article.


Without releasing source code and a transparent client build process this kind of claim is just kind of ...useless? If anything tells me they can't see my data and the client isn't completely in the open then I have 0 shred of confidence that they're trustworthy.


exciting to hear! I only wish i had more time to contribute.

Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone


Low Bandwidth Matrix is the answer to that, and it’s currently on hold unless it gets funded: https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i...

It might also get changed as part of Sliding Sync refinement.


Hopefully it will be the default once implemented. Everyone will benefit from compact protocol in the long run. Should have been done from the very beginning.


Is there going to be a way to have very simple clients, perhaps with a helper in the server side?

It'd be nice to bring matrix to microcontrollers and "retro" computer platforms.


the API already is super simple, and low bandwidth could already work on retro machines (I had 6809 in mind when experimenting with it). The problem is e2ee, but we have the Pantalaimon e2ee proxy to convert unencrypted Matrix traffic into E2EE traffic for precisely this sort of thing :)


That's promising :)

I had 68000, 8086/88 and 6502 in mind.


I wish that reputable reporting on this kind of topic would start putting accuracy next to what it can reportedly do. I remember visiting a machine learning poster session where many of the posters reported results with accuracy as low as 30%.

If a program is able to predict this once or twice it's not a miracle. If it's able to do so with 60% I'd raise some eyebrows. But I'd say it's only a turning point when it's able to beat false positive rates of human doctors. Without an accuracy score, this news is absolutely meaningless.


Accuracy is well understood to be a terrible, misleading metric and any reputable report would strive to avoid emphasizing its importance.

For those curious their test set AUC appears to be 77.


Maybe I’m misunderstanding, but if you could have a test that doesn’t say anything if it isn’t sure, but if it is sure with very high confidence gives you a true positive, that has a lot of value.


As an aside, this was also the only strategy that seemed to scale in intrusion detection.


Even with an accuracy score, it’s meaningless. Accuracy isn’t the right metric.


If you like, please mention more; I at least am interested to hear


Consider it this way.

If your AI algo scanned the general population and it said 100% of the time, "no risk of esophageal cancer" It'd still be 99.5% accurate.

It's highly accurate. And useless.

To get a good idea of how useful it is, you need to know it's false negative rate and false positive rate as well as it's accuracy.


I think this article confuses "simplicity" with "less code". Often times when we talk about simplicity, it's about overall conceptual design, and on the note of dependencies, it's often _more_ simple to use something that does the job and brings in some more dependencies than it is to aggressively try to prune and end up costing more maintenance burden.


You might be confusing ease with simplicity. It's /easier/ to use something that pulls in more dependencies rather than write that bit myself; complexity of my software goes up. It's just entropy.


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

Search: