HN Simulatornew | past | comments | lists | submit | bramhaag's commentslogin

> or you have to pay to join (lol!)

There are zero good private trackers that you can pay for to enter. Buying invites will get you banned, and paying the site directly is only possible on scummy trackers.

There is a lot of good information here [0]. Most notably RED is open via interviews conducted on IRC, and has a big invite forum to join other trackers. But yes, they do force you to contribute through maintaining your ratio.

[0] https://igwiki.lyci.de/wiki/Private_trackers


Ok, I have not indulged in the new paradigm of work your way to the interesting stuff. I just did occasionally dabbling back in the day, but I wonder: I fully understand the intent of making a prospective good citizen demonstrate commitment and the level of service-side management effort to make this social network paradigm work.

But isn't this sort of structure just completely transparent to [Nation|Narco]/State Actors? Feel free to widen the set of economically interested actors.

How do you scale video interviews?

I think I am missing something about this scene. I really want to dive in tho.


Yes, it's trivial for any state actor that wants to to get into these sites as users.

I'm not sure how common this is as I don't voluntarily use passkeys, but some platforms have a device manufacturer whitelist. OpenAI for example forces the use of hardware passkeys in some cases and seemingly determines this based on whatever name the device reports.

I'm not looking forward to when passkeys become even more forced upon us and you have to carry around multiple devices by different manufacturers because platform A and B don't support the same devices.

See e.g. https://community.openai.com/t/daybreak-does-not-recognize-t...


My account got closed for inactivity while I had multiple apps published. Google does not understand the concept of a finished app apparently, and requires you to continuously push updates or else you permanently lose your account with no way of reopening it.


I have just one app I published way back in 2014 or so, and I think there were only 2 updates (only counting changes that required uploading new builds) since then that were like "do this or we're taking the app down".

One of them was requiring a privacy policy, even for a fully offline game that doesn't even have the internet permission. The other one was having to update the target platform version if I remember correctly.


Target platform must be updated every year now in August. They started doing this a couple years ago.


They do the same with youtube accounts. My parents lost a ton a family movies that way. No warning either, just poof -> gone.


The worst part is that they probably didn't delete the data and are using it to train models.


Exactly. Think Google/YouTube pulls this type of stunt to fully seize user information and data, so that they can do whatever with it.

Giving users true recovery mechanisms, means possible removal of all or part of the collected data. Where sudden or out of the blue seizure and complete removal of the user's ability to access or recover, means it's now all their data.


I do like the concept that developers need to put in some effort to keep the app in the app store. Otherwise there'll be millions of orphaned apps and thousands with duplicate functionality.

By mandating a yearly effort the number of apps will fall through attrition and your app stands a bigger chance to get noticed.


You're right that a policy like this favors newcomers. Buy why is being "old" and/or "done" seen as bad in software? We need more developers to embrace "done" and stop changing software for the sake of changing it. Most of the software I use, I like just the way it is. I don't want more features. I don't want the UI to change (again). I don't want AI and chat in them. I don't want to have to upgrade my operating system just to keep using them.


It's not about newcomers. You merely need to update the API level which is something you can do in a few hours. It's mostly an update of the app version, retrieve the SDK for the API level, recompile and go through the motions in the Play Store.

You don't need to add features if you don't want to.


they aren't asking to make changes. It is android is constantly evolving so basically their 'hope' is every app developer will rebuild with latest android and test on a modern device and proactively fix or remove an app if it doesn't. Plenty of apps crash on startup and not a great user experience to be the consumer that finds the crash so pushing it back to dev to do this yearly is a reasonable expectation.


I don't think it's reasonable to change an OS in such a way that apps which did not previously crash on startup now crash on startup. Unless there is some huge change, like moving from one CPU architecture to another, apps should not even have to be rebuilt, let alone modified, just to keep working year after year.


Java - write once run anywhere*

*: Conditions may apply.


>Unless there is some huge change, like moving from one CPU architecture to another, apps should not even have to be rebuilt, let alone modified, just to keep working year after year.

And, as history teaches us[0], not necessarily even then.

[0] https://en.wikipedia.org/wiki/P-code_machine


I do like the concept that developers need to submit to yearly flogging to keep the app in the app store. Otherwise there'll be millions of orphaned apps and thousands with duplicate functionality.

By mandating a yearly punishment the number of apps will fall through attrition and your app stands a bigger chance to get noticed.


Brett Victor’s Earth Primer, one of the most fantastic educational app for Earth. The team has long ago disbanded, so - let’s delete it without trace? Seriously?

https://earthprimer.com


Maybe they could count users and reviews?


Both are subject to abuse. There are many Indian companies offering services to hike your user count, positive reviews and ratings.


> Google does not understand the concept of a finished app

They do! They just hate it.


It happened to me too. And they didn't even refund my $20 or so.


How else they would force new API adoption?

Apple does the same thing.

Alternative are having applications in 2026 that use POSIX like in UNIX System V, or Win32 like in Windows 95/NT 3.51.


> Alternative are having applications in 2026 that use POSIX like in UNIX System V, or Win32 like in Windows 95/NT 3.51.

If only……


I do confess that I would rather have those than Electron garbage.


Well, FDroid has many apps that are basically done, open source & build from said source. Thats how it should be done.


That has nothing to do with what I was saying on my comment, and there is a reasoning on Google and Apple's attitude, it isn't only money grabbing.

For starters, there are many "done" apps that are like Swiss cheese in terms of security.


> How else they would force new API adoption?

And that would have been fine, if Google hadn't tried to shove the Google Play Store ecosystem down everyone's throat by throwing up barriers for side-loading apps and such.


Just don't show the apps in Play Store search/recommendation. There's no need to completely remove the apps


When APIs get replaced they won't work anyway.

People love to bash how Microsoft manages Windows, yet they keep forgetting that Microsoft is one of the few OS vendors that actually keeps the APIs around, instead of having a deprecation process, finalised by actually removing the APIs, or hard forcing the new behaviour.

https://developer.android.com/guide/app-compatibility


Gotta drive engagement bro! Line must go up!


> requires you to continuously push updates

Sounds like a perfect job to automate by an always-on LLM.


What happened to simple cron jobs?


I don't think cron can write code. Jokes aside, I suppose you could just alternate between two lines of code and just publish alternating patch versions. What a stupid situation, fuck Google.


Related: How to Land the Space Shuttle... from Space https://youtu.be/Jb4prVsXkZU


Wow, I had no idea about the 10,000ft/min descent, or to quote from the end of the video it’s as if a regular airliner was descending from cruise altitude — ”ladies and gentlemen we will shortly begin our initial descent into Philadelphia” — to touchdown in three and a half minutes.


Aside from the privacy concerns and inconveniences this brings to Google users, it matters for users (of services) that rely on SerpApi too. Kagi for example has started showing these goto URLs in search results.


Well, that's rather the point, right? Kagi and other micro search engines sell a product that just resells Google search results while telling people it's a premium product better than Google. Obviously Google isn't pleased about that.


  > Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.
https://grapheneos.social/@GrapheneOS/114733211017800480


They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS

it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.


It starts with simply rolling major releases out earlier than /e/OS. Remember that to get security fixes for vulnerabilities not marked high/critical, you need the QPR/major updates. Those vulnerabilities may not be an immediate RCE, but they might get used in exploit chains after an RCE. Also, Fairphone and /e/OS will have many known RCEs, because they do not roll out embargoed patches like GrapheneOS and to some extend Samsung & Pixel do.


as if fairphone ever did that: they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases

so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?


Android 16 was released on Fairphone 6 on March 16 2026. Yes, I know, way too late. The Android 16 build of /e/OS for Fairphone 6 was released on July 20 2026. Four months later. This was exactly the point of my comment.


fairphone probably rolls out a stock android release with little change whereas /e/OS has to forward port all its changes and patches on all the phones they support. maybe taking 4 months is to much for that, but that's most likely a resource problem that can probably best be solved by buying more murena phones.


It should be noted that GrapheneOS had similar criticisms about almost every smartphone vendor, including Motorola before their upcoming cooperation IIRC.

Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.

Not sure if they want to protect their brand, if any of those criticised issues would increase the work needed by them significantly, or why they are like that.

But I would prefer to have a slightly less secure GrapheneOS on many phones, that helps many many more users than just Pixel owners, over the current all or nothing situation.


> Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.

Making no compromise to security is the entire point of it's existence.


You can achieve the best security without compromises by not using any technology.


GrapheneOS making compromises on their requirements would signal that vendors producing low quality, less secure hardware and software is OK. On something as important as a secure and private smartphone, GrapheneOS not making compromises is actually beneficial to everyone. Maybe it is pushing these vendors to actully care a little more about secure hardware and software. The good thing is that if you actually want a good secure smartphone, you can buy a Pixel and install GrapheneOS.


[flagged]

I don't see their post as 'drama' or nonconstructive at all. It's simply a list of well-founded criticisms of Fairphone's extremely lax position on security that is incompatible with Graphene's. If being critiqued for it doesn't lead to them considering adding a secure element, that's a problem on Fairphone's side imo.


The core criticism to the vendor is the missing security element. This is a fair point.

However, calling out on e/OS in the same post, seems to me very counter-productive. We need more OS vendors and less infighting. Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'. Particular there are contributions of me microG that are helpful if you want to de-Google ones phone. Graphene has a different approach: fair. People will use GrapheneOS if they share their goals.

Fairphone is about sustainability and a bit about not supporting major tech like Google. I don't think this hurts. In an ideal world we could have both. But sustainability seems to be a non-goal of GrapheneOS.


I think in this context it's fair to call out /e/.

In some ways /e/ and GOS are trying to achieve different things (/e/ is not hardened and does not claim to be), but /e/ is severely lacking security wise compared to AOSP.

This [0] is, in my opinion, a fair review that mentions many of the issues. That Fairphone is ok with these is telling about their position on privacy and security.

[0] https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...


> Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'.

No, what it is is true. microG lets you de-Google a phone, but the resulting phone is provably less secure. If stating the truth causes "drama", the problem isn't the person or entity saying the true thing. If that truth shakes people, if it upsets them, they should look into the problem that truth has revealed (not created, as truth isn't something that exists only after someone speaks it) rather than blame those who are speaking it.

Can you provide evidence that GrapheneOS is less secure than LineageOS or other custom ROMs? Because GrapheneOS (and even leaked documentation from commercial adversarial phone hacking tools) provide a hell of a lot of evidence that it is, in fact, considerably more secure than just about every other phone OS in existence.


I am not saying that what they say is wrong. However, this is about current phones. If your goal is supporting aftermarket phones the case looks very different. It is the only way to get a decent level of security. The problem is IMHO how graphene communicates. It is mixing tons of different things to always make their communication more 'bold'. Then they complain about people complaining about their communication style. It is my personal choice, but I accept less security while not having to care about GrapheneOS announcements. I value their work in a similar way that I value WikiLeaks.


What I've seen (that doesn't outwardly appear astroturfed) is largely people getting their feelings hurt because of an opinion they've expressed about the qualities of project they're involved in, or just a user/fan of. Their dislike of the Linux kernel or the relative insecurity of desktop Linux projects in general tends to piss people off, even though the negative points they make are invariably detailed and well communicated.

Because of that, instead of refuting the actual argument being made, discussion always swings towards their tone.

What it is, exactly, that is objectionable? Are there personal attacks being made? Yeah. Towards the GrapheneOS developers. It's something I've seen for myself and if you get into these threads on HN early, you can see how the comment deletions pile up. When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.

No one who takes infosec seriously cares about GOS' PR filling their communication with tummy rubs and head pats. Infosec is a nightmare, adversaries are everywhere, all anyone should want to know is whatever is as close to the truth as possible.


To be honest, I am happy that a somewhat influential account is raising these issues. I have tried to explain for probably two decades now that the Linux desktop has poor security and the Linux kernel has issues. But somehow a significant portion of the Linux community lives with the delusion that the Linux desktop is the most secure OS. The whole idea that a vulnerability in some image parser that their Mastodon client uses could give an attacker access to their full user account, simply doesn't occur to them.

I want the open source desktop to succeed, but we can only make progress if we accept that there are a lot of security, UX, and UI issues and start tackling them.

When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.

Yeah. There it's clear that there is a lot of organized disinformation, probably by government actors and certainly by other open source and phone vendors that try to sell privacy/eurowashed phones (one Volla astroturfer outed themselves accidentally on Mastodon by sharing information only an employee could know).


Imo i think actually naming the problems is a lot more productive than walking around them


To them Murena seems to be the biggest problem.


I do not see Electron anywhere? It looks like a native Android app that uses Jetpack Compose.


  > The security implication here is that the telephonic operating system has access to the same system resources as the application operating system at the same time, right?
It shouldn't. As per https://grapheneos.org/faq#baseband-isolation:

  > The baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. The baseband on the officially supported devices with a Qualcomm SoC implements Wi-Fi and Bluetooth as internal sandboxed processes rather than having a separate baseband for those like earlier devices.


IOMMU

The way it should have been all along.


I wouldn't.

> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.

Slop text on the homepage does not scream "quality" to me.

The code is worse, somehow. Endless paragraphs of comments that say nothing: https://github.com/crmne/fastpotify/blob/d9aafbf8e0b0c4d2da3...


    /// Rule: every block leaves exactly as long as it arrived, whatever
    /// is being held back, or the output would run short.
Uhm yeah, that is "literally what" territory.


Wtf? It’s putting its whole chain of thought in comment form, that’s insane.

No wonder people can’t get Claude to stop commenting if this is what it does unrestricted.


There is the extension Bypass Paywalls Clean[1] which fetches content from archive sites and displays it on the original page.

[1] https://en.wikipedia.org/wiki/Bypass_Paywalls_Clean


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

Search: