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

who is we, this argument is as useful as "we should not waste food so we can fix starvation"

I found the Rosetta Stone of Hacker News.

people, humans, the species

I would argue the (very incomplete) list in my comment is predatory whereas wasting food is not (for the most part)


I mean it's not hard to understand that if good model can run on consumer hardware, even better models can run in data centers


If we get to the point where a local model can reliably do the coding for a good majority of cases, then the economic landscape changes significantly. And we are not that far from having big open weight models that can do that, which is a first step


Larger, yes, absolutely. Better? Right now it seems that bigger is better, but if we are thinking about long term future, it's not obvious that there isn't a point of diminishing returns with regards to size. I can also imagine a breakthrough, where models become much smaller, with the same or better capabilities as the current, very large ones.


You are always going to get the same scaling laws in model size regardless of what else you do, so the same degree of improvement seen now relative to the smaller models will be achievable in the future. Yes, small models may be on par with previous generation large models, but the same is true for processors and you don't see supercomputers going away. It's the same principle.


who?


"So basically", what a weird conclusion to take out of it, just don't pay with your credit card for services you can pay cash or crypto.


Sorry, perhaps the takeaway is clearer when you see the full quote [0]. I omitted it for space, here's the relevant part

> Third, let's talk about what was actually disclosed. No emails were handed over. No message content. No metadata about who the user communicated with. The only information Proton could provide [...]

Yes, paying by crypto prevents Proton from disclosing your identity that way. Is there anything preventing Proton from disclosing the email content or metadata? Do they claim they won't disclose that? Clearly they do allow themselves to disclose metadata [1]

> For example, in ransomware cases, we can preserve information about which victims contacted the suspect, so that victims can be notified.

So, "just don't pay with a credit card" comes with the additional caveat of "don't email somebody you don't want the FBI to know you emailed". Whether you also need to "don't write anything you don't want the FBI to know", I haven't investigated further, but you could perhaps look that up yourself. I will just assume that to be the case based on what I've seen.

[0] https://www.reddit.com/r/privacy/comments/1rltej7/comment/o8... [1] https://proton.me/legal/law-enforcement


There are limits of what you can encrypt, in all of the cases of proton being critiqued for its compliance with law I haven't seen any instance of them being able to disclose email content, where metadata is "who we're sending email to", which is, I assume, not encryptable if you want an usable service. That being said, the quote does make your pov clearer, thank you for that.


> Is there anything preventing Proton from disclosing the email content or metadata?

Mmh.. The fact that it is encrypted client-side ? I mean the code is open-source fgs. [0][1][2]

[0]https://github.com/ProtonMail/android-mail [1]https://github.com/ProtonMail/ios-mail [3]https://github.com/ProtonMail/WebClients


Yeah, if you trust that they will never push a backdoor to your client on the request of Swiss law enforcement. It's a web app "fgs".

They also admit to scanning all mail to and from non-Proton accounts "for spam". So what's stopping them from one day adding a small if statement that just writes that data to disk, for specific "interesting" users?

Regarding metadata, I sure hope you have nothing to hide in the below emphasized:

> Account Activity: Due to limitations of the SMTP protocol, we have access to the following email metadata: *sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times*. We do NOT have access to encrypted message content, but unencrypted messages sent from external providers to your Account, or from Proton Mail to external unencrypted email services, are scanned for spam and viruses to pursue the legitimate interest of protecting the integrity of our Services and users. Such inbound messages are scanned for spam in memory, and then encrypted and written to disk. We do not possess the technical ability to scan the content of the messages after they have been encrypted. We also have access to the following records of Account activity: number of messages sent, amount of storage space used, total number of messages, last login time. User data is never used for advertising purposes.



Please quote where in that document the answer to my question is:

> Is there anything preventing Proton from disclosing the email content or metadata?

Also please link me to the source code of Proton's server-side code, so I can audit their scanning of all incoming and outgoing mail, to verify it's not logging them. What you linked above is just the clients.


that's why they have independent audits.


can you expand on the "loads" part? ip and payment option?


Keyword is "like": a service like Proton. No idea if and what data they have offered to their government. I was merely trying to offer an explanation to the parent commenter, who was wondering how people can critique pricacy-focused services offering data when required by law.


Fair enough, I agree. In Proton case, I'm biased because I used to work there ~2019-2022 and the company was basically printing money from subscriptions alone (covid likely helped with that), while fighting (pretty successfully) every request to avoid providing even that limited metadata, because alternative of ruining your core strength - privacy - meant the death of the business. I don't know if anything changed, but I'd bet the goals remain largely the same - providing good-enough privacy any commercial company can realistically give you. Unencrypted user data in this business is poison, and they're well aware fwiw.


But don't they have both the encrypted data and the decryption keys? I don't remember giving them my keys to use, and I can look at my stuff from multiple devices so the keys aren't stored on my device.

So they must have the ability to look at all that encrypted data anyway?


Did you not notice that you have to type in a password?


your password is your key, you can check networking to see if it is being sent in raw text or not.


You seem to be hiding behind this "like" while writing into comments about Proton - making accusations and theories that imply it's Proton that actually does that.


find your level -> answer D to everything -> you're a beginner! And I thought I have high standards...


can you elaborate on "easy to read and debug", because in my experience it is anything but


Compared to a random tool someone vibecoded?


what about a random bash script that somebody vibe coded


just use 200usd plan, I forgot what limits are.


Do you hit the limit pretty quickly on the Pro plan these days? Im thinking about subscribing for video editing, but Im still not sure.


You'll remember it soon


Do you often hit the limits recently on the $200 plan? I don't even come close


I didn’t often hit the limits with the plus plan but it changed.

They same will happen with $200 plan.

But the $500 plan will fix that


i used to, its much better now. opus 4.6 has been great on tokens


Yes, quite a while back, they used to charge a lot more for the Opus tokens


Have not hit limits for 2 months now and I use it a lot. I have 200 max as well.



Not sure what's the point of it being so fast and so small if it's also wrong.


what's the point of black and white statements that are wrong for a major subset of problems that the tool set out to solve?


And what's the point of being right when it's slow and bloated? Come on, it works for a lot of use cases, and it doesn't work for some. And it's still evolving.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: