[HN Gopher] FSF announces Librephone project
___________________________________________________________________
FSF announces Librephone project
Author : g-b-r
Score : 1368 points
Date : 2025-10-14 23:47 UTC (23 hours ago)
(HTM) web link (www.fsf.org)
(TXT) w3m dump (www.fsf.org)
| Terr_ wrote:
| This seems pretty relevant on the heels of yesterday's popular
| discussion on how "Free software Hasn't Won" [0] in terms of
| tools available to the average consumer.
|
| Just because _pieces_ are open-source (or "free software")
| doesn't mean the _autonomy and capabilities_ we want are
| necessarily present in the overall system.
|
| [0] https://news.ycombinator.com/item?id=45562286
| le-mark wrote:
| > Practically, Librephone aims to close the last gaps between
| existing distributions of the Android operating system and
| software freedom. The FSF has hired experienced developer Rob
| Savoye (DejaGNU, Gnash, OpenStreetMap, and more) to lead the
| technical project. He is currently investigating the state of
| device firmware and binary blobs in other mobile phone freedom
| projects, prioritizing the free software work done by the not
| entirely free software mobile phone operating system LineageOS.
|
| The time is right for this project I hope they succeed.
| monero-xmr wrote:
| If rich techies on this website want to support something
| worthwhile, here you go
| lostmsu wrote:
| Not rich but is there a way to contribute specifically to
| this project? The donate button on the website does not work.
| tjr wrote:
| I would have expected an online means to contribute
| specifically to Librephone, but indeed, seems like nothing
| yet. Hopefully it is forthcoming.
|
| Otherwise, their website suggests you can specify a
| particular project via the memo line of a check:
|
| https://www.fsf.org/about/ways-to-donate/
| r283492 wrote:
| As the first project FSF has launched in years with a
| current budget of one developer I expect they will be happy
| to spend new donations on further funding for it. However,
| it is very uncommon for a nonprofit to have a separate fund
| for a project that is part of the organization itself,
| rather than a project which makes semi-independent
| decisions and is fiscally sponsored by a related nonprofit.
| The exception is usually when some very large donor which
| insists on that arrangement.
| trenchpilgrim wrote:
| I was talking to someone who is involved in a nature
| conservation nonprofit recently - small donations go into
| the general pot of money for the organization to choose
| how to spend it. If you want to influence what the money
| is used for you have to donate a significantly higher
| sum. They said they like having many small donors because
| they can fund things that don't necessarily make a big
| splash in a press release but are important precursors to
| impact (e.g. researching what projects would have the
| most impact vs actually implementing a project).
| wltr wrote:
| Upon commenting, I removed the snarky part of the website
| being visually... well, bad. After all, FSF isn't about
| design and aesthetics, right? But donate button not working
| demonstrates the whole seriousness of the effort.
| frogperson wrote:
| Indeed, this is the right time. I really want to daily drive a
| linux phone, but i dont want to buy a used phone. I hope this
| brings more hardware support for newer phones.
|
| I'm willing to suffer a rough beta or alpha experience, but let
| me use modern hardware of my choice.
| BLKNSLVR wrote:
| Why not used?
|
| I'm kinda the opposite, I don't want to buy new any more.
| Currently rocking a 2nd hand Pixel 7a running GrapheneOS and
| loving it.
|
| If battery life is the issue, that's fair enough. I've bought
| a couple of wireless charging docks that I spread around the
| places I frequently spend my time, so if it needs a boost I
| can charge her up just by plonking it on the dock. Most of
| the time, though, she makes it through the day from (maximum
| charge for battery longevity reasons) 80% down to 30%, maybe
| 25% or 20% if there's lots of interesting news in a day.
|
| But I'm not a particularly heavy user and I don't game on it.
| criddell wrote:
| The time is right, but I still don't think this project can
| accomplish much because people are generally happy with their
| phones.
|
| That said, the phone market is huge. They could sell enough
| devices to fund future development which might be good enough
| even if it doesn't slow down Apple or Google. At least then
| there will be a device for those of us who are not happy with
| the state of things.
| jMyles wrote:
| > The time is right, but I still don't think this project can
| accomplish much because people are generally happy with their
| phones.
|
| Is there survey data available on this? Anecdotally,
| everybody I know hates their phones. In fact, I think if you
| asked, "what's the biggest pain point in your life right
| now?" I think most people will point to their phones.
| scuff3d wrote:
| Maybe, but that pain point isn't something free software is
| going to fix. Obviously not everyone has the same problems
| with their phone, but largely I think they fall into a few
| categories: notification overload, apps designed to keep
| you scrolling for every last minute of the day, and dark
| patterns or other design choices aimed at separating users
| from as much of their money as possible.
|
| Every single one of these is fixable on any modern phone.
| Stop using social media, take a hatchet to what apps can
| send you notifications and when, and be more mindful of
| what tricks are commonly deployed to steal your attention,
| time, and money.
|
| But people can't even manage that. They don't even have to
| _do_ anything, they just have to _stop doing_ certain
| things, but they can 't or won't. Those same people aren't
| going to go through the effort to switch, and even if they
| did they would end up re-creating the same thing that makes
| them miserable currently.
| mike_d wrote:
| You might need to expand your social circle a bit.
|
| If you asked normal average people "what's the biggest pain
| point in your life right now?" they would point to
| financial, societal, or health issues.
|
| The vast majority of people when asked specifically about
| their phones probably wish that they were a newer model or
| had a longer battery life. As long as it communicates with
| people, lets them access banking and social media, and has
| a few of their niche hobby/entertainment apps nobody
| actually cares about the licensing of the modem firmware or
| the fact you can't install TempleOS on it.
| wraptile wrote:
| > because people are generally happy with their phones.
|
| Maybe thats exactly why it can succeed now. The phone tech
| has plateud to the point where a 5 year old phone performs
| almost identically as a new one and this is when people can
| afford to experiment and take more risks.
|
| Also its much easier for free software to catch up now as
| most problems are already solved and/or easy to copy.
| SV_BubbleTime wrote:
| > much because people are generally happy with their phones.
|
| Talked to many iPhone owners this year? The 17 hardware has a
| bizarre choice of a camera button / pointless physical
| change, and IOS 26 is pretty much hated by everyone.
|
| I use iPhone, and have happily for years but F if this isn't
| the worst OS I can remember. The first downgrade really.
| NetMageSCW wrote:
| Your "everyone" seems to be substituting for "me" an awful
| lot.
| moi2388 wrote:
| I like the action button and have no issues whatsoever with
| iOS 26.
| wltr wrote:
| Have you been around when iOS 7 was released? If not, I'd
| say that was the same, whatever that means. Things might
| get better, but we're not entitled to it.
| mike_d wrote:
| I think they will fail because they fundamentally don't
| understand the problem.
|
| Android does not contain binary blobs because of some evil
| conspiracy against free software. If they could get away with
| it, the whole damn thing would be open source.
|
| The problem is those blobs do things that interact with
| complex hardware for which only blobs are available. Even if
| you reverse engineer them, you are going to get sued into
| oblivion because of the patents you are going to need to
| infringe on to make functional replacements.
|
| But even if you get a blessing from the component
| manufacturers, your new hippie binary blobs need to be
| certified to legally operate on cellular and wifi frequencies
| in most parts of the world. If you decide you don't like
| something and change it - as is the open source way - that
| new version with your modifications needs to be certified
| too. Carriers do not allow uncertified devices on their
| networks.
| onli wrote:
| No one is going sue the fsf into oblivion. The movement has
| decades of legal experience, if a company would be dumb
| enough that company would just burn money and lose.
| Especially about reverse engineering software, as if
| patents had any power there. Apple, the end boss in that
| regard, not fighting on that level against the m1 project
| is proof enough.
|
| Second, fuck the carriers. Certifications will not persist
| as soon as real Foss phones are available. Nothing persists
| against a world of free hardware invading a realm. And even
| if: freeing everything around a modem blob would still be a
| big step forward.
|
| It's frankly ridiculous to assume the people working on
| this and the organisation that already supported replicant
| knowns nothing about the mobile space.
| mike_d wrote:
| I understand it might seem confusing if you are not
| familiar with the requirements, but they are not trivial
| to bypass.
|
| Cell phones operate in licensed radio spectrum, so they
| need to have proper testing and certification
| (https://www.fcc.gov/oet/ea/rfdevice). Any device not
| properly certified would be illegal to manufacture or
| import into the US.
|
| Separately cellular networks require PTCRB certification
| of the devices to ensure they are interoperable with the
| network (https://www.ptcrb.com/). The FSF could in theory
| write custom firmware for baseband and wifi chips, but
| they would need to seek certification as this would be
| considered a substantial modification. It would likely
| require cooperation from the chip manufactures to provide
| samples with various testing/debugging harnesses enabled.
|
| Qualcomm and the like would probably sue to stop the FSF
| on the basis that it could put their own device
| certifications into jeopardy.
|
| That isn't even touching on non-transmitting components
| like GPUs or sensors where the actual functional logic
| may be split between hardware and software (your blob
| driver). Even by doing a clean room reimplementation, you
| risk infringing on software patents, and will have little
| flexibility to work around them since the hardware will
| expect things to be done a specific way.
|
| You would think it would be ridiculous to assume the
| people working on this know nothing about the mobile
| space, yet their actions do bring that into question.
| zevon wrote:
| I think all your concerns are valid but they are not
| necessarily insurmountable. The FSF or whatever other
| entity could do just what you suggest and seek
| certification within the current legal frameworks. They
| could also talk to the carriers and negotiate
| individually which is probably going to be quite annoying
| and slow but it's not impossible and it's not like that's
| not done in the commercial space. The could build
| mechanisms into the hard-/firmware that takes your device
| off whatever regulated spectrum/provider if you modify
| anything that is in regulated territory (as watched over
| by some form of maintainer-quorum-signing-negotiation-
| structure). I'm sure there are many mechanisms and
| processes one could come up with that could keep with
| regulatory or other control aspects while still keeping
| things open.
|
| All that patent and legal business is probably a more
| important/existential concern and a go/nogo-factor if you
| want to be a commercial player in a market-driven
| environment and less so for an entity like the FSF.
| m4rtink wrote:
| The blobs are there to assure you need to throw away your
| perfectly fine phone every 3 years due to lack of software
| updates.
|
| If it all was open source, the community could quite easily
| provide updates - you can run a modern Linux distro on 10+
| years old laptop just fine.
| CivBase wrote:
| > If they could get away with it, the whole damn thing
| would be open source.
|
| Who is "they"? Certainly not Google. Google has been moving
| open-source Android functionality into the closed-source
| Google Play Services for many years.
| k_bx wrote:
| I don't mind having a second phone, esp. if it's a foldable
| which can be a great reader and a small "linux in a pocket".
| There might even be some use-cases, for example I recently
| wanted to implement a type-c external GPS antenna, and found
| out that it's a pain on Android (done via "developer mode"
| hacks etc.), and impossible on iOS.
|
| That being said, very low expectations on this project.
| barnabee wrote:
| The project will accomplish much if _those who want it_ have
| better choices, even if they're not perfect.
|
| They don't need to replace or even challenge Apple and Google
| for market adoption, just be there and be a viable
| alternative used by a noticeable minority of people.
|
| Getting half as far as desktop linux would be a fantastic
| achievement.
| bigstrat2003 wrote:
| Ultimately, I don't think the most important challenge is in
| binary firmware blobs, but the software which people depend upon
| to run their lives. What does it matter if you can run a
| completely free software stack on your phone, if your bank
| software (or your required government ID, as is looking
| depressingly likely) requires you to run a Big Tech approved
| phone OS? Perhaps the FSF can't do much about that, but that is
| where I feel they could truly make the biggest difference for
| freedom for the average user.
| endgame wrote:
| It becomes much harder to force attestation on people if
| there's a significant user base that runs alternative operating
| systems.
| bombcar wrote:
| Do you really NEED to be forced to attest if you can make
| your phone look like any damn PC using a browser?
| kube-system wrote:
| I can't tap my PC to buy a burrito at Chipotle.
| ray_v wrote:
| This sounds like a challenge to me.
| bitmasher9 wrote:
| It's actually super easy and not a challenge. The lowest
| tech way to do it would be the tape a cc with tap
| functionality to the inside of a laptop.
| hn_user82179 wrote:
| what a phenomenal comment, thank you for the laugh
| bombcar wrote:
| I took "tap to pay" being clicking on Order in an app;
| and I have _certainly_ made a "online order" from inside
| the Chipotle, on their wifi with my laptop (usually
| because walking to the counter would cost _more_ because
| of stupid promotions).
|
| It makes more sense that they're referring to Apple Pay
| or similar shenanigans (which itself is more annoying
| than a credit card, to be honest, Face ID goes wrong or
| the double click closes the wallet app instead of
| authenticating way too many times, especially if you're
| trying to do it one-handed).
| hdseggbj wrote:
| So you pay more money and also give up your privacy for
| what you could pay cash for. I don't think you're the
| target market for this phone.
| kube-system wrote:
| I pay less money for my burrito than I would with cash,
| but the reason I use my phone is convenience, not cost.
|
| > I don't think you're the target market for this phone.
|
| My comment is downstream of the entertaining of a
| possibility of:
|
| > a significant user base that runs alternative operating
| systems
|
| ... which isn't going to happen if you ask your users to
| give up commonly used features. It will forever be a
| niche project, at best.
| hdseggbj wrote:
| And there are still folks who don't use ad blockers.
| drnick1 wrote:
| You seem to be part of the problem. As long as people
| like you are happy to run spyware on their phones for the
| sake of convenience or a meager discount, companies will
| be empowered to make such software and devices a
| requirement.
| austhrow743 wrote:
| Do you think the same for using credit cards in general
| or is using the phone somehow worse?
| drnick1 wrote:
| I use cash whenever possible, but carrying cash for
| larger transactions has its own risks and those risks
| need to be balanced against the privacy benefits it
| offers. The way I see it, carrying a credit card in
| addition to my phone when I might need it is a minor
| inconvenience relative to that of allowing Google
| complete control over my phone.
| bombcar wrote:
| Credit cards have become mainly a way for the banks and
| visa/mc to use the customer to strong arm money out of
| the business.
|
| Get 3% and rebate some to the customer. For the
| convenience.
|
| It's kind of sad, really.
| NoGravitas wrote:
| I can tap my debit card to buy a burrito, no apps
| required on my end.
| jojobas wrote:
| Some banks require app confirmation for PC-initiated
| transactions, using play integrity requiring apps. Cause
| security, you know.
| SchemaLoad wrote:
| It's because it's way easier to install malware on PC
| than mobile. None of us are immune either. In recent
| times there has been malware distributed by common NPM
| packages as well as game mods. Every NPM package you
| install has the ability to steal your browser session
| tokens and the only thing stopping the attacker from
| actually logging in and spending your money is the fact
| it has to be confirmed on your phone.
| jojobas wrote:
| Choosing between a risk of that and preinstalled non-
| removable malware in every phone? Tough one, I know.
| array_key_first wrote:
| That doesn't require a bank approved app - we already
| have authentication mechanisms that are standardized.
|
| People do proprietary bullshit because they want to do
| proprietary bullshit. Anything else is made up.
| koolala wrote:
| What kind of transactions require this? Normal bank
| transactions don't, right?
| brewdad wrote:
| My brokerages require it every time I login from a
| computer. My bank will require it if it can't find a
| cookie from a previous login session. Occasionally, my
| bank will require it seemingly randomly since I usually
| log in at least once a week from my laptop yet every
| couple of months or so I have to reconfirm on the app or
| another secondary method.
| koolala wrote:
| What are the other secondary methods?
| jojobas wrote:
| Transfer of more than a set amount between even your own
| accounts in different banks.
| koolala wrote:
| Between your own accounts is the main use-case because
| you typically can't transfer between different banks.
| lmm wrote:
| > you typically can't transfer between different banks
|
| WTF? What kind of shitty banking system are you using?
| koolala wrote:
| Wells Fargo said to do it I had to use Zelle.
| lmm wrote:
| Wow. You guys really need better banking regulation.
| immibis wrote:
| AFAIK Zelle is something US banks got together and set up
| on their own because the government didn't. So a Zelle
| transfer is the US equivalent of a SEPA transfer.
| lmm wrote:
| Depends on the bank's policies. Currently it tends to be
| when you transfer to a new destination and/or above a
| certain amount. I could certainly imagine a bank
| requiring it for every PC-initiated transaction as and
| when they reach a point where most normie customers are
| using their app.
| koolala wrote:
| "Every PC-initiated transaction" doesn't make sense to
| me. What type are transactions are you talking about?
| lmm wrote:
| > What type are transactions are you talking about?
|
| Bank transfers and I guess direct debit authorisations
| (if your bank requires you to confirm those) and
| reauthorisation/confirmation of card payments that were
| blocked by the bank's fraud detection. I think those are
| the only kinds of transactions one would ever use a PC
| for? I mean for me most of my day-to-day transactions are
| me paying by debit card in a shop, but you can't do that
| on a PC in the first place; pretty much everything else I
| do on my PC.
| koolala wrote:
| Do you have to authorize those day-to-day transactions
| with your debit card on your phone every time?
| lmm wrote:
| No. Only to unblock when they get blocked/flagged as
| fraud (tends to happen for large transactions like plane
| tickets or buying a bunch of furniture), and even then I
| currently have the option of authorizing via the web
| browser (and I think also via phone call).
|
| But sending a bank transfer is also a fairly common day-
| to-day transaction that I do a couple of times a month
| (and is the only way to pay for some government services
| like tax certificates short of visiting the tax office in
| person). Authorising a new direct debit happens
| occasionally (joined a gym, changed my utility provider,
| got a new credit card, that kind of thing).
| degamad wrote:
| Fraud prevention on my primary transaction account
| requires 2FA for every transfer.
|
| The only supported 2FA is the bank's own dedicated 2FA
| app.
| koolala wrote:
| So if you buy something on Amazon with your debit card
| you have to authorize it?
| drnick1 wrote:
| I think it's time to look for a new bank.
| dotancohen wrote:
| In my country we have a large religious community that
| eschews smartphones. Due to this no company or government
| agency requires a smartphone for service.
| drnick1 wrote:
| This is a very good thing. I don't think many people here
| on HN reject technology, but sometimes no technology is
| better than one that is not controlled by the user.
| veber-alex wrote:
| No it isn't.
|
| They just use an SMS code instead which is not secure at
| all.
| bandie91 wrote:
| choosing a wrong alternative does not make mandating
| spyphones good.
|
| why not distribute hw tokens for purposes like this? it
| has the least flaws IMO.
| bandie91 wrote:
| would you mind reveal which community and country is
| this? maybe i can ask them to lobby in my area too...
| SchemaLoad wrote:
| These days browsers are becoming increasingly distrusted.
| My bank logs my browser out after 30 minutes inactivity and
| then to log back in I have to confirm the login on my
| phone.
| SoftTalker wrote:
| This seems desirable? Is your phone the _only_ 2FA
| available?
| kennywinker wrote:
| That... seems reasonable? My bank does that with their
| website and their mobile app. I was able to setup 2fa
| using a totp app, so i don't rely on sms for that part
| SchemaLoad wrote:
| It is given the environment. But it does highlight the
| poor security of desktop browsers where they are only
| trusted to do anything when a phone app approves it.
| While the phone app is considered secure enough to just
| stay logged in perpetually without any external
| confirmation.
|
| To hack the banks app you have to find an exploit in iOS
| or Android which would allow you to read the other apps
| private storage, which is borderline impossible now. To
| hack the banks website you just have to buy some random
| browser extension and add malware to it, or break into
| someones NPM account and distribute it there, or any
| number of ways to run code on someone else's computer.
| Something very achievable by an individual.
| thwarted wrote:
| > _But it does highlight the poor security of desktop
| browsers where they are only trusted to do anything when
| a phone app approves it._
|
| Does it? The browser doesn't do anything, the person
| sitting at the computer where the browser is running is
| what performs the actions. The reauthentication and 2fa
| is meant to authenticate and authorize the user, not the
| browser.
|
| The attack vector of someone else using your phone using
| an app that doesn't require (re)authentication is
| independent of the browser or the app itself being
| trusted. That your bank doesn't periodically require some
| kind of re-authentication for their app is a security
| hole, but because the device could fall into the wrong
| hands, not because the code/app/browser used to access it
| isn't trusted.
| SchemaLoad wrote:
| That is true. I guess one of the main differences is the
| bank app can run a faceid check when you open the app and
| before you make a transaction while websites don't have
| access to these apis. So they are forced to make you
| approve the action via your phone.
| thwarted wrote:
| Every banking phone app I've used auto-logouts after
| being idle or unused for a bit, and my primary bank's app
| requires 2fa using an app that exists on the same device
| -- a second factor that secures nothing. They probably
| are not explicitly considering the phone more secure than
| a computer, but rather a good 80% of this is security
| theater or a checkbox on some baseline security checklist
| that was implemented without really understanding what
| the implications, for usability and security, were going
| to be.
| kennywinker wrote:
| > 2fa using an app that exists on the same device -- a
| second factor that secures nothing
|
| If I steal your device, and you didn't have faceid, I
| have both factors. But if I steal your password, or find
| it in a leak of another site because like most people you
| re-use passwords, then I only have one factor. It still
| provides a fair bit of security because of that.
| vlz wrote:
| > 2fa using an app that exists on the same device -- a
| second factor that secures nothing
|
| 2FA on the same device secures against your login
| credentials becoming known to another party, e.g. by
| fishing, password reuse, database leaks, etc., which are
| real threats. It is not meant to protect against someone
| being in possession or full control of your unlocked
| device, which is of course also a real threat, though
| possibly less common.
| goodpoint wrote:
| It's not reasonable at all.
| kennywinker wrote:
| Could you elaborate on what part you find un-reasonable,
| and why?
| thwarted wrote:
| This isn't the browser not being trusted, it's access to
| the device the browser runs on. Forcing logout when idle,
| and authenticating again, is good in general to avoid
| leaving something accessible when walking away from it,
| even if it's a home computer that is otherwise "secured".
| ants_everywhere wrote:
| webauthn cares about the strength of the authenticators
| used. Mobile has standard libraries for biometrics and
| secure enclaves. This is less common on desktops and
| laptops. Your bank may offer the ability to enroll a
| yubikey or similar.
| wongarsu wrote:
| My bank doesn't let me do anything in the browser without
| 2FA, and the only 2FA they offer is their smartphone app.
|
| My other bank offers 2FA via chip reader as an alternative.
| I guess that's somewhat viable for an alternative phone OS,
| if you want to carry the reader around with you
|
| That might just be European banks though
| seba_dos1 wrote:
| That could be nice on the Librem 5 which has an
| integrated smartcard reader.
| pjmlp wrote:
| Websites are starting to make use of passkeys and TPM stuff
| on the device for workflows where money is involved.
| bigstrat2003 wrote:
| I agree, but unfortunately I think the chances of that are
| just about zero. The reality is that the vast, vast majority
| of people don't care about software freedom. They care about
| the flashy marketing features in the newest iPhone (and
| competitors). I wish it were otherwise, but alas. Heck, you
| can't even get people to care about their _physical_ freedom
| most of the time, let alone their digital life. It 's hard to
| see this effort taking off as a result.
| inatreecrown2 wrote:
| you have to start somewhere, and with Goggle closing Android to
| non-approved apps this seems like the right move.
| koolala wrote:
| In an emergency, can't you call your bank over the phone? Do
| you depend on it still if you have a Computer?
| monero-xmr wrote:
| Most importantly is to continue supporting web browser access
| and open web protocols. Then anyone with a web browser and
| device can use all the apps.
| userbinator wrote:
| Actually "open" is a misnomer, maybe it was a decade ago but
| it's clear that Big G has an effective monopoly over
| browser(s), the web "standards", and is gradually making them
| more user-hostile.
| array_key_first wrote:
| It's still significantly more open than any other platform.
| Believe it or not, Mozilla is not asleep at the wheel, and
| neither is Apple.
| scheeseman486 wrote:
| Mozilla is absolutely asleep at the wheel (and have
| arguably already swerved off the road and hit a tree) and
| Apple aren't any better than Google in terms of wanting
| to lock down the web.
| LoganDark wrote:
| I use Safari as my daily driver and I'm still routinely
| shocked at just how terrible certain aspects of the
| experience is compared to Chrome. For example, the UI
| seems to completely block for most of the website loading
| process, rather than streaming as Chrome does. Also,
| rather than restore the previous state when I swipe to go
| back, it has to reload the page from scratch. Little
| things like this continue to annoy me day by day, the
| primary reason I don't switch to Chrome is because it
| just doesn't integrate with macOS at all.
| userbinator wrote:
| _Also, rather than restore the previous state when I
| swipe to go back, it has to reload the page from scratch_
|
| I've encountered cases when both behaviours would've been
| desired (either use the cached version, or the latest
| version), so I think that's neither a point in favour nor
| against.
| LoganDark wrote:
| Well, Safari caches resources, it just doesn't seem to
| cache the actual runtime state of the page like Chrome
| does (look for bfcache). The bfcache article claims
| Safari and Firefox do it too, but I have both in front of
| me and no they don't (or it's not good enough).
|
| I think real caching is superior because you can manually
| reload if you actually needed that, but you can't go in
| the other direction.
| array_key_first wrote:
| I've never used safari but to be fair to Firefox: I
| haven't experienced either on desktop. When I go back,
| the page loads instantly. I haven't checked the network
| tab but I'm assuming it's not doing a new request.
| LoganDark wrote:
| Something Safari does is show a stale version of the
| webpage while the updated version is loading. I notice
| because none of my pointer movements take effect until
| the page finishes loading again. I'm not sure if Firefox
| does this too.
| randcraw wrote:
| Exactly. A simple phone that runs a browser I can trust
| that's also capable of running web-based apps is all I need.
| I already avoid running apps on my iphone whenever possible.
|
| The phone I really want is as uncomplicated and open as
| possible and beholden to no corporate economic interests or
| privacy invasions.
|
| Now that I'm retired I'm looking for a project to immerse
| myself in. This sounds like just the ticket.
| seba_dos1 wrote:
| It depends on what definition of "uncomplicated" you'll
| assume, but that's pretty much how I perceive my Librem 5.
| It's fairly inspectable and relatively easy to understand
| as a computing device - no weird stuff like hundreds of
| disk partitions that you can't touch without risking
| bricking the phone like on Qualcomm devices, but a fairly
| regular GNU/Linux installation with well-defined boundaries
| on what's open and what's not - and it runs web apps pretty
| well. I have things like my bank, public transit planner,
| ride-hailing, webmail, RSS reader, Matrix client, package
| delivery status, even Facebook & Messenger for the handful
| of people that can still be only reached there - all
| "installed" as web apps using Epiphany (aka GNOME Web).
| Some of them required a bit of fiddling to discover which
| user-agent leads to a usable experience, but the results
| have been pretty good so far. In case I _really_ need to
| run some Android app for some reason, I can boot Waydroid
| up and launch it there, though I use it very rarely. No
| corporate economic interests, no privacy invasions, no
| invasive notifications or ads, it simply works the way I
| want it to work. I just have to be careful with battery
| usage, but it 's manageable :)
| SoftTalker wrote:
| Use the website. I've never seen a bank where a mobile app is
| the _only_ option for remote access. If my bank did that, I'd
| switch banks.
| ttoinou wrote:
| They more and more force you into 2FA through banking app
| kennywinker wrote:
| Every bank i've used (2, so ymmv) allowed 2fa using a totp
| app, they just don't make that choice obvious you have to
| dig around in the settings
| konimex wrote:
| Here in SE Asia (in my country at least) you're lucky if
| they even offer you SMS 2FA (and even then, only for cash
| withdrawal from ATMs), because otherwise its just using
| PIN or biometrics without any kind of second factor auth.
| _blk wrote:
| UBS bank mandates their "Secure Access" app as second factor
| even when logging in from a desktop. They used to allow the
| smart card reader for existing customers that had it as a
| work around for a few years but they disabled that.
|
| Also many websites are making it remarkably hard to not use
| the app if they even remotely sense you're not on an actual
| PC. FB and LinkedIn aren't banks but prime examples.
| _blk wrote:
| Oh, and of course the stock app will refuse to run on
| rooted (or sometimes even just not widely used) phones.
| marssaxman wrote:
| Good reason to stop using that bank.
|
| I like my credit union.
| rjdj377dhabsn wrote:
| In SE Asia, most banks I've used no longer offer any services
| other than through their app.
| JumpCrisscross wrote:
| What about WhatsApp?
| rjdj377dhabsn wrote:
| I don't follow.. are you asking if WhatsApp offers some
| alternative to banking services? It doesn't.
| JumpCrisscross wrote:
| > _are you asking if WhatsApp offers some alternative to
| banking services? It doesn 't_
|
| Indian banks provide their full suite of services through
| WhatsApp. I have opened and closed accounts, completed
| KYC and authorised transfers through it.
| varispeed wrote:
| Monzo bank in the UK doesn't have a web access (apart from
| very basic page where you can block your card and do nothing
| else, not even see your balance). They also retired support
| for older Android phones, so if you happen to use it on an
| old phone, you are out of banking. I, for security, refuse to
| install bank apps on my phone that I carry, but I have them
| on a separate phone that I have in safe place.
| bigstrat2003 wrote:
| To be clear I'm not saying that alternatives don't exist
| _now_. But it 's a worrying trend that big businesses, and
| even governments in some cases, are moving away from such
| alternatives being available. Look for example at the
| proposed age verification scheme in the EU, where they don't
| plan to make a version you can use on a desktop (and even for
| mobile devices require you use a vendor-attested device).
| Sure, right now it's just for looking at porn. But it seems
| to me that once that settles, it won't be long (a decade or
| two) before you start to see government IDs require a similar
| mobile app. That's the kind of thing I fear happening soon.
| Canada wrote:
| I'm starting to see banks retire their web sites and push the
| app. It's likely that in 5 years most banks will only offer
| apps.
| ttoinou wrote:
| Banking might be the wrong example to choose from here since we
| discovered with cryptos how to handle money without governments
| Bender wrote:
| I hope all the things you mention never become mandatory some
| day because I currently use my phone for voice and text only.
| Sooner than later I plan to get rid of my phone all together.
| I'm gonna surprise the phone company and get a land line. That
| means any online service that uses SMS/text to verify me will
| fail.
| hypercube33 wrote:
| If you're being serious, you're in for a rude awakening. POTS
| lines are dead and being replaced with VOIP and VoIP to pots
| modems on the premise. lots of cities have already started to
| grub the copper out and replaced it a long time ago with
| fiber.
| userbinator wrote:
| Changing the implementation but not the interface is
| exactly the point. It doesn't matter how it's delivered;
| it's _just a phone line_ for voice calls.
| Bender wrote:
| I get what you are saying but POTS in my location is still
| copper. I know because I dug it up when putting in a cattle
| guard. I will have to splice it back together and run it
| somewhere other than under my driveway which I had paved.
| 811 marked it as disco/not-in-use. The telco accidentally
| leaked their plans to run fiber everywhere so I might wait
| for them to do that. If it ends up being VoIP then maybe I
| would still have SMS capability for poor mans 2FA? Maybe
| the competition will drive the cost of my existing fiber
| down. To userbinator's point the end result will be no more
| options to install applications. It would just be a phone.
| I would be back to good old fashioned NSA voice monitoring.
| linguae wrote:
| This was a problem during the early 2000s when Windows and
| Internet Explorer were utterly dominant. Some banks, government
| services, and other essential websites used ActiveX controls,
| preventing access by non-Windows users. I remember during my
| senior year of high school being unable to fill out a college
| financial aid application circa late 2004 or early 2005 on my
| PC running FreeBSD and Firefox; I needed to use Windows and
| Internet Explorer.
|
| I remember the stagnation of Internet Explorer combined with
| increased awareness of security exploits in Windows and
| Internet Explorer led to the rise of Mozilla Firefox and (to a
| lesser extent) increased marketshare for the Mac. This,
| combined with the arrival of smartphones around 2007, put
| pressure on organizations to make their Web sites accessible to
| a wider range of browsers instead of just IE.
|
| Perhaps if we had a critical mass of people using phones with
| FOSS software, this would be enough for banks and other
| organizations to consider people who don't use Apple/Google
| products.
|
| The challenge, though, is getting that critical mass. Firefox
| benefitted from Microsoft's fumbles in the 2000s. It's going to
| be hard for a FOSS project to compete head-on against Apple and
| Google.
| kovac wrote:
| I think this is the right place to start.
|
| A free OS will empower developers to implement technical
| workarounds that could trick these apps into working there. If
| the OS is tightly controlled, we have no recourse.
|
| Even in the worst case scenario, we could use a cheap big-tech-
| approved phone for these applications (a glorified digital
| token) and use the free phone for everything else. When there's
| enough adoption and trust in the new phone, non-technical
| avenues are available to influence these organizations to
| accept the alternative.
| hnuser123456 wrote:
| And I feel like it undermines any effort to make free,
| featureful applications if the hardware itself can't be
| trusted.
| HexDecOctBin wrote:
| Trusted to do what? Work against user's interests? Prevent
| user from even expressing their interests?
| munchlax wrote:
| You can trust hardware and software that's easy to inspect.
|
| If you can't be sure what's going on and unable to inspect
| or debug the hardware and software, how can you trust it's
| doing what you want?
|
| Proprietary hardware and software is already known to work
| against the interests of the user. Not knowing exactly
| what's going on is being taken advantage of at large scale.
|
| Let's put it this way: if you can choose between making
| your own lasagna with a good recipe vs ready-made microwave
| lasagna. What would you choose? How about your suit? And
| would you trust an open known to work well pacemaker vs the
| latest Motorola or Samsung pacemaker? Would you rather
| verify the device independently or pay up for an SLA?
| Arainach wrote:
| No software is "easy to inspect". Only a tiny fraction of
| users will ever even try. When things are inspected and
| problems are found, you need a way to revoke the
| malicious bits. You'll never notify everyone, which is
| one of the roles app stores play.
|
| You trust hardware and software by establishing
| boundaries. We figured this out long ago with the kernel
| mode/user mode privilege check and other things. You want
| apps to be heavily locked down/sandboxed, and you want
| the OS to enforce it, but every time you do you go up
| against the principles of open source absolutists like
| the FSF. "What do you mean my app can't dig into the
| storage layer and read the raw image files? So what if
| apps could use that to leak user location data, I need
| that ability so I can tell if it's a picture of a bird"
|
| For sensitive information - such as financial
| transactions - the rewards for bad actors are simply too
| high to trust _any_ device which has been rooted. The
| banks - who are generally on the hook if something goes
| wrong, or at least have to pay a lot of lawyers to get
| off the hook - are not interested in moral arguments,
| they want a risk-reduced environment or no app for you -
| as is their right.
| munchlax wrote:
| Not really.
|
| If their security depends on enslaving the user, their
| security sucks.
|
| Real security, be it your financial transactions or
| keeping your bird pictures safe, doesn't depend on any
| secret algorithm. Because it's secure.
| Arainach wrote:
| The threat models aren't secret algorithms, they're apps
| reading the contents of the screen, stealing keystrokes,
| MITM attacks against 2FA, and much more.
| munchlax wrote:
| Apple, Google and Microsoft created that problem.
|
| I don't have this problem on my computers, they run free
| software. My wifes thinkpad runs free software. The
| friends I gave a computer with various GNU+Linux distros
| don't have this problem.
|
| Add Google Chrome with its spammy extensions to the mix
| and they start getting problems.
| yjftsjthsd-h wrote:
| So, things that can be exploited on a stock Pixel with no
| user root? This is a weird argument to make at the same
| time as https://news.ycombinator.com/item?id=45588594 is
| on the front page.
| seszett wrote:
| > _For sensitive information - such as financial
| transactions - the rewards for bad actors are simply too
| high to trust any device which has been rooted_
|
| In practice, that just means you trust a Chinese black
| box Android ROM from a random manufacturer, but not a
| fresh Lineage OS. To run some banking apps there, one
| _has to root it_ and install all kinds of crap to hide
| the fact that your phone is running an OS you actually
| can trust.
|
| I don't think it's right, I don't think non-manufacturer
| provided ROMs are a real danger in practice, or rooted
| phones, and I think this is all just security theater and
| an excuse to control what people do on their own devices.
| lmm wrote:
| > The banks - who are generally on the hook if something
| goes wrong, or at least have to pay a lot of lawyers to
| get off the hook - are not interested in moral arguments,
| they want a risk-reduced environment or no app for you -
| as is their right.
|
| If they pay for the phone and ship it to you then I
| agree. Otherwise, they have an obligation to serve their
| community (part of their banking charter) and that may
| include meeting their customers where they are, rather
| than offering an app with unreasonable usage
| requirements.
| Arainach wrote:
| No charter requires allowing access from any device. The
| charters don't even require banks to be open during hours
| most of their customers are off work.
| lmm wrote:
| The charters aren't that specific (nor should they be).
| But they do oblige the banks to serve their customers to
| a certain extent.
| yjftsjthsd-h wrote:
| > You trust hardware and software by establishing
| boundaries. We figured this out long ago with the kernel
| mode/user mode privilege check and other things. You want
| apps to be heavily locked down/sandboxed, and you want
| the OS to enforce it, but every time you do you go up
| against the principles of open source absolutists like
| the FSF. "What do you mean my app can't dig into the
| storage layer and read the raw image files? So what if
| apps could use that to leak user location data, I need
| that ability so I can tell if it's a picture of a bird"
|
| Well, no. The objection isn't to sandboxing apps, but to
| sandboxing the user, as it were. On my laptop, I run my
| browser in a sandbox (eg. bubblewrap, though the
| implementation of choice shifts with time), but as the
| user I control that sandbox. Likewise, on my phone, I'm
| still quite happy that my apps have to ask for assorted
| permissions; it's just that I should be able to give
| permission to read my photos _if I choose_.
| Arainach wrote:
| Users can't be trusted. They don't read. You can put a
| popup that flashes in all caps saying "THIS WILL GIVE
| ACCESS TO YOUR BANK ACCOUNT" and users will blindly click
| OK to get to whatever they think they want, be that an
| Instagram feed, a game, or whatever.
|
| https://devblogs.microsoft.com/oldnewthing/20030901-00/?p
| =42...
|
| It was true 22 years ago and is even more true today.
| NetMageSCW wrote:
| There's no way I'd trust open source anyone with my
| health. And I am not sure there is one open known to work
| well project, let alone a pacemaker that couldn't
| possibly be funded in the open source world. What open
| source hardware is actually more usable than the closed
| source alternative for most people?
| kiratp wrote:
| Should the app builder's ability to "trust" that the
| hardware will protect them from the user supersede the
| user's ability to be able to trust that the hardware will
| protect them from the app?
|
| In other words, should the device be responsible to
| enforcing DRM (and more) against its owner?
| r283492 wrote:
| And FSF has a history of creating important OS level
| software.
| BLKNSLVR wrote:
| I've kinda migrated to the worst-case scenario already and
| it's really not that bad - for my use case.
|
| I have an old phone (actually running LineageOS rather than
| stock) that works as you perfectly describe as a glorified
| digital token. This device doesn't come with me. There's no
| banking I need to do, on a day-to-day basis, requiring said
| token, that _has to be done right now or the world will end_.
| It can wait until I get home (and I usually use the bank 's
| web interface from a desktop). This device has minimal other
| apps installed, which limits bank app accessibility of other
| app data, and other app accessibility of bank data.
|
| Then my GrapheneOS daily driver serves my day-to-day needs
| with minimal data leakage, tracking, ads, other general
| paranoia-inducing modern-life shit.
|
| I pay for things on a day-to-day basis with a physical debit
| card due to an existing habit of not wanting to depending on
| a single device for "all the things", so GrapeheneOS wasn't a
| downgrade, but it should be noted to others that whilst
| Google Wallet can run on GrapheneOS, NFC payments through the
| Google Wallet will not work due to Full SafetyNet
| requirements that GrapheneOS can not pass. Non-NFC items such
| as tickets and boarding passes have been reported to work
| (and I'm pretty sure I've used it for that, although Google
| Wallet is no longer installed on my device).
| glitchc wrote:
| It sounds utopian except you still have to pay for a cell
| plan on said device, no? How else to obtain a phone number
| for MFA?
| NetMageSCW wrote:
| Hopefully by not using MFA that depends on SMS.
| NoGravitas wrote:
| Unfortunately there are non-SMS MFA that are still tied
| to a phone number, and you may be forced into using them
| for some context. Duo Mobile is one.
| BLKNSLVR wrote:
| No, just connected via wifi. I don't use it outside the
| house. The MFA token comes via the banking app itself,
| not via SMS.
|
| If it came by SMS my daily driver would receive it.
| efreak wrote:
| You already have a cell plan. It doesn't have to be
| attached to the same device.
| NetMageSCW wrote:
| To me that sounds like sacrificing living for a principle
| and missing the point.
| BLKNSLVR wrote:
| I hadn't migrated my life to any of the (tiny, possibly
| zero) convenience improvements that "mobile banking" may
| offer me, so none of what I've described has been any
| kind of downgrade in 'living'.
|
| (I don't mean this in a sarcastic way) are you able to
| make tangible what 'living' I may be sacrificing?
| aidenn0 wrote:
| I see a trend of banks pushing people off of their websites
| onto the mobile app.
| BLKNSLVR wrote:
| That is a slight concern, but I don't see it happening,
| at least in Australia for the big four banks, in the near
| future.
|
| If that became the case, then the 'glorified token
| device' would become the dedicated banking device, and
| not much else would change (ie. I still wouldn't be doing
| 'banking' while I'm out and about).
| pjmlp wrote:
| Like they have been doing for Desktop Linux?
| praptak wrote:
| Having a separate phone as a "glorified digital token" is
| probably within the top 3 things you want to do anyway if you
| are serious about digital security.
|
| See the recent discussion about pixnapping:
| https://news.ycombinator.com/item?id=45574613
|
| Also, if your bank uses SMS for verification then the phone
| should have its own phone number which you keep secret.
| Otherwise it's one data leak and one sim swap attack
| (https://en.wikipedia.org/wiki/SIM_swap_scam) from breaking
| your SMS verification.
| NoGravitas wrote:
| > A free OS will empower developers to implement technical
| workarounds that could trick these apps into working there.
|
| Not if they require something like hardware-backed remote
| attestation, and only accept such attestation from Google or
| Apple.
|
| I'd love a practical Linux phone, and being able to run a
| deblobbed close-to-mainline kernel on a new-ish phone would
| help with that, but that doesn't really solve the most user-
| facing problem of mobile phones, the ecosystem lockdown.
| ipaddr wrote:
| Get a big tech second phone. Cheapest available. Just perform
| the needed tasks and use your Libre phone for everything else.
|
| Does anyone remember having a copy of internet explorer that
| the bank required (or chrome these days) but using firefox for
| everything else? Apply that concept to a phone.
| jeena wrote:
| But then I would need to constantly charge two phones and
| keep two phones in my pocket all the time because I never
| know when I would need to do those things on the go.
| longitudinal93 wrote:
| I recently added a second phone for secure comms
| (Graphene). The biggest hassle turned out to be moving data
| between them. For that I settled on running my own Matrix
| server.
| DirkH wrote:
| You check your banking apps multiple times each day with
| the frequency and unpredictability expected from messaging
| apps?
|
| If not that frequently or unpredictably then you could just
| plan to use your laptop for banking some time during the
| day.
| getpokedagain wrote:
| Yup. Right now that's something running graphene for me. I'd
| prefer full linux but the other options don't seem viable yet
| to me. When I tried the pine phone a few years ago its
| battery life was in the 3-5 hours range if I used the phone
| which is not sufficient.
| varispeed wrote:
| Some banking apps require relatively new OS, so if you have
| an old phone with e.g. Android 8 and you can't upgrade
| (Android 9 removes certain important features), you are out
| of luck.
| drnick1 wrote:
| For people without a viable alternative such as transferring
| their funds to a bank that does not require Google/Apple
| certified devices, this seems to be the way. The second phone
| does not even need to have a SIM card in it, except perhaps
| during set up. That phone does not leave home and is ideally
| be powered off with its battery removed when not in use.
| Everything else can be done on a free device, ideally using
| FOSS apps. Ideally again, this means no Facebook, no
| Whatsapp, no IoT crapware.
|
| Luckily, here in the U.S. this is still possible. I run
| Graphene on a Pixel without Play Store compatibility layer
| and everything just works. Most of my apps come from F-Droid,
| with the notable exception of Whatsapp, for which a
| standalone APK is available. Unfortunately, it is proving
| difficult to get rid of Whatsapp entirely because of friends
| and family.
| 0xbadcafebee wrote:
| Well you're partially right. After all, the "big tech approved
| phone OS" is actually _Linux_ , so just having a free OS isn't
| enough to prevent it from being co-opted and turned into a
| locked-down platform.
|
| But the partially wrong part is, we can make our own platform.
| PCs let you install and run any software you want, because it's
| an open platform. If we make an open platform smartphone that
| can compete on features with the closed behemoths, and that
| then becomes popular enough, then banks may offer apps on that.
|
| But this is tricky too. Linux already has issues getting
| official support from corporations. We'd need our open platform
| to be compatible with the closed ones, so that it's easy for
| banks to run their apps on our open platform. There are already
| ways around this, like virtual machines to run Android, or
| other methods. But the closed behemoths may try and end-run
| around this, like DRM. So we'll still need to advocate for our
| rights and compatibility.
| 1718627440 wrote:
| > so just having a free OS isn't enough to prevent it
|
| They have a free kernel not a free OS. Them not having a free
| OS is precisely what is the issue here.
| thuruv wrote:
| seconding this. more compatible with day-to-day life/apps means
| more adoption which I believe is a snowball effect.,
| phs318u wrote:
| I agree that FSF and similar groups should be focusing efforts
| on influencing government policy at least as much as on
| software. The problem is that in practice, you'll get a bunch
| of people who are erstwhile free software supporters, shouting
| back that the FSF should "stay n their lane" and stay out of
| politics (missing the point that in life, everything is
| politics).
| mekoka wrote:
| If the government needs me to get a side phone for ID, I'll
| cross that bridge. For everyday use, I'm fine with having a
| "rogue" phone as my primary.
| jay_kyburz wrote:
| The next step will be for them to prevent you connecting to
| the cellular network.
| longitudinal93 wrote:
| Just tether through your shit phone
| userbinator wrote:
| Indeed, binary blobs are not much of a problem; it's anti-user
| "security" that has to be attacked. Otherwise we'll end up with
| user-hostile systems that we can see the source code of but
| can't modify, in contrast to systems that we can't see the
| source code of but can modify. The Windows modding scene of the
| late 90s/early 2000s is a good example of the latter (and I've
| joked that every power user was a novice reverse-engineer),
| while Android is turning out to be a good example of the
| former.
|
| Stallman had a good idea for free (as in freedom) software, but
| then "missed the forest for the trees" by focusing on the
| source code.
| DonHopkins wrote:
| >Stallman had a good idea for free (as in freedom) software,
| but then "missed the forest for the trees" by focusing on the
| source code.
|
| RMS is afraid of trees!
|
| https://news.ycombinator.com/item?id=28419139
| smashah wrote:
| i think the best solution to this would be some sort of docker-
| project for people to remotely access a device hooked up to a
| raspberry pi or something at home via adb via
| https://github.com/Genymobile/scrcpy as "natively" as possible.
| varispeed wrote:
| Funny that bank software needs approved phone, but runs
| absolutely fine in the browser. That to me sounds like
| collusion - something that regulators should look at. There is
| absolutely no need for banking app to require "legitimate"
| Android or other operating system.
| lambertsimnel wrote:
| Increasingly, browser-based online banking requires
| authentication with a proprietary smartphone app, where it
| used to accept other forms of 2FA
| hedora wrote:
| There is one solution to this problem that many people reading
| this message can contribute to:
|
| Make sure your app has a progressive web app version that has
| feature parity with the store apps. That way, the app will work
| on phones like the librephone, and, if Apple or Google decide
| to kick you off the store, you and your users have some
| recourse. As a bonus, it's compatible with open source -- users
| can modify the app and install it without jailbreaks, root or
| (for now) sideloading.
|
| React Native supports this (and can mostly be bundled with
| electron for mac/win/linux support).
|
| Are there other stacks people can recommend?
| scheeseman486 wrote:
| This won't help if Google/Apple/Microsoft roll out integrity
| checks for browsers, something which they have already
| suggested they want to do.
| mikestorrent wrote:
| It won't just be them. I foresee Cloudflare and other CDNs
| offering a free checkbox: [] Require age of majority
| verified user
|
| And it will in turn depend on Secure Attestation, Web
| Credentials, and other recent W3C work to provide proof
| that you're the registered owner, age of majority and
| verified by thumbprint or other biometrics, running an
| unmodified device. Your ID might be escrowed with your OS
| vendor, email provider, bank, ISP, or even Twitter/X, who
| knows. Either way, as an end user you'll be mollified that
| you don't have to provide your ID to the adult site, and
| the adult site will be happy that they don't have to
| implement any of this themselves.
|
| And, of course, this will mean that an intelligence service
| could have ironclad proof of exactly what person visits
| what website, effectively killing a lot of online
| anonymity.
| fuzzzerd wrote:
| That sounds awful.
| Barbing wrote:
| You're probably 100% right and it's honestly
| heartbreaking.
|
| Time to donate to the EFF and FSF I guess...
| hedora wrote:
| Also, time to switch back to firefox, and turn off the
| DRM crap.
|
| I get warnings from some sites (like radio stations) that
| DRM is required for the page, but haven't noticed any
| breakage.
|
| Using them in that mode adds signal to their web server
| logs saying that forcing DRM will break their site.
|
| Everyone that cares about this stuff should be doing
| this.
|
| (And, no, firefox isn't broken. Also, Firefox doesn't
| include the pile of dark patterns and mandatory google
| spam that chrome does.)
| LoganDark wrote:
| It's something they've already done, they just aren't being
| public about it yet. Look up the X-Browser-Validation
| header.
| kees99 wrote:
| ...and packaging _my_ app as a PWA is going to help with
| cantankerous bank /ditigal-id apps, how, exactly?
| mmh0000 wrote:
| Momentum.
| thedumbname wrote:
| You are mixed up 3 different tech stacks: 1. React Native has
| nothing in common with web apps except JS runtime. It uses
| "native" widgets for Android and iOS. You need to add a new
| "native" runtime for your free OS. There are some third-party
| attempts to add mac/win/linux support, but they are not
| feature complete as officially supported platforms. Again,
| your free OS will be step behind. 2. Yes, you can write PWA
| with React (Web), but PWA still have many missing features
| which offered by platform APIs of Android and iOS. Your app
| will not be in "feature parity" with "native" app. Especially
| banking app. 3. Electron apps are integrated with desktop
| platform APIs, you cannot easily port Electron app to mobile.
| Every time big company with big investments wins.
| dotancohen wrote:
| What does a banking app need that a PWA can not provide?
| NoGravitas wrote:
| Technically nothing.
|
| In practice, banks will demand remote attestation of the
| environment the app is running in.
| hedora wrote:
| I have a react native app, and can compile it to pwa mode.
| It runs well in a browser.
|
| 99% of the code runs fine in electron to. Index.tsx is the
| main exception.
|
| I'm not saying you can automatically run software for one
| of these targets across all three. I'm saying it's
| straightforward to write portable software that works on
| all of them.
|
| Also, I can't think of any apps I use that require any
| platform-specific APIs at this point. Even if they did, the
| phone I want would be able to surface those APIs to pwas.
| thaumasiotes wrote:
| > What does it matter if you can run a completely free software
| stack on your phone, if your bank software (or your required
| government ID, as is looking depressingly likely) requires you
| to run a Big Tech approved phone OS?
|
| Log in to your bank over the internet, the normal way.
| matheusmoreira wrote:
| Yeah... Corporations and governments are starting to push
| remote attestation. There'll be little point to a free computer
| if it gets us denied service everywhere. At this point we're
| gonna end up marginalized, like second class citizens of
| society.
| jMyles wrote:
| > There'll be little point to a free computer if it gets us
| denied service everywhere. At this point we're gonna end up
| marginalized, like second class citizens of society.
|
| Given the apparent trajectory of the corporate/government
| model of organizing society, it seems like they're going to
| be the ones that will be second-class citizens.
| nostrademons wrote:
| You can replace the banking system. Replacing the banking
| system does nothing if a single tech company can brick the
| phones of people using the replacement, or block it from
| launching.
| wafflemaker wrote:
| Banks and national id apps already work on GrapheneOS.
| Sometimes you just need to msg devs and ask them to use a
| different OS attestation method - see link 1. This battle is
| won already.
|
| 1.: https://grapheneos.org/articles/attestation-compatibility-
| gu...
| twothreeone wrote:
| Sorry, but no. Device attestation is another mechanism to
| track and ultimately exercise control over the user. It
| fundamentally goes against the freedom of choice. You want me
| to authenticate with multiple factors? Cool.. let me tell you
| which method I'm already using on all my other accounts and
| then tell me how to register that with your service. You want
| to "measure" my device? Okay, I'll take my business
| elsewhere..
| autoexec wrote:
| > What does it matter if you can run a completely free software
| stack on your phone, if your bank software (or your required
| government ID, as is looking depressingly likely) requires you
| to run a Big Tech approved phone OS?
|
| What does it matter if you can use any OS you want if your
| phone is filled with SoCs which are bugged and backdoored by
| the state and/or who knows who else? The reality is that we
| need both free hardware and free software. I can always tell my
| bank to fuck off and move my accounts to one that gives me
| freedom to use the mobile OS of my choosing, and if there isn't
| a single bank on earth willing to do that I can always simply
| refuse to use my cell phone for banking.
|
| I'd much rather keep the phone I control and trust while
| limiting myself to only having the options of a desktop PC, a
| laptop, an ATM, a phone call, a drive thru, and walking into my
| bank's closest branch when interacting with my bank. Not being
| able to also stab my finger at a cell phone screen to check my
| balance isn't really that big of a deal.
| geokon wrote:
| Safe hardware is super difficult
|
| The only project I know of that really actively addressing
| the end to end problem is Bunnie Huang's precursor.
|
| Work seems to be going on low-key:
| https://github.com/betrusted-io/xous-core
| bigstrat2003 wrote:
| > What does it matter if you can use any OS you want if your
| phone is filled with SoCs which are bugged and backdoored by
| the state and/or who knows who else?
|
| Perhaps. But how does this effort from the FSF do anything to
| solve that? They are (as far as I can tell) producing
| firmware, not hardware. If the hardware manufacturers are
| working with the government or whomever to spy on you, they
| will just not use the FSF firmware in that case.
| mrsssnake wrote:
| The mere fact such phone exist could be enough argument for
| pushing back, for ex. hurtful legislations.
|
| People tend to see current world as carved in stone, like it is
| not going to change. It is, still not easy but, much easier to
| ask government not to mandate Windows/MacOS only program for
| essential task, because of couple of users of other systems,
| rather than asking to imagine that in future there might be
| other systems.
| pessimizer wrote:
| Why would the FSF be working on a problem that has absolutely
| no technical element? What exactly do you want them to tell
| your bank and your government? Why exactly can't _you_ tell
| your bank and your government that?
|
| > that is where I feel they could truly make the biggest
| difference for freedom for the average user.
|
| By doing what exactly? Telling your government to change their
| ID policies? You seem to be complaining at your health food
| store about the nutrition of McDonald's food, because most
| people eat at McDonald's and that's where they would make the
| most difference.
| jajuuka wrote:
| Historically we have seen bumps in Linux usage because of
| cross-platform support. Either officially or unofficially. So I
| agree that focusing on making that transition more seamless
| will be of more benefit than telling people they need to use
| something different or suck it up. There is a reason rooting
| and making banking and other high security apps functional has
| been pretty popular.
| its-summertime wrote:
| https://librephone.fsf.org/FAQ.html
|
| Currently scope only seems to go as far as the operating system
| soupy-soup wrote:
| That's really as far as they need to go; if the userland is
| compatible with Linux, it can use all of the work that KDE and
| other organizations have put into building mobile interfaces.
|
| These projects have stuff that works, but the lack of firmware
| for chips that can connect to modern cell infrastructure means
| that they can't really create an appealing product. The OS
| layer is where all previous Linux phone efforts have failed,
| and I hope the FSF makes it farther than everyone else has.
| seba_dos1 wrote:
| > The OS layer is where all previous Linux phone efforts have
| failed
|
| The OS layer is where the existing projects are thriving,
| with various distros and shells to choose from to match one's
| needs and tastes. It's the appropriate hardware that's in
| undersupply. I'm using a Librem 5, a 2019 design, and if I
| wanted to switch to something newer I can't because there's
| no viable upgrade path on the market. No other hardware
| vendor has invested significant resources into mobile
| GNU/Linux since then, everything else is either purely
| community-based or uses Halium.
| jancsika wrote:
| Does webrender work with the Librem 5? Last time I checked
| it didn't-- Firefox disallowed it because the etnaviv
| driver didn't have all the features available needed to
| enable it. It appears there's been a lot of work on etnaviv
| recently but I don't know if it affects this issue.
| seba_dos1 wrote:
| etnaviv doesn't do GLES3 yet, so no, but the work to
| support it (mostly done by Christian Gmeiner) is ongoing
| and progressing. I'm using Epiphany though, it's pretty
| snappy these days and I make extensive use of its webapp
| feature. I don't even remember when was the last time I
| had to fallback to Firefox because of some
| incompatibility, but it did happen at least once.
| bsimpson wrote:
| Interesting that they chose Android as a base and not one of the
| desktop-Linux-for-mobile ports like postmarketOS.
| ACCount37 wrote:
| App compatibility is a thing, you know.
|
| I like postmarketOS, but it always felt to me more like a pet
| project than a real OS, for that reason.
| beeflet wrote:
| waydroid
| ray_v wrote:
| Inertia is a hell of a thing.
|
| Seems like a smart decision to me since that's what everything
| phone related builds to as a lowest common denominator anyway.
| ocdtrekkie wrote:
| It's an incredible waste and an amazing example of how useless
| the FSF is today. Instead of supporting real Linux phones
| they're focusing on trying to degunk Android even more.
| gertop wrote:
| > It's an incredible waste
|
| Funny, I would have used those exact words had they chosen
| anything BUT Android as their base.
|
| All the other "freedom" Linux phones are failures (yes I'm
| sure fsflover will now chime in to but akshually). I know
| because I bought them all. They all have one thing in common:
| the software sucks.
|
| And I don't even need apps. Just basic phone functionality
| (several Linux phones still can't do MMS), a web browser, and
| no crashes. Unfortunately no Linux phone has been able to
| give the to me yet. Whereas Android has been delivering for
| over a decade.
| drnick1 wrote:
| I think that supporting Android as a free platform is a
| sensible choice. Android has benefited from more than a
| decade of development by Google, Samsung, and others and
| provides a polished experience and thousands of apps people
| actually want to use (and many excellent FOSS options too).
| AOSP is already "free software" and starting from scratch
| with Linux would make very little sense at this point. The
| FSF is right to focus on what matters here, which is hardware
| on which to run free Android.
| NoGravitas wrote:
| A fully degunked kernel that supports LineageOS with full
| hardware support is one that will also run PostmarketOS or
| similar.
| _blk wrote:
| yes, but it's probably the quickest path to market with a
| reasonably certain customer satisfaction.
|
| Doesn't stop you on working from there once that milestone is
| reached.. I would certainly welcome more alternatives in light
| of the recently announced changes from do-no-evilG
| crossroadsguy wrote:
| If they wouldn't have then X years later there would have been
| first beta release and zero apps on it except for a calculator
| app, a notes app, a calendar app, and maybe a mail app
| developed by the core developer team. The post would have
| definitely reached the top of hn, so that'd be a plus.
| rjdj377dhabsn wrote:
| It makes a lot of sense to me. There's a huge amount of work
| that's already been put into the Android ecosystem that can be
| used in a free software phone.
|
| Trying to build a non-Android Linux phone that is competitive
| is just not practical at this point. It would require an
| enormous amount of funding.
| o11c wrote:
| If prior "Linux phone" projects have taught me, it's that
| "based on desktop Linux" is a great way to have a ton of apps
| that install just fine, but can't meaningfully be used.
|
| Not even just "requires a mouse/keyboard", but a lot of things
| of the form "assumes a reasonable screen size", ...
| anonzzzies wrote:
| Android already is mobile: making it better makes sense. Linux
| already runs fine on it: termux and things like NOMone desktop
| combined with allowing virtual memory and keep apps running
| like some brands (Blackview, Oukitel) allow, you are there a
| lot of the way. Then Android desktop support (again, many
| brands have something already but it is now in Android mainline
| it seems). I use an oukitel rt7 as my main daily driver: it is
| rooted. It has some quirks and of course is very far from open,
| but things works, -ish. I would spend far more time on
| contributing if we had an open choice(or at least working) here
| that supports the 5g. On other phones/tablets, it is the
| fingerprint sensors, 3d face camera, but also different 'niche'
| auxillaries that would get far more attention if you at least
| can start with something that is (mostly open) and works. If we
| have coverage for a bunch of devices with everything working,
| it will be more attractive to work on other/newer ones.
|
| With Linux, you will need, as I have seen on my pine phone, way
| too much focus on just basic apps which still are not good
| compared to their android equivalent: spending time there is
| not spending time on hardware support...
| Tepix wrote:
| It's the right decision: Android is mostly open source and
| works well. Not to mention that in real life, right now, people
| need access to certain apps as a firm requirement.
|
| Have you seen the attempts of past "Linux phones"? Usability,
| performance and usually battery life were horrible and progress
| was also slow.
|
| There have been comments about the race to support recent
| phones. I hope that Fairphone will looked at as a target
| device. It would be a good cultural fit and they don't have a
| yearly device cycle which should also help.
| NoGravitas wrote:
| I think it gives them the ability to compare device support of
| "LineageOS with vendor kernel" and "LineageOS with unblobbed
| near-upstream kernel" as a measure of progress. If you get the
| latter working as well as the former, bringing up PostmarketOS
| on the same kernel is a much smaller problem.
| flykespice wrote:
| They don't want to repeat GNU/Hurd tragedy
| ACCount37 wrote:
| Unfortunately, even if you could completely de-blob the kernel
| itself (and for many chipsets, that would require a considerable
| amount of reverse engineering work!), smartphones bear the Curse
| of the Modem.
|
| In a modern smartphone, modem is often a part of the SoC itself -
| and it runs some of the biggest and fattest blobs you've ever
| seen.
| arminiusreturns wrote:
| Yep, with DMA sometimes. I've heard this same thing on the
| Pinephone forums iirc during the early years.
| hypercube33 wrote:
| I for one am up to the idea of breaking android off Google due
| to the same reasons of chrome - conflict of interest since
| Google is an advertising company.
| femto wrote:
| Not insurmountable, given the availability of srsRAN.
|
| https://www.srsran.com/
| ACCount37 wrote:
| But are you enough of a madman to port that onto an
| undocumented magic modem?
| kube-system wrote:
| This is the big barrier here, and unfortunately, it is legally
| impossible to open source.
|
| In most countries, the spectrum that cell phone carriers use is
| licensed to the carrier, under the condition they only connect
| devices that are guaranteed to comply with the requirements of
| using that spectrum. The end user (i.e. the person with the
| phone) has no license to use the spectrum. So in order to get
| regulatory certification, basically every modem has to be
| locked down so that the end user cannot operate it in a way
| that would violate any rules or regulations for using that
| spectrum.
|
| So basically, it's illegal to have open source modem firmware.
| At least, as long as cell phones are operating on spectrum that
| isn't open for public use.
|
| Ultimately, if you want to open source a modem, you first need
| to build your own cell phone network.
| tguvot wrote:
| theoretically, there is lte cbrs where spectrum not licensed.
| kube-system wrote:
| Don't cbrs devices need to be part 96 certified? The
| spectrum might not be licensed but you still may need a
| certified device to legally use the spectrum. Which you
| could do, but that is a tall hill to climb for a FOSS
| enthusiast. And when you're done -- what network are you
| going to connect it to? A cheap SIM from the corner store
| is probably out of the question :)
| tguvot wrote:
| looks like they need. but it still gives you more
| possibilities compared to usual spectrum. if there is
| enough coverage from SAS you (or FSF) can build your own
| cbrs network that will have open source modem/firmware
| (yet, still will have to comply with part96).
|
| there are also all kind of open source lte/cbrs projects
| iirc
| kube-system wrote:
| It's a fun thought exercise, but putting "part 96
| certification" at the end of my build pipeline sounds
| pretty expensive. And building a physical cell phone
| network is stupidly capital intensive. Maybe there are
| some interesting small scale niches that this would be
| useful for. But as a daily driver cell phone, I don't
| think we're ever gonna have an open source modem, at
| least not until there are significant changes to the
| spectrum that's in use.
| tguvot wrote:
| i didn't say that it's cheap. i said that it's possible.
| jMyles wrote:
| Hopefully open mesh wifi will supplant cell phone networks
| anyway.
| kube-system wrote:
| Haven't there been projects trying to do this since
| 802.11b? I think the last time I looked one of these mash
| networks up, there wasn't even decent coverage in the dense
| city I lived in.
| bouncycastle wrote:
| this is the same thing with wifi. There are different
| channels and transmission power rules depending on country.
| Something you cannot change even if you are root or build
| your own kernel, as it's built in to the wifi hardware (eg.
| raspberry pi)
| kube-system wrote:
| Part 15 is a lot more permissive, and it's unlicensed. But
| yeah, the device still has to be part 15 certified.
| ACCount37 wrote:
| You can open source it. Unfortunately, "open source" doesn't
| mean "user is allowed to run his own code" nowadays.
| pabs3 wrote:
| One of the two processors (the ARM one) in the PinePhone modem
| runs a proprietary Linux distro, which can be replaced by a
| free distro. The code on the Hexagon processor can't be
| replaced yet though I think.
|
| https://themodemdistro.com/ https://github.com/the-modem-
| distro/
| ACCount37 wrote:
| Yeah, and it's the Hexagon mDSP that's the issue. It's
| basically THE modem. It has its own RTOS and runs the entire
| RF stack and whispers to all the other RF parts. The cores
| that run the Linux distro are just... there. For you to run
| Android on, normally.
|
| PostmarketOS can run on some devices with almost no blobs -
| but there's no escaping the modem curse.
| charcircuit wrote:
| >Librephone aims to close the last gaps between existing
| distributions of the Android operating system and software
| freedom
|
| I am so happy they are focusing on Android, one of the most
| popular operating systems widely used by every day people. This
| is important work for providing user friendly, free software to
| users.
|
| Let's just hope they don't fall into the trap of disqualifying
| binary blobs sent as part of drivers vs opting for hardware that
| harcodes the blob.
| tmtvl wrote:
| Are you hoping the _Free Software Foundation_ _doesn 't_
| prioritize _Free Software_? For people who are okay with random
| bits of proprietary software doing who-knows-what on their
| devices there are various alternatives already.
| Dylan16807 wrote:
| That's not even close to what they said.
|
| They're saying approval of any who-knows-what code shouldn't
| be decided based on how it's loaded.
| degamad wrote:
| I initially made the same misread that you did...
|
| The OP's point is, having the firmware permanently burnt-in
| on a ROM chip vs loaded as a binary blob via a driver doesn't
| change the "non-free"-ness of the firmware itself.
|
| So opting for hardware which has a "fully-open-source"
| driver, but runs a binary blob encoded into the hardware,
| doesn't make the system fully open.
|
| It's a take for a more Free system, not for accepting binary
| blobs.
|
| (Or I guess for acknowledging that if you're willing to allow
| binary blobs stored in hardware, then dynamically-loaded
| binary blobs doesn't change the "free"-ness.)
| charcircuit wrote:
| To me:
|
| Open Source Firmware signed by OS > Firmware blob signed by
| device manufacturer > Firmware blob hardcoded by device
| Manufacturer
|
| The FSF treats hardcoded firmware blobs as "free" and
| updatable firmware blobs as nonfree despite there not being a
| big difference between them in practice. And practical
| differences like being able to fix security issues benefits
| users.
| jacquesm wrote:
| > And practical differences like being able to fix security
| issues benefits users.
|
| More often than not these updates are not actually benefits
| to the users.
| charcircuit wrote:
| Can you provide such an example? Because of bugs in the
| new version? A lot of the time old versions can still be
| loaded.
| jacquesm wrote:
| Just in the last couple of days:
|
| https://news.ycombinator.com/item?id=45568700
|
| There are by now thousands of examples of this, I wonder
| why you would ask for an example, this is about as
| uncontroversial as the sun going up tomorrow.
| charcircuit wrote:
| The number of times that Linux distros, free software,
| has made my computer unusable, requiring me to manually
| fix it, is uncountable. Bugs from OS updates is still
| entirely possible even without updating firmware blobs.
| jacquesm wrote:
| To a driver whose car just died on I 405 in heavy traffic
| that is a distinction without a difference.
| tmtvl wrote:
| Thank you for clearing that up, I clearly misread that
| completely.
| ggm wrote:
| Thank you John Gilmore.
| zb3 wrote:
| For it to succeed, they must also help put pressure on
| governments (countries like Brazil or Italy) and banks to stop
| depending on "Play Integrity" because only Google has the keys
| (and blocks leaked ones) so we can't count on bypasses being
| available (it's not just a matter of obfuscation).
|
| This needs to be done before age verification apps become
| universal..
| matheusmoreira wrote:
| There was a time the brazilian government mandated free
| software in government computers. Lots of people hated it
| unfortunately. Eventually Microsoft lobbying put an end to it.
| That was around ten years ago... I wonder if such a thing could
| ever repeat again.
| matheusmoreira wrote:
| Took them long enough... The free software movement was still
| stuck on PC despite the fact the whole world moved to mobile.
| Glad to see they're finally starting to catch up.
|
| They should probably prepare themselves to make ideological
| concessions... The situation is very ugly here in mobile land.
| Treacherous computing, remote attestation, DRM, all ubiquitous
| and normalized...
| glitchc wrote:
| It's a great idea. Why not join forces with the PinePhone and
| Librem folks? They're building the hardware and I'm sure they
| could use more software folk to help out with the firmware and
| OS.
| IlikeKitties wrote:
| How will this phone comply with child safety laws?
|
| *Edit* Because Idiots are Downvoting me, look at the texas law SB
| 2420 as an example. These phones will essentially be illegal in
| texas unless they comply with already passed laws.
| kube-system wrote:
| They will comply with the law because they are not making a
| phone, or any product at all for that matter. This is a reverse
| engineering initiative.
| Razengan wrote:
| The world could have been very different today if Nintendo or
| Sony had put phone functionality in the DS and Vita.
|
| Any reason that can't happen now in something like the Steam
| Deck?
| tom_alexander wrote:
| USB modems exist and work on Linux[0]. The Steam Deck is a
| Linux computer with a USB port. You could be living this
| reality today.
|
| [0] https://www.thinkpenguin.com/gnu-linux/usb-4g-lte-
| advanced-m...
| seba_dos1 wrote:
| They work fine for data and SMS, but it gets complicated once
| you need audio routing (it's rare for a modem to expose audio
| over USB) or waking up from low power mode to answer the
| incoming call. Could be done with M.2 USB modules and some
| dedicated controller in-between though.
| mrheosuper wrote:
| HID USB devices can already wake up computer from sleep, so
| i dont think we need M2 here.
|
| Also i dont think routing audio is problem, the dongle
| could represent itself as external audio device, like those
| external usb dac.
| seba_dos1 wrote:
| Of course it could! Now find one that does.
| tguvot wrote:
| something like this https://en.wikipedia.org/wiki/Xperia_Play
| numpad0 wrote:
| Vita had a WWAN variant. What that means is, hardware wise it's
| trivial, business wise it's impossible. It's always has been
| that way. It took _Apple under peak Jobs leadership_ couple
| years to sell the iPhone globally.
| CMCDragonkai wrote:
| The phone is the critical root identity anchor for most of the
| world now. And many countries outside of the west has already
| made the Sim card a root identity. Additionally to make it
| trustworthy (think Google wallet and digital wallets and so on)
| to work they cannot trust the end user because effectively you
| the user don't own your own identity. So that's why the phone has
| to be proprietary - so that it's secure element can be trusted in
| interactions with the state-big-tech nexus. I talked about my
| experience with this while attempting to cross borders in SEA.
| https://polykey.com/blog/architecting-anti-fragile-trust-at-...
| vectraMosaic64 wrote:
| Two phones might be our sad reality, one for freedom, one for
| compliance.
| kobieps wrote:
| Good to see someone fighting the fight
| aussieguy1234 wrote:
| I suppose my PC's BIOS is a binary blob, yet I run open source
| Linux on that machine.
| floxy wrote:
| https://www.coreboot.org/
| fsflover wrote:
| But do you trust that it obeys you and not three-letter
| agencies or hackers?
| https://en.wikipedia.org/wiki/Intel_Management_Engine
| vfclists wrote:
| Looks like we will have to wait forever.
|
| I can't take these jokers seriously.
|
| Years after mobile phones came onto the market they are now
| planning to create their own phone.
| seba_dos1 wrote:
| Not sure, but perhaps it could be somewhat easier to take them
| seriously if you had actually clicked on the link instead of
| living in an alternate reality where it's about "planning to
| create their own phone".
| vfclists wrote:
| The FSF has never been a solid act.
|
| For years they have studiously ignored the fact that the
| mobile phone is the place where many people engage with IT
| and have been faffing about in the desktop and server space.
|
| Instead of leading they have always trailed behind. What they
| should have been doing was focusing on the software vision
| which they will most definitely screw up.
|
| Focus on the software vision and wait for the deblobblable
| hardware to emerge or commission their own hardware from
| scratch.
|
| I'm sorry but these guys have and will always be useless,
| much like the Wayland project.
|
| How many years has that crew taken to create something fully
| capable of replacing X11?
| drnick1 wrote:
| Someone hasn't read the article.
| vfclists wrote:
| These guys want to build on the Android foundation. I'm sorry
| but this will not work.
| neilv wrote:
| > _The FSF has been supporting earlier free software mobile phone
| projects such as Replicant,_
|
| Hopefully this project will go better than Replicant. Here are my
| notes on running Replicant on the (then already very old)
| flagship Samsung GT-I9300:
|
| https://www.neilvandyke.org/replicant/
|
| The hardware was a little difficult to obtain in the US, and WiFi
| worked only with a blob of questionable provenance.
|
| It looks like Replicant has been stuck for several years, and
| they recognize that they need to find a new device, funding, etc.
|
| (After Replicant, I spent some time on PostmarketOS with various
| devices, and then gave up and bought iPhones, and then got ticked
| off and moved to GrapheneOS.)
|
| I wonder whether the FSF is already collaborating with Purism on
| this, to leverage their work on the Librem 5 and PureOS, which I
| believe the FSF is well aware of. If the FSF manages to muster a
| lot more open source volunteers on a more affordable hardware,
| but that work is also usable for Librem 5, then it could be a
| win-win. (And Purism also has something called Liberty Phone,
| which is a made-in-USA Librem 5 phone, so their lawyers should
| talk about trademarks in any case.)
|
| https://puri.sm/products/librem-5/
|
| https://puri.sm/products/liberty-phone/
| nicman23 wrote:
| hahahahaha 2k for a phone that cannot last a day. yeah no. i d
| rather go for a redmi with postmarket os. it does not even have
| a blob free modem
| linmob wrote:
| That's their US made patriot phone, the regular less than
| half of that. Also, please read up on the concept of
| economies of scale.
|
| If you go with postmarketOS (good!), and don't want to touch
| anything that touched Purism, better avoid anything GTK
| (Phosh, GNOME Mobile and related apps). While Purism did not
| make a competitive phone, their investments into libre
| software went great and keep paying off.
| positron26 wrote:
| > If the FSF manages to muster a lot more open source
| volunteers
|
| First line of my pitch is, "When hundreds of millions of people
| need something, it doesn't make sense to wait for a handful of
| volunteers to build it for free."
| linmob wrote:
| I am pretty sure that it's not going to be the Librem 5,
| despite Purism's efforts to get it RYF certified (which,
| thinking of the Redpine WiFi card) went so far that they
| seriously impacted user experience.
|
| Why? There's no Android port for that device and they keep
| mentioning LineageOS.
|
| Even the PINE64 PinePhone would be more likely, as that has
| Android support and even some LineageOS 22 support [1]. The
| Replicant project had eyed it as a target device [2].
|
| That said, I'd expect a different device, and, assuming
| LineageOS supports one, and I would not be suprised to see a
| device that's not powered by a Qualcomm, Mediatek or Samsung
| SoC.
|
| [1]:
| https://github.com/GloDroidCommunity/pine64-pinephone/releas...
|
| [2]: https://blog.replicant.us/2024/03/replicant-status-and-
| repor...
| seba_dos1 wrote:
| You make it sound like the Redpine card ended up being shitty
| _because_ of RYF efforts. The Redpine card was chosen because
| of its internal flash, but the fact that the vendor failed to
| properly support the advertised features (and even removed
| some that worked before), abandoned its mainline driver and
| pretty much halted the firmware development after SiLabs
| acquisition is orthogonal to that and could have happened
| with a different card as well. So nice it was a replaceable
| M.2 card, isn 't it? ;)
| zozbot234 wrote:
| > Why? There's no Android port for that device and they keep
| mentioning LineageOS.
|
| The LineageOS folks are working on supporting their OS on
| Linux-first devices running a close-to-mainline (not AOSP)
| kernel. So it could go either way. Of course if they do
| choose an Android-first device, their efforts would
| ultimately also make it easier to run a mainline kernel on it
| as shown by projects like pmOS.
| seba_dos1 wrote:
| That's nice to know. Do you happen to have some links to
| where I could read up more on this effort?
| mschuster91 wrote:
| > That said, I'd expect a different device, and, assuming
| LineageOS supports one, and I would not be suprised to see a
| device that's not powered by a Qualcomm, Mediatek or Samsung
| SoC.
|
| Is there any actually relevant alternative to this oligopoly?
| Apple doesn't sell to third parties, NVDA lacks a baseband
| and so does (to my knowledge) Broadcom, and it's been ages
| since I saw anything from Intel in the mobile space.
| neilv wrote:
| I just noticed the part about FSF Librephone being based on
| LineageOS (therefore, Android).
|
| Has anyone told the FSF that it _isn 't_ "GNU/Linux"?
|
| I suspect that Purism has the better idea for a sustainable
| starting point for an FSF-ish phone.
|
| I'd be curious why FSF is barking up the Android tree again
| (the massive, intractable Android source code tree).
| nullbyte808 wrote:
| I highly doubt this will takeoff. I'm betting it never works
| beyond a couple outdated phones.
| lovelearning wrote:
| The concept of "outdated" is imposed by big tech itself through
| artificial restrictions. Apps are forced to update their
| minimum supported OS versions. Upgrades are stopped after 1 or
| 2 years. And so on.
|
| Anyone who has replaced Windows 8 or Windows 10 on their 5+
| year old machine with a distro like Xubuntu/Lubuntu realizes
| that "outdated" is often a sales propaganda term, not
| necessarily a technical term.
| numpad0 wrote:
| Why aren't they sending representatives to 6G standardization
| bodies? It's too late for 5G and under.
| Worldblender wrote:
| Finally! It took the FSF long enough to catch up with the
| overwhelming usage of mobile devices, but it's better late than
| never.
|
| I like that this project is trying to tackle something much more
| challenging that can't be done with just software: reverse
| engineering device firmware and binary blobs, the pieces of
| software that actually make hardware components interface with an
| OS. Understanding how this stuff functions is key to being able
| to write replacement software, so we may have less non-free
| software to deal with. I don't have any experience in trying to
| reverse engineer software, so the best I can do for now is cheer
| on from outside, unless I want to try my hands at this stuff
| later.
|
| I also like that this project is not intending to produce an
| Android-based distro, but focusing more on reverse engineering.
| Although I read that the results are targeted at helping
| developers of Android-compatible OSes, the results can hopefully
| be used by non-Android [GNU/]Linux distros and perhaps other *nix
| stuff, like the BSD distros. The FSF (by way of developer Rob
| Savoye) recognizing that a project like this is not going to be
| quick, easy, or cheap, and is a long term effort is good, as that
| likely means this project isn't going to be easily abandoned just
| because of not being able to produce quick results.
|
| I hope that this whole effort can eventually let us break free of
| the Apple-Google mobile device duopoly, as it sure is getting
| tiring for me to stick with one of these two companies for my
| mobile computing needs.
| r283492 wrote:
| > the results can hopefully be used by non-Android [GNU/]Linux
| distros
|
| That was stated as a goal at the FSF 40 event, videos of which
| should be online in the next few days.
| SchemaLoad wrote:
| I hate to complain, but I can't help but feel this is kind of
| impossible with the resources available to the people working
| on it. Reverse engineering a modern phone would take years and
| years of work from many people, and by the time you have it
| worked out, the phone is obsolete and very few people still use
| it.
|
| The Apple Silicon macbooks seem a good example. The M1 came out
| about 5 years ago now and with a whole project and a lot of
| work later there is still limited hardware support. Having to
| put this effort in for all the models of phones seems massive.
| NetMageSCW wrote:
| 1) The article states they are focusing on the phone model
| that they guess will require the least work to become totally
| free. This may make the project useless, but it does give it
| some hope of finishing.
|
| 2) The hope is that the M2-M5 won't be that different from
| the M1 models - after all, Apple doesn't want to spend their
| money reinventing the wheel without compelling reason. I
| think that is less likely with phones from different
| manufacturers, though Android phones typically share a lot of
| single source components.
| fsflover wrote:
| > The hope is that the M2-M5 won't be that different from
| the M1 models - after all, Apple doesn't want to spend
| their money reinventing the wheel
|
| From the Asahi Linux website, M2 is sufficiently similar to
| M1, while M3 and M4 won't likely be supported soon due to
| significant differences.
| zozbot234 wrote:
| They're aiming to perfect their support for M1/M2 prior
| to working on the M3 and later models. Seems like a
| sensible choice, given that even a baseline M1 or M2 Mac
| is still a highly compelling device for a vast majority
| of uses. And Asahi will become more relevant as these
| devices cease to be supported by newer releases of macOS.
| kace91 wrote:
| One would hope that enough things stay similar between
| devices that replacing, say, the galaxy s25 paves the way for
| a far easier implementation of the s26, particularly now that
| the market is stagnating a bit.
|
| And I'm not knowledgeable about this at all, but intuitively
| I'd expect apple stuff to be much more customized than the
| average android phone - they're famous for vertical
| integration and owning the end to end process.
| pjmlp wrote:
| Phones aren't x86, each is own snowflake, and on Android
| the nature of being a managed userspace, means there is a
| certain freedom regarding which ARM designs that Samsung,
| Qualcomm, Mediatek, and whatever else is out there comes up
| with.
|
| Then there is everything else that happens to be on the
| motherboard.
| mcny wrote:
| The camera is also surprisingly software dependent. Using
| the pixel camera vs using default configuration with an
| app called open camera, the difference is so clear. The
| camera is basically all software -- the images are pure
| trash before processing.
| kace91 wrote:
| >Using the pixel camera vs using default configuration
| with an app called open camera, the difference is so
| clear.
|
| Is this hardware dependent though?
|
| I ask because I've seen custom android mods that port the
| pixel camera, presumably if that works for other devices
| it's a good sign that postprocessing can be decoupled
| from specific hardware.
| VGHN7XDuOXPAzol wrote:
| I, too, have noticed this. Would be curious if anyone has
| a more in-depth article to read about _why_ the
| difference is so stark!
| qingcharles wrote:
| Can you access the camera, though? I thought full access
| to the camera sensor was locked down only to awful
| Samsung apps?
| SchemaLoad wrote:
| It's been many years since I did android rom stuff but
| how it was back then was that yes you can access the
| camera, but you lose the proprietary image processing
| pipeline which exists just as software. So your photos
| come out looking much worse since phone cameras rely
| heavily on software to look good.
| sznio wrote:
| >by the time you have it worked out, the phone is obsolete
| and very few people still use it.
|
| If you work out a phone from 5 years ago, you're not that far
| off from a phone of today. Nobody designs it all from
| scratch, you mostly modify the old one. Getting the
| foundations going will take years - adapting the foundation
| to a different phone of the same series will only take
| months.
| wrasee wrote:
| Hardware is hard. It doesn't always have the transparent
| composability that software has because you hit physics and
| the real world.
|
| The example already given makes the point. Work has been
| great on the M1 but my understanding is that this has not
| translated all that well to e.g. M2, M3 and M4.
| eptcyka wrote:
| When it is this late, it might as well have been never.
| goku12 wrote:
| That's certainly not the case here, even if it's true
| sometimes. The duopoly is gradually tightening their grip on
| the customers' wallets. It's worth it at any stage to reverse
| their cash grab.
| pjmlp wrote:
| This is bound to fail unless they get the full stack and
| even then, it will be for specific phone models, x86 is an
| anomaly in having a cloning freedom that IBM did not
| intended.
| fsflover wrote:
| https://news.ycombinator.com/item?id=27897975
| pjmlp wrote:
| If you think just by using Librephone powered device is
| going to be safer, good luck.
| fsflover wrote:
| https://news.ycombinator.com/item?id=19870406
| eptcyka wrote:
| Open firmware is but one part of the equation. The
| evolutionary pressure of state actors trying to deploy
| malware on iOS and Android forces those platforms to
| develop vulnerability mitigations and security
| architectures that currently just are not matched by
| anything in FOSS. Desktop linux is woefully insecure
| compared to these platforms. I don't want it to be, but
| it seems that, unless you are ready to use Qubes, no one
| has the time and effort to further the security of
| desktop linux in any meaningful way.
| a456463 wrote:
| Been running the latest lineageos without google crapware on
| oneplus 6. It is amazing
| system2 wrote:
| Let's hope the phone's ui won't look like FSF's website.
| realaaa wrote:
| ahahaha too true
|
| but actually these kind of websites are way more informative
| also
|
| instead of "clean" look where everything is just fluffed up
| aitchnyu wrote:
| It will be much easier on the eyes (and perfect IMO) if font
| size changes from 13 to 16, and all line heights like 1 are
| fixed to 1.5.
| wltr wrote:
| To me this feels like blah blah blah, but I'd love to be very
| wrong, of course.
| z3ratul163071 wrote:
| thank god.
| pjmlp wrote:
| All the best for the efforts, however I am bin long enough around
| this planet to not have big hopes how this will turn out.
|
| Phones aren't x86 hardware, which only got open due to a lucky
| event, regretted by IBM.
| classified wrote:
| I want this, even if it means we have to pay some of the people
| who work on this.
|
| > _Librephone will serve existing developers and projects who aim
| to build a fully functioning and free (as in freedom) Android-
| compatible OS._
|
| It may well be that Google will not rest until "Android-
| compatible" means that they can put their foot down on this. We
| should be prepared for that eventuality.
| gorgoiler wrote:
| It is very inspiring to see a project announced like this with
| the developer's name attached to it. As someone who has always
| struggled with the confidence to be open about my work, let alone
| work openly in public, it feels extremely inspiring to see Rob
| Savoye (and Zoe and John behind him) nail their plans to the door
| like this.
|
| My thrill is matched in strength by the loathing I have for this
| Apple device on which I type, whose entire boot process is
| miserably locked down from the very start. It is like a bicycle
| made from Mickey Mouse logo bolts where the spanners are
| proprietary and not for sale. The situation is just as ludicrous.
|
| The two major phone OS companies both stand on the shoulders of
| IBM PC, openly bootable hardware, and the fantastic software
| systems nurtured and built on top of these platforms -- the BSDs,
| GNU, Linux, and the long tail of all that run on them. It is very
| troubling that their own platforms are the antithesis of being
| openly hackable.
|
| Librephone could be successful in a few ways. Outright, as a
| device, but also as a carrot to bring open handheld hardware to
| enough people to drive political change (with a small-p, the
| politics of society, as well as politics of the big-p kind) such
| that iOS and Android would have to follow suit. With actual
| public policy Librephone could also end up being a stick:
| bringing about legislation that _requires_ computers of any kind
| to be able to boot software of our choosing. Right-to-repair plus
| plus, if you will.
|
| With enough Librephone devices in the right hands, either the
| market or the law will demand that we have the same openness and
| freedom to use our devices the same way we do commodity x86
| hardware today. The same freedom imprisoned and exploited in the
| core of mine and your phone, right now.
| yjftsjthsd-h wrote:
| > The two major phone OS companies both stand on the shoulders
| of IBM PC, openly bootable hardware, and the fantastic software
| systems nurtured and built on top of these platforms -- the
| BSDs, GNU, Linux, and the long tail of all that run on them. It
| is very troubling that their own platforms are the antithesis
| of being openly hackable.
|
| I can kinda see a lineage from the PC to Android, if only by
| way of Linux being born on the 386. But Apple? They've been
| doing their own thing since day 1; I can easily imagine a world
| where IBM never existed and the iPhone is unchanged.
| gorgoiler wrote:
| It's a fine thread, but the links from FreeBSD to Darwin are
| real, and Darwin is behind macOS and iOS. Not just as a
| kernel, but a lot of the runtime and many of the auxiliary
| pieces of software too.
| germandiago wrote:
| I am a fan! I have missed this for years.
| BLKNSLVR wrote:
| Meta-commentary: At least within the HN community there seems to
| be a strong interest in a pursuit such as this, given that this
| is at the top of the front page, and has been for a little while,
| plus the first page has simultaneously contained these two
| stories:
|
| https://news.ycombinator.com/item?id=45584498
|
| https://news.ycombinator.com/item?id=45585869
|
| It's heartening.
| squarefoot wrote:
| I applaud the move, but it's going to be really hard if
| manufacturers aren't willing to document their chipsets and keep
| bootloaders locked. The folks at Pine64 were forced to waste
| resources to develop their own platform, which after the enormous
| effort ant time invested resulted outdated the day it came out of
| the factory, because of that.
| rcarmo wrote:
| Well... mixed feelings here. I spent a lot of time dealing with
| early smartphones and hacking away at Android, Tizen, FirefoxOS
| (remember that?) and several variations on that theme back when
| manufacturers were vying for differentiation, and I get that the
| FSF has a mission, but I don't see this panning out.
|
| Like many folk who've been watching Google's gradual shutdown of
| AOSP and alignment with Apple in terms of platform lockdown, I
| think the days of fully open devices are actually coming to a
| close. Again, I applaud the FSF's initiative, but you need to get
| a lot of buy-in for this kind of thing to work---manufacturers,
| developers (both OS and app devs), and, of course, users, who
| will never accept anything that doesn't let them do things like
| banking, shopping, mainstream social apps, etc.
|
| And you can't do a lot of those on an unlocked boot loader (which
| I think is going to be the logical consequence of replacing bits
| of the OS) without more hacking. It's like XML and violence---it
| will only lead to more of the same.
|
| I expect the usual amount of "you can do that with web apps"
| pushback, but let's be real. Except in markets like India where
| simpler and vastly cheaper platforms make sense, you either use
| iOS, Android, or... nothing but voice calls, and I don't see
| enough here to make me think this will be something for everyone.
| masfoobar wrote:
| I understand your views.
|
| However, I still stand by the idea of having options. Many of
| us in developed Countries are likely to remain on our IPhones
| or Androids, but there is still a chance for FSF to shine in
| other areas.
|
| Also, as someone who was a FirefoxOS user (I think around
| 2011-2016) I am always open to replacing my Android with FREE
| (as in freedom) alternatives.
|
| As I mentions in previous comments - the main "fight" is
| convenience vs freedom.
|
| Either we have the convenience of being able to do things on
| our devices with little effort of all (with variations of
| lockdowns and/or less control)... or we run something that
| respects your freedoms but some things require a few more
| seconds/minutes to do.
|
| Personally, I would choose the latter. However, I know I am the
| minority in the world of phones.
|
| Don't get me wrong. I am not some freedom(software) fighter. I
| accept that there is a convenience I need on phones today. In
| the workplace, I need MS Teams. If I don't have this, my
| Company will have to offer me a Work phone. Other than this, I
| do use it for banking, map navigation, etc. However, these are
| not deal breakers for me.
|
| Also, we have the convenience with AI, which more and more will
| adapt like a special friend, will make things ever harder in
| the freedom world. Be interesting to see how this evolves.
|
| At the end of the day - things change. It's hard to think like
| this but we don't know what we will be using in the next 10
| years. Maybe in this universe, Microsoft Windows might still be
| king in the OS world. However, in another Universe Microsoft
| ends up making too many poor decisions even businesses are open
| to alternatives.
|
| It's the same thing for smart devices. Apple might make a
| STUPID decision in the next 10 years. Although we still have
| Android variants on the market, the Librephone might get a big
| push by ex-Apple users.
|
| We shall see. If this project does well and can do certain
| types of "convenience" then I would be willing to try it!
|
| It is always a pleasure to have something with convenience but
| does not cost my freedom.
| demaga wrote:
| > you can do that with web apps
|
| And this is not even always possible. In Ukraine, government
| app is released as an app, not a web service. Same goes for
| banking app. You just can't do these things from other devices,
| you must have (mainstream) Android or Apple phone.
|
| I've been looking into projects like GrapheneOS for a while
| now, but it is just impossible to use in Ukraine.
| franga2000 wrote:
| If it's a government app, you can pressure the government in
| many more way than you can let's say a bank - and FSF has
| experience in that kind of pressure. I hope their technical
| initiative also comes with a parallel legal/policy initiative
| that tries to get governments to stop using things like
| attestation.
| ZoomZoomZoom wrote:
| > If it's a government app, you can pressure the government
| in many more way than you can let's say a bank
|
| Many more, like?
|
| For an individual, almost none. I can boycott a bank (if
| it's not a government one), I can't boycott my own
| government, only leave.
|
| An organization can start an initiative, but without an
| interested party involved it's only an initiative, you can
| hardly call it "pressure".
| franga2000 wrote:
| You can't boycott a bank, they all do the same shit and
| you need to have one.
|
| With a government, however, you can go through your MPs,
| use administrative procedures to lodge complaints, etc.
| They also don't have Visa/Mastercard forcing them into
| attestation, it's usually just because the contractor
| thought it made things More Secure(tm).
| zozbot234 wrote:
| > ..users, who will never accept anything that doesn't let them
| do things like banking, shopping, mainstream social apps, etc.
|
| Plenty of users are now buying feature phones that don't come
| with these features. Think of a libre phone as a uniquely user-
| focused, distraction-free device that still allows for a core
| smartphone/PDA compute featureset.
| devjab wrote:
| As an EU citizen the biggest issue for me is that even if I
| bought a fairphone with grapheneOS, it might as well be a
| "dumb" phone. This is because all the apps to make our daily
| lives non-annoying require the Google Play or the Apple App
| store. So to me it's the lack of digital sovereignty from the
| EU and our individual countries that is the main issue. Sure it
| would be nice if big tech didn't close their platforms, but
| that ship appears to have sailed. If they ever get around to
| making these apps available through a different store, then I
| don't see why I wouldn't want a different OS.
|
| We still need open hardware and more companies like fairphone
| to utilize it, but we primarily need the EU to get it's act
| together and break the reliance on big tech app stores. I know
| there are a few companies trying to build app stores with the
| necessary security compliance and if the EU wants to be serious
| about digital sovereignty it'll need to support these.
| bogwog wrote:
| > As an EU citizen the biggest issue for me is that even if I
| bought a fairphone with grapheneOS, it might as well be a
| "dumb" phone. This is because all the apps to make our daily
| lives non-annoying require the Google Play or the Apple App
| store.
|
| This is a common misconception I see around here, probably
| because people think Graphene is yet another custom rom like
| LineageOS, and haven't actually tried it for themselves.
|
| GrapheneOS supports Google Play (it ships with an app that
| lets you install it in one click), it does NOT give you root
| access, and it goes through the extra effort of implementing
| the obscure security features that banking apps require. I
| won't say 100%, but maybe 99% of apps on Google Play will
| work on Graphene, including banking apps. This compatibility,
| along with the added security and privacy features are why
| it's such a big deal. It's not just hype around the latest
| shiny custom ROM.
| NoGravitas wrote:
| Banking apps will work on Graphene _if_ you have sandboxed
| Google Play Services installed, and _if_ the banking app
| requires only a basic level of Play Integrity attestation.
| I got the same level of support with my previous LineageOS
| for MicroG phone as I have with my current GrapheneOS
| phone, it just required a lot more tinkering (and was a lot
| less secure).
|
| I do appreciate the work the GrapheneOS team puts in toward
| compatibility, and especially the fact that they just got
| RCS messaging working. But any time Google or even an app
| vendor wants to tighten the noose, they can, just by
| requiring the higher, hardware-backed attestation level.
| bogwog wrote:
| https://grapheneos.org/articles/attestation-
| compatibility-gu...
|
| That page seems to be saying the opposite: hardware
| attestation would support GrapheneOS, whereas the Play
| Integrity API would not.
|
| Anecdotally, both of the banking apps I use 'just work',
| and I haven't encountered any app that doesn't work. The
| closest thing was the Disney parks app a few years ago
| which would crash on launch until I disabled the hardened
| malloc feature for it.
| pabs3 wrote:
| I see "... and permitting our official release signing
| keys" there, which means you are swapping Google Android
| for GrapheneOS Android, and you can't use bogwog Android
| if you wanted to.
|
| There is a list of apps banning GrapheneOS keys here,
| including govt apps, ticket apps, and McDonalds for some
| reason:
|
| https://grapheneos.org/articles/attestation-
| compatibility-gu...
| bogwog wrote:
| > you are swapping Google Android for GrapheneOS Android
|
| No? You're adding support for Graphene's keys, not
| replacing Google's. Obviously, the main barrier is
| convincing developers of these apps to add support for
| Graphene's keys. However, this is only a problem for apps
| that opted to implement the Play Integrity API at all,
| which doesn't seem to be very common. All the recent
| monopoly rulings against Google may be deterring devs
| from implementing this obviously anti-competitive
| feature, and that's not to mention Google's new
| responsibility to offer the Play store app catalog to
| competing stores, thanks to the Epic case.
|
| > The injunction issued last year by U.S. District Judge
| James Donato requires Google to allow users to download
| rival app stores within its Play store and make Play's
| app catalog available to competitors. Those provisions do
| not take effect until July 2026.
|
| (source: https://www.reuters.com/sustainability/boards-
| policy-regulat...)
|
| Maybe they'll get away with requiring competing stores to
| implement Play Integrity API, maybe (probably) not.
|
| Also, that list of incompatible apps is probably out of
| date since I use the ebay app all the time with no
| issues.
| pabs3 wrote:
| My point was that this situation doesn't allow for
| Software Freedom, since you the user cannot control the
| OS, its an unmodifiable blob unless you are either
| someone with a blessed key (like Google, or GrapheneOS
| devs), or are willing and able to to go without the apps
| that use the attestation APIs, or have one locked down
| device for attestation apps and a separate one that you
| can actually control. Probably the only way to deal with
| that is make attestation to third parties illegal, I
| assume governments and banks would get exempted from such
| laws though.
| NoGravitas wrote:
| Android has a hardware attestation API that is compatible
| with GrapheneOS (if the app accepts GOS's keys), but
| nobody uses it. Everyone uses the Play Integrity API;
| GrapheneOS can't pass the "strong" (hardware-backed)
| level of Play Integrity, though it passes the weaker
| ones.
| cookiengineer wrote:
| Why can't they just partner with postmarketOS here?
|
| Why do we have to have /e/OS instead of a better supported
| LineageOS, because /e/ is a 1:1 copy anyways?
|
| Why do we have to have a Librephone project now instead of
| partnering with say, Fairphone and the Pine64 people?
|
| Open source loses this war because proprietary devices are
| streamlined. The only thing that comes close to this is
| GrapheneOS, LineageOS, and postmarketOS.
|
| LineageOS has huge problems since the mandatory eBPF requirements
| of late Android versions, which postmarketOS and its upstreamed
| kernel drivers could fix. GrapheneOS has huge problems because of
| Pixel devices, which LineageOS could help with.
|
| We need a unification of this ecosystem because each on their own
| is hardly surviving on their own against the megacorporations.
| realusername wrote:
| I agree about postmarketOS but eOS isn't the same as Lineageos,
| I used both and they are pretty different. eOS wants to have
| its own non-Google ecosystem which is a non-goal for Lineageos
| rjdj377dhabsn wrote:
| Why is eBPF a problem?
| cookiengineer wrote:
| A lot of functionality of newer Android releases
| (Android/AOSP 13 and later) rely on eBPF [1] for both
| interception of process insights and sandboxing of processes.
| eBPF in a nutshell is a way to build kernel hooks, so that
| you can also disallow or intercept syscalls or kernel API
| calls that the Apps are executing behind the scenes.
|
| eBPF was introduced with Kernel 4.14 officially (but partly
| long before that). Most LineageOS supported devices still
| rely on older kernels, the most range being around the Kernel
| 4.4 or 4.9 branches, which lack that eBPF functionality. The
| LineageOS maintainers were backporting a lot of things
| already, but that's the "hardcut of now unsupported legacy
| devices" that people are experiencing with their old phones.
|
| The issue here is that upstream vendors (e.g. Fairphone,
| actually meaning upstream Qualcomm IoT) only maintain their
| outdated kernel versions, and never maintain them in the
| sense of updating their driver code into newer kernel
| releases. The drivers are always stuck in an outdated state
| of a feature frozen kernel.
|
| I'm just making this specific example with the Fairphone
| because "5 to 8 years support" isn't what most people would
| think it is. It means "only the really critical security
| patches of old stuff gets backported" and does not mean "hey
| we migrated our old code to a new kernel and Android
| version".
|
| For example, Fairphone 1, 2, 3, 3+ are all stuck in old
| kernels right now (4.9 being the latest backport for the
| FP3+) and are essentially not updatable because of this.
|
| I don't try to blame Fairphone here, because other
| manufacturers are much much worse in this regard. Fairphone
| and Pixel are already the "as good as it can get" for third-
| party ROMs case.
|
| I mentioned postmarketOS specifically, because they're trying
| to fix that by upstreaming the kernel drivers, so that Linux
| support of those devices will stay updated with newer kernel
| releases (hopefully).
|
| [1]
| https://source.android.com/docs/core/architecture/kernel/bpf
| saagarjha wrote:
| I don't think Android is really using eBPF for much. Last I
| remember they were loath to adding more things and they've
| definitely locked away the ability to load arbitrary new
| programs because they couldn't secure the attack surface it
| opened up.
| TranquilMarmot wrote:
| Supposedly Graphene is partnering with a major OEM (they say
| "one of the top 10") to get better hardware support. Even then
| they're still at the whim of Google, though - the most recent
| QPR1 update still has not been pushed to AOSP even after many
| weeks. Supposedly partnering with an OEM means they get these
| updates quicker but who knows.
| styanax wrote:
| You may have missed this, it's only been ~11 days since the
| post but they've got a solution now, with the first release
| having happened:
|
| https://discuss.grapheneos.org/d/27068-grapheneos-
| security-p...
| TranquilMarmot wrote:
| This is a security patch which is different from the QPR1
| release. _Supposedly_ once they partner with an OEM they
| will get more reliable access which would be nice, but I'm
| hesitant. I switched my Pixel 8 Pro to Graphene a few
| months ago and really like it.
| bebna wrote:
| I got an FP5, would not buy again.
| haltcatchfire wrote:
| Could you elaborate on why? This type of comment doesn't add
| any value.
| dddw wrote:
| Can you elaborate?
| boudin wrote:
| I got a FP4, will definitely buy again.
| GTP wrote:
| I considered purchasing it, but ultimately turned it down due
| to its size. What's the reason you're not liking it?
| guerrilla wrote:
| I like the size. I do not like the weight. I love the phone
| overall though. Love love. Good choice despite downsides.
| beeforpork wrote:
| We bought two FP5 with e/OS/ from Murena (for spouse and
| myself), and would buy again. Why wouldn't you?
| palata wrote:
| I don't like how /e/OS claims everywhere that they support
| all those phones, when in all my experience they just can't
| keep up and I end up with phones that don't receive vendor
| firmware updates for 1+ year.
| fsflover wrote:
| Why are all commenters on HN ignoring the only smartphone
| running an FSF-endorsed [0] operating system, Librem 5, and
| only list everything else? I just can't get it.
|
| Even the FSF themselves didn't mention it or provided any
| reasoning for choosing a Google-controlled operating system -
| despite recommending Librem 5 earlier [1]. What am I missing?
|
| [0] https://news.ycombinator.com/item?id=25504641
|
| [1] https://www.fsf.org/givingguide/v11/
| rjsw wrote:
| We know that you will post something about Librem 5 so there
| is no need for anyone else to do it.
| gessha wrote:
| It's amusing to me that whenever I see a submission about
| Linux phones, I start looking for the obligatory @fsflover
| comment.
|
| No bad feelings, fsflover, keep up the good work. I also
| can't wait to post on here from a libre phone.
| tyler-dot-earth wrote:
| as someone who has followed this phone for a long time, it
| has had an image problem - fairly old hardware, early
| software/buggy, and bad customer service experiences.
|
| i'm still pretty tempted to play with one.
| fsflover wrote:
| > fairly old hardware
|
| How new do you think the chosen Android hardware will be at
| the end of the promised reverse-engineering efforts?
|
| See also: https://puri.sm/posts/the-danger-of-focusing-on-
| specs/
|
| It's fast enough and stable enough to serve me (and many
| other people, including in the HN comments) as a daily
| driver.
|
| > bad customer service experiences
|
| This depends: Purism is a quite small company, and
| sometimes they take time to reply, but the community at
| forums.puri.sm has been really helpful. I'm a happy user.
| closeneough wrote:
| This project is about reverse engineering the firmware blobs.
| It states that they do not want to create a distribution like
| postmarketOS or other projects do.
| fsflover wrote:
| The listed distributions have already been created. The OP
| didn't suggest to create a distribution but to collaborate
| with existing ones not relying on the Google's OS.
| pessimizer wrote:
| Graphene and Lineage both rely on Google's OS, so this is
| not what the OP was saying.
| fsflover wrote:
| Did you miss postmarketOS in the OP's post?
| Itoldmyselfso wrote:
| > GrapheneOS has huge problems because of Pixel devices, which
| LineageOS could help with.
|
| What are these "huge problems" caused by Pixel devices?
| franga2000 wrote:
| Probably that Google is dragging their feet releasing Pixel
| kernel and other source code. LineageOS has many years of
| experience getting a working system on top of bad or
| incomplete sources, including getting kernel source out of
| vendors in the first place.
| palata wrote:
| > dragging their feet releasing Pixel kernel
|
| Isn't it only the device tree, and therefore only affecting
| initial support for the Pixel 10?
|
| Doesn't feel like a huge problem, though it makes it harder
| to support the Pixel 10.
| moffkalast wrote:
| I will never use GOS as long as it requires me to buy a
| Pixel, on principle, because it's made by Google. It's like
| having to buy a Microsoft Surface in order to use Linux.
| bbarnett wrote:
| You can use an older pixel, thus not really giving money to
| Google, and also preventing that phone from landing in a
| landfill. Without all that Google and carrier excess junk
| on board, an older phone is fast.
|
| You can buy a new pixel, install GrapheneOS, and laugh
| thinking about how you're denying the enemy the OS level
| tracking they wanted with that device.
| notrealyme123 wrote:
| But you still support Google and the closed source
| Android ecosystem with that.
| hsbauauvhabzb wrote:
| You could offset that by convincing others to use
| graphene, and by degoogling your device you're also
| cutting off one of their other income streams
| palata wrote:
| The reason why GrapheneOS only supports the Pixels is that
| the other manufacturers are not trying to get their shit
| together and release a phone that is reasonably secure.
| It's not that GrapheneOS supports Google, it's just that
| the other manufacturers are worse than Google.
|
| If a major manufacturer released a good smartphone that
| GrapheneOS could support, they would get new users from the
| set of people who want GrapheneOS. I would gladly buy a
| non-Pixel as long as it can run GrapheneOS.
|
| Which means that in a way, if you buy a Pixel and install
| GrapheneOS, you give more credibility to GrapheneOS, making
| it more interesting for a different manufacturer to
| consider supporting them.
| fsflover wrote:
| https://news.ycombinator.com/item?id=45208925
| wolvesechoes wrote:
| Why do we have to have million Linux distros? Why do we have to
| have dozen desktop environments?
|
| Because in FOSS world every single actor is a snowflake with
| unique vision. Any form of cooperation ends up in drama and
| moral accusations.
| fsflover wrote:
| Why do we need so many car models and manufacturers?
| mcny wrote:
| I don't mind the many multiple distributions but the
| default experience really sucks.
|
| For example, there should only ever be one clipboard by
| default. If power users want multiple, they can go out of
| their way to configure their device config as such.
| Similarly, the function keys should function as function
| keys on a keyboard out of the box, without us having to
| fiddle with config files. Also the scroll wheel click to
| scroll should work out of the box without requiring editing
| config files. The default experience is still pretty poor.
| wolvesechoes wrote:
| We don't.
|
| But as soon as FOSS orgs will obtain resources comparable
| to those of car companies I will stop complaining.
| notrealyme123 wrote:
| So what exactly is the problem? To many options?
| j45 wrote:
| The options thinking they're an island retreat only for
| those who agree with their way while standing on the same
| continent.
|
| What's missing is building something that resonates with
| the user/consumer's experience backwards, not just personal
| preferences or interpretations, which is fine, but at that
| point it's a personal project, not a product, or much
| larger unless it really captivates both people who can
| contribute to creating it and also it is adopted quite
| easily.
|
| Creating beginners can seem like something too many OSS
| projects can be allergic to. It's the greatest sin of too
| many projects, and they ultimately can't be freed of it.
| t43562 wrote:
| Either software is free or it isn't. You can't have
| single-vision-central control _and_ freedom. Android is
| an example of an effort that took something free and made
| a usable mobile operating system ontop of it - but lead
| straight back to the problem that it isn 't fully free.
| wolvesechoes wrote:
| Hm, there is also an option to avoid creating yet another
| fork the moment someone said something unpopular, or to
| try helping improve existing solutions instead of
| creating yet another cool project that achieves nothing.
|
| Of course no one can be forced to do so, but that's the
| problem - FOSS crowd would have to actually forced to
| cooperate, because otherwise petty dramas sabotage any
| common effort.
| t43562 wrote:
| Forks happen, I think, because someone doesn't agree with
| the direction or can't get accepted into the clique of
| people working on something.
|
| So if you tell them it's evil to fork you're saying, in
| effect, stop working.
|
| I have lots of new functions for GNU make but the chance
| of getting them into make is almost 0 because the
| maintainer doesn't like this or that aspect of anything.
| Fortunately, I can make a fork. If people eventually show
| a desire to use my fork (nobody, unfortunately!) then he
| might eventually change his mind or develop some
| competing feature to kill mine off.
|
| That's what is happening. To get people to pull together,
| they have to have a reason, like money.
| j45 wrote:
| Graceful forking is different than .. what too often
| happens with keyboard warrioring.
| raverbashing wrote:
| > You can't have single-vision-central control and
| freedom
|
| But that's how a lot of projects do: Apache for instance,
| nginx, or llvm.
|
| The problem is not being OSS, it is the lack of focus,
| and a game where everybody brings their ball and are
| playing the way they want instead of an unified game
| t43562 wrote:
| To take LLVM as a convenient example ... why does it
| exist? Why didn't Apple pour its money into GCC?
|
| Why does nginx exist? They could simply have found that
| config bug in Apache that made Apache slower and we
| wouldn't have needed another web server...?
| gitgud wrote:
| The FOSS world is primarily about freedom. You don't have to
| align with someone else's vision, you don't need to be
| profitable, you don't need to care about other projects
| wolvesechoes wrote:
| How's the computing freedom for general audience? Better
| than ever, right?
| mixmastamyk wrote:
| A.k.a. not getting paid, so you might as well do what you
| want.
| zozbot234 wrote:
| > LineageOS has huge problems since the mandatory eBPF
| requirements of late Android versions
|
| It's a mixed bag. The eBPF requirement makes it harder to
| support newer AOSP versions on very old downstream kernels (you
| now need a close-to-mainline port, like what pmOS aims to
| provide) but because it _is_ a requirement, it will make it
| easier for newer devices to run a more up-to-date kernel
| starting from the available downstream sources.
| m4rtink wrote:
| Mobile software is unfortunately not really a lego that can
| always be combined at will.
|
| In your examples you compare Android rebuilds with real Linux
| distros. The projects also have quite different goals
| (providing full manufacturer ROM replacement for Android on
| Lineage OS to reusing any old hardware to basically run servers
| on PostmarketOS).
| feitingen wrote:
| That's not entirely true.
|
| Most PostmarketOS devices start out using LineageOS kernels,
| and many are atill using those.
|
| Why not use PostmarketOS kernels on LineageOS?
|
| The ultimate goals are different, but cooperation on
| upstreaming kernel work would benefit both.
| zozbot234 wrote:
| LineageOS kernels are AOSP downstream kernels, and
| PostmarketOS has expressly deprecated their use. LineageOS
| is now working on running their system on close-to-mainline
| kernels, as provided by PostmarketOS and most Linux
| distributions.
| fsflover wrote:
| > Mobile software is unfortunately not really a lego that can
| always be combined at will.
|
| If we're talking about the mainline Linux, then it this looks
| exactly like a Lego to me. I hope that FSF will concentrate
| their efforts on that.
| j45 wrote:
| You have a good point about things coming together, but open
| source often is a lot of design and development by committee,
| or interest.
|
| Librephone appears to be taking existing linux approaches, and
| specifically reverse engineering the SoC blobs to be completely
| free. I may have mis read, but it doesn't appear they are
| building another android distro for android phones, as they
| already have done that in the past.
|
| Just tried to learn the difference between these and it seems
| like:
|
| - Graphene - For current devices only - An alternative for
| phones that are supported and updated by Google. Security
| Patches, etc.
|
| - LineageOS - For devices while they're supported or may not be
| updated that often. Support can be sometime by community
| members.
|
| - PostmarketOS - devices that no longer have a maintained
| Android version for it, can just become a linux computer.
| Mobile functionality doesn't necessarily.
|
| Some phone chips overtime end up having a hardware security
| flaw that software can't fix.
|
| I really enjoy using Android. Part of the issue is not all
| deices get timely security updates, even if they get monthly
| updates, the updates might be from 6 months ago. Google might
| release a security patch but sometimes it has to go through the
| device manufacturer, and maybe even the mobile company. Pixel /
| Android pure installs seem to improve this a bit, but it's hard
| to have complete trust.
| oblio wrote:
| Librem?
| sznio wrote:
| From my understanding of the article, Postmarket or Lineage or
| any other mobile operating system will be able to make use of
| this project. The goal is to provide FOSS drivers, so that you
| can run Lineage without proprietary blobs copied from the
| distribution of Android provided by the device manufacturer.
|
| It's mainly a libre purity project. A Lineage user won't be
| able to tell a thing, but the system will be "ethically pure"
| fsflover wrote:
| > Postmarket or Lineage or any other mobile operating system
| will be able to make use of this project.
|
| Any OS "is able" to use anything from any other OS - in
| theory and given infinite resources. In practice though, it
| makes a huge difference when something works by default.
| ric2b wrote:
| No, software licensing often gets in the way.
| fsflover wrote:
| How does the licensing affect firmware blobs?
| jrochkind1 wrote:
| They are also software that is licensed?
| fsflover wrote:
| AFAIK you can use and reverse engineer the firmware blobs
| on any OS, free or not.
| devmor wrote:
| I wonder if it's one of those situations where the
| potential for legal system abuse is a chilling effect.
| fsflover wrote:
| Can you elaborate?
| devmor wrote:
| Such as when it's technically legal to do something as
| long as you do it a certain way, but the interested
| parties may not believe that you did it correctly and
| will bury you in legal discovery requests that
| financially ruin you or force you to stop.
|
| Or they sue anyways hoping for a favorable ruling that
| changes the interpretation of the law (Oracle v. Google
| for a famous example of this)
| jrochkind1 wrote:
| Legally, you mean? In the US? Interested in more info on
| this.
| M95D wrote:
| Sure.
|
| https://en.wikipedia.org/wiki/Clean-room_design
| jrochkind1 wrote:
| That doesn't make sense to me, extracting/copying a
| firmware blob is not clean-room design. It would only be
| clean-room design, as the article you link to explains,
| if you constructed it yourself from scratch based on the
| functionality you understand it should have. But ok!
| xoa wrote:
| You might have gotten lost on the steps involved in
| clean-room reverse engineering here?
|
| > _extracting /copying a firmware blob is not clean-room
| design_
|
| It's stage 1. Clean-room reverse engineering is about
| working with the nature of copyright, and classically
| goes roughly like this:
|
| 1. You set things up with a "contaminated" or "dirty"
| side team who have direct exposure to the IP in question,
| and a "clean" (or "virgin" is another older term) side
| team that are thoroughly firewalled. The clean side must
| only have devs who have never ever had any exposure to
| whatever it is you're trying to clean replicate [0].
|
| 2. The dirty side is in charge of producing a "fact
| sheet"/spec. That side absolutely extracts/disassembles
| or whatever else to get at the target, which is precisely
| what "contaminates" them. They are looking at copyrighted
| code. Then they use that research to a create a purely
| factual spec, which is then passed across the firewall to
| the clean side. This must be the _only_ communication.
|
| 3. The clean side then uses that to write new code
| themselves that will handle state per the factual spec
| they've been given.
|
| The reason it works is that (in the US) purely factual
| information cannot be copyrighted, there's no "sweat of
| the brow" doctrine or the like. Copyright, unlike
| patents, does not cover ideas or methods, it's about the
| creativity of the person in question. You can't
| _copyright_ the mathematics of a function, of "when X
| input is received Y is output", or of general concepts.
| So if two (or more) people independently create works
| that happen to cover the exact same subject matter, but
| can prove they were fully independent, then it doesn't
| matter even if it happened to be literally identical
| (however improbable that would be). Each would have their
| own independent copyright on it.
|
| So clean-room RE avoids all the legal snarls around "how
| close is this" in favor of the simple binary question of
| "did the team that wrote this RE'd code have any exposure
| whatsoever to copyrighted IP?" If the answer to that is
| "no" that's the end of any legal complaint, because by
| definition their output cannot be a derivative work.
| Software patents short circuit that, part of the many
| reasons they're evil, but as a practical matter the
| number of really fundamental hard to avoid ones is
| rapidly shrinking because it's 2025 and by 2005 a lot of
| the foundations had long since been done.
|
| ----
|
| 0: Which is not necessarily trivial to hire for, because
| the kind of person who has the kind of skills you need
| also is going to tend to enjoy hacking around and reverse
| engineering stuff for fun anyway increasing the chance
| they've managed to contaminate themselves.
| thayne wrote:
| Reverse engineer? Probably. As long as there aren't
| patents involved. And that is what the librephone project
| aims to do, from what I understand.
|
| But the binary blobs are protected by copyright, so you
| need a license to use them.
| galangalalgol wrote:
| There aren't even any arm or x86 desktops that are completely
| blob free. There is some ridiculously expensive amd power
| hungry power9 thing that nothing will run on, and some of
| sifive's newer boards might qualify. Every arm at least has
| some soc blobs. And every x86 has something like ime. Going
| straight for a blob free phone seems like getting ahead of
| ourselves. How about we shoot for a completely free rpi
| usable on the desktop first?
| M95D wrote:
| Rockchip AFAIK doesn't have any. It boots with mainline
| u-boot, but it doesn't include any wifi or other radios.
| 3abiton wrote:
| You're forgetting 1 tiny thing: the wjole AOSP ecosystem is
| running on volunteer dev time. It's much more difficult to
| organize and streamline vision / roadmap.
| ForHackernews wrote:
| I prefer /e/OS to LineageOS because it includes sensible
| defaults (e.g. Maps app + MicroG with location providers and
| signature spoofing enabled) that are a pain to set up for
| yourself after flashing vanilla LineageOS.
|
| /e/OS already partners with Fairphone, if you like that
| hardware: https://murena.com/shop/smartphones/brand-new/murena-
| fairpho...
|
| I agree that PostmarketOS needs a lot more love, but it's very
| far from being a daily driver system today.
| strcat wrote:
| /e/ has extraordinarily poor privacy and security. Extremely
| delayed privacy and security patches including years of
| delays for kernel, driver and firmware updates or complete
| AOSP patches is not compatible with privacy.
|
| /e/ rolls back privacy and security far more than LineageOS
| and /e/ includes their own invasive services. Murena services
| even send data to OpenAI without user consent.
|
| https://discuss.grapheneos.org/d/24134-devices-lacking-
| stand... is a detailed post covering the lack of privacy and
| security of /e/ with a bunch of linked sources including
| other detailed posts by third party privacy and security
| researchers. It also touches on the lack of security of
| Fairphone hardware including end-of-life Linux kernel
| branches not getting LTS updates and delays for
| driver/firmware patches, but it's much worse with /e/.
| honkostani wrote:
| As in every idealistic movement, the fundamentalists(which
| contribute all the talk and non of the walk) hijack it and
| drive it into a wall.
| ookdatnog wrote:
| Your statement is wrong in two distinct ways:
|
| - Fundamentalists never hijacked the FSF, they founded it:
| Stallman is about as fundamentalist as possible about free
| software.
|
| - In the case of the FSF, the fundamentalists are absolutely
| walking the walk, both in terms of contributing software, and
| in terms of going out of their way to not use proprietary
| software.
| positron26 wrote:
| > in terms of going out of their way to not use proprietary
| software.
|
| Performative and an example of very self-defeating tactics
| that belie motivations other than actually accomplishing
| anything.
|
| > they founded it
|
| This is true, but it actually contributes to arguments that
| the FSF is full of crazies content to preach from the
| monastery of ascetic suffering rather than live in a world
| with lots of independence and strong open source.
| ekianjo wrote:
| PostmarketOS has never achieved proper support on any device so
| far.
| fsflover wrote:
| Doesn't this count?
| https://wiki.postmarketos.org/wiki/Purism_Librem5_(purism-
| li...
| wltr wrote:
| Looks like it is not. Unfortunately.
| fsflover wrote:
| What's not proper about it?
| supermatt wrote:
| TLDR or something? They aren't making an OS.
|
| The project is about opening up the closed blobs that mobile
| chipsets use:
|
| "This project's goal is not another Android distribution, but a
| long-term project to better understand and reverse-engineer the
| nonfree blobs used by virtually all SoCs made today."
| fsflover wrote:
| https://news.ycombinator.com/item?id=45589873
| supermatt wrote:
| Thats clearly not what the OP is suggesting as per "Why do
| we have to have /e/OS instead of a better supported
| LineageOS, because /e/ is a 1:1 copy anyways?". Both cases
| are android. /e/OS is not librephone.
|
| There's little point in "partnering" with postmarketOS,
| because the project is literally about clean room reversing
| the proprietary blobs found in android devices:
| https://librephone.fsf.org/site/ - there are no commercial
| phones using postmarketOS with blobs to reverse engineer.
| fsflover wrote:
| > there are no commercial phones using postmarketOS with
| blobs to reverse engineer
|
| This is false: https://wiki.postmarketos.org/wiki/Purism_
| Librem5_(purism-li...
|
| See also my other comment:
| https://news.ycombinator.com/item?id=45589096
| supermatt wrote:
| > This is false
|
| You can install postmarketOS on it (just as you can
| install lineageOS, etc on a Samsung galaxy, etc), but it
| ships with PureOS. "The Librem 5 is a phone built on
| PureOS" - https://puri.sm/products/librem-5/
|
| The project is to reverse engineer proprietary blobs - so
| it makes sense to go where those blobs are and reverse to
| match the functionality that is exposed commercially
| instead of guessing at a subset for base implementation
| on a non-official OS?
|
| > See also my other comment
|
| It seems you are just as confused about this project as
| the OP, which is ironic given your name.
| fsflover wrote:
| > but it ships with PureOS
|
| Why does it matter? Yes, I would prefer that FSF
| collaborated with PureOS directly, but collaborating with
| postmarketOS also seems possible. There are enough blobs
| in Librem 5, which don't depend on the OS.
|
| > which is ironic given your name
|
| Indeed I'm quite surprised about the FSF actions lately.
| supermatt wrote:
| > Why does it matter?
|
| Because to reverse it you need to have a functionally
| complete baseline to compare it to. For the Librem that
| baseline is what it ships with (PureOS). For nearly every
| other device on the planet, that is Android.
|
| By them focusing on creating fully functional free
| drivers to swap out with the non-free driver blobs on
| Android, they will have created a reference source that
| can be adapted for any other OS.
| fsflover wrote:
| You're right about the drivers, but you don't need to
| reverse engineer them for Librem 5: They are already
| free. You only need to do it for the firmware, which
| AFAIK doesn't depend on the OS.
| supermatt wrote:
| "Non-free driver blobs" in the librephone context means
| anything needed to drive the hardware. i.e. kernel
| drivers, HAL modules, firmware images, user-space vendor
| libs, etc.
|
| But sure, librem5 probably has most of that already.
| fsflover wrote:
| > But sure, librem5 probably has most of that already.
|
| So it would be less work and would benefit more operating
| systems to work on it. Yet the FSF chose another hardware
| - I don't understand why.
| supermatt wrote:
| Because they aren't focusing on a specific piece of
| hardware... I'm really not sure what you are expecting?
| The librephone project to be focused on librem5 instead
| of the hardware used in thousands of other devices?
| RIMR wrote:
| Why partner with postmarketOS, LineageOS, GrapheneOS, or
| CalyxOS? This would be an open source initiative that
| contributors from any of those projects to add to. The results
| could be used by any of the aforementioned distributions, and
| more. It might even make running vanilla Linux on our exiting
| smartphones viable.
|
| Why partner with Fairphone and Pine64? They already have open
| hardware, and require zero reverse engineering to get a fully
| open solution working. In a world with thousands of Fairphones
| and Pinephones, and billions of corporate smartphones,
| replacing the proprietary software needed to run those billions
| of corporate smartphones is a hell of a win for software
| freedom.
|
| And are you really expecting the argument "open source loses"
| to be a real argument against a project by the Free Software
| Foundation? This is like asking a cancer charity why they don't
| endorse your preferred brand of cigarettes.
|
| What the FSF is doing here isn't about maximizing your
| experience with your preferred custom ROM, it is about tearing
| down the proprietary software barriers that prevent the vast
| majority of smartphone users from fully owning the hardware
| they purchased. It fits perfectly with the FSF's goals.
| ycombinete wrote:
| This type of semi-whataboutist comment appears at the top of
| most open source project announcements.
|
| Once we live in a centrally planned utopia these projects
| will all be merged with each other and produce the perfect
| phone/operating system/smart watch.
| fsflover wrote:
| > tearing down the proprietary software barriers that prevent
| the vast majority of smartphone users
|
| Are you aware that all those millions of devices require each
| model a dedicated reverse-engineering effort? You don't gain
| the coverage you're implying by concentrating on Android at
| all.
| torginus wrote:
| That's just the unfortunate reality of free software. Free
| software is anarchy, and the only people who thrive in anarchy
| are the ones who band into fiefdoms, who then fight amongst
| each other and build mutually incompatible projects (often from
| the very same components) which are direct substitutes to each
| other.
|
| There's tons of evidence of this with stuff like linux distros,
| desktop environments (each one MUST have its own sanctioned
| file manager, video player, music player etc, god forbid some
| godless charlatan come along and make its own).
|
| The price of admission into these 'tribes' is the adoption of
| the local creed (libraries/HIG/coding style/whatever/not
| speaking out against the Dear Leader/Core Principles/local
| purity committee). As with other such despotic organizations,
| incompetence and laziness is tolerated, disloyalty is not.
| pferde wrote:
| Nice try, Ballmer, go spread your FUD somewhere else. Nothing
| in your post is true.
| akagusu wrote:
| > Open source loses this war because proprietary devices are
| streamlined.
|
| "Open source" didn't loose because it didn't fight anything. It
| was exactly "Open source" that enabled Google to dominate the
| smartphone landscape.
|
| FSF and many other have been warning us for decades that
| Android been open source didn't matter because firmware, play
| store and many other components of Android were proprietary.
|
| People gave a shit to them and now do you want to blame them
| for the results?
|
| The diversity of projects were not and are not the problem. The
| problem is people that do nothing and only criticize.
| positron26 wrote:
| > It was exactly "Open source" that enabled Google to
| dominate the smartphone landscape.
|
| The financial interest may have preferred a licensing model,
| but either way, it was the financial interest that actually
| built a ton of this software. Linux isn't unpopular with
| businesses because of its license model. It is healthy
| because it found ways to plug into financial interest.
|
| The FSF will always push licensing models while ignoring
| financial interest, basically abandoning users and
| businesses. There are how many billion smartphone users on
| Earth, and the FSF expects volunteer programmers and
| volunteer donations recruited on one of the worst websites I
| have ever seen to carry the load? Give me a break.
| Ajedi32 wrote:
| This is the one big flaw I've seen in Stallman's philosophy
| on software. He's been thoroughly proven right I think
| about the dangers of closed-source (unmodifiable) software
| to user freedom. But I think his insistence that Free
| Software also needs to be freely redistributable with no
| payment to the author in order to be Free has greatly
| limited the resources available to build such software.
|
| The FSF will argue "you can totally sell Free Software"[1],
| which ignores the fact that without any restrictions on
| distribution/copying, the fair market value of said Free
| Software rapidly drops to ~$0. It's not a viable business
| model. Companies have built alternate business models
| around soliciting donations, or selling support or non-free
| add-ons to Free software, but selling Free Software itself
| (at least as the FSF defines it) doesn't actually work in
| practice. (You can do it obviously, but it's effectively
| just a different way of soliciting donations at that point;
| the fair market value of the software is ~$0.)
|
| [1]: https://www.gnu.org/philosophy/selling.html
| jraph wrote:
| > It's not a viable business model.
|
| > You can do it obviously, but it's effectively just a
| different way of soliciting donations at that point; the
| fair market value of the software is ~$0
|
| It is a viable business model. At XWiki SAS1, they do
| this for their "Pro apps" [1] which are paid extensions
| for XWiki targeted to businesses and that are free
| software (under the LGPLv2 license) with license checks.
|
| Businesses won't bother removing the license checks, it's
| easy enough to pay, and far easier than donating.
|
| It is not XWiki SAS's only business strategy nor the one
| that brings the most money, but still, that's not a
| possibility to discard too fast.
|
| You can also find paid open source Android apps on the
| Play store, and people (individuals!) will totally pay
| for them even if you can have them for free from F-Droid,
| like OsmAnd+ [2] or Conversations [3].
|
| [1] https://store.xwiki.com/
|
| [2] https://osmand.net/
|
| [3] https://conversations.im/
|
| 1 I work for them
| Ajedi32 wrote:
| As I said that's just another way of soliciting
| donations; it relies entirely on consumer goodwill (or
| ignorance/poor accessibility of the free option). There
| are limits to how big you can get with that (or how much
| you can charge) before someone just undercuts you with a
| fork.
|
| I'm not saying it's impossible to survive with that
| model; lots of organization survive on donations. But
| you're not gonna be able to build the Free Software
| equivalent of Microsoft or Google on donations.
|
| That said, I think doing that with business software is a
| particularly interesting case because it allows low level
| employees to justify running a donation through the
| regular software purchasing process without raising too
| many eyebrows if they care to. I've seen a few other
| projects with similar models.
| fsflover wrote:
| > that's just another way of soliciting donations; it
| relies entirely on consumer goodwill (or ignorance/poor
| accessibility of the free option).
|
| That's almost like saying that Netflix relies on the
| consumers' goodwill, since pirating is too easy. In
| reality, people pay for convenience in getting what they
| want.
| Ajedi32 wrote:
| The main reason Netflix is more convenient than piracy is
| that piracy is illegal. If The Pirate Bay was allowed to
| offer a $2/month unlimited movie streaming service with
| no legal repercussions, Netflix would be out of business.
| fsflover wrote:
| Actually, piracy became rare exactly when Netflix became
| easy to use and not when the former became illegal (which
| it always was).
| jraph wrote:
| It's nothing like donations: people pay these extensions
| / apps like any other paid software. That's my point,
| actually.
|
| In XWiki's case, we know it's not perceived like "I could
| be having it for free but I'll pay anyway because it's a
| nice thing to do".
|
| We do explain that our stuff is open source to our
| customers though. It's a selling point.
|
| In our case, admittedly, it helps that our target
| customers want our support anyway.
|
| > before someone just undercuts you with a fork.
|
| Absolutely, it is a risk to take into consideration. Now,
| maintaining a fork has costs too, and someone doing this
| would rely on continued maintenance and goodwill from the
| upstream vendor as well.
|
| Downstream vendors actually have an incentive to keep
| good relationships with upstream, so they can share fixes
| and have some guarantee that whatever they base their
| business on keeps being maintained.
| john01dav wrote:
| We should have terms and rigorous standards for software
| that is proprietary but not otherwise restrictive of user
| freedom. Most (weighing by how commonly it's used)
| software is either traditional, abusive, proprietary
| software like Windows or Google'd Android or is fully
| free like Linux. But, there is a large library of
| software that isn't under a free license, but doesn't
| attempt to abuse the user into being more profitable
| beyond any initial sale. Examples include the Nvidia
| drivers on Linux (but not Windows), Jetbrains IDEs, many
| game engines (I'm thinking of Unreal here), and most
| commercial software in the 90s and 2000s. The defining
| feature of this is that 1) it is not under a free
| license; and 2) aside from basic license checks in some
| cases and bugs, it never does anything against the
| interests of the users. Having well-defined standards and
| terms in this area could encourage more of such software,
| for product designers that appreciate the promise of free
| software but are not convinced by its revenue options.
| a456463 wrote:
| PREACH. Sorry. I felt heard and seen!
| bogwog wrote:
| Did you read the article? They're not creating nor choosing an
| operating system for the librephone project. They're looking
| into reverse engineering the binary firmware blobs needed to
| achieve a fully free software distribution on a modern device.
| Afaik, this work will benefit all alternative OS projects for
| whatever devices they succeed with.
|
| I guess maybe a good analogy would be like trying to port
| coreboot to a laptop.
| pessimizer wrote:
| I'm pretty sure they said they're partnering with _everybody
| that they possibly can._ I also don 't know what you mean by
| "just partner with postmarketOS." It's basically a project to
| create a fully-free Android-compatible distribution (or rather
| the fully-free low-level elements that would support this), and
| postmarketOS is not Android. I also don't have any idea why you
| think that they wouldn't be talking to everybody who is reverse
| engineering phones to get OSes on them.
|
| I really do not understand this comment at all. I don't
| understand the weird judgemental tone, and I don't understand
| that people have reacted to it like there is content there.
| kristianpaul wrote:
| "Librephone is the FSF's project to free up those blobs. This
| project's goal is not another Android distribution, but a long-
| term project to better understand and reverse-engineer the
| nonfree blobs used by virtually all SoCs made today. " Looks
| they're going to build something literally from the ground
| TZubiri wrote:
| I feel that free software sometimes obsesses over the 1% when
| the 99% of their objective is achieved.
|
| I make a parallel with politics and transparency, a software
| lead once told me that a completely transparent government
| was tried in the french revolution and it kind of didn't
| work. For example, we all would agree that there's some
| functions of government related to war and security that
| should not be transparent. I feel that free software would
| obsess over that private fraction because for all you know it
| might hold all of the secrets and evil that you imagine.
|
| That said, it is possible that under the guise of reasonable
| need for private blobs/three-letter-agencies, a lot of other
| 'evil' things may be hidden. Maybe they say it's due to
| security or IP concerns, to provide protection against device
| tampering, to avoid pollution of radiofrequency spectrums,
| but it's possible that in reality they are hiding spying
| software in the wifi firmware and hardware keystores?
|
| I feel that if the FSF recognizes that there's some areas
| that are ok to have closed source, then they could be taken
| seriously, otherwise they will just be ignored and leave room
| for precisely the kind of misuse of closed source that they
| fear. This is especially noticeable when they fight against
| projects that precisely do a lot for open source, like github
| (See GitLab/Savannah), or Android, they are 99% of the way
| there, give them a break.
|
| Extremism begets extremism, if the jails are too full (or too
| empty), advocating for the other extreme will get you
| nowhere, the Overton Window doesn't quite apply, in fact it
| can be harmful as you are providing a real threat to the
| other extreme.
| worik wrote:
| > free software sometimes obsesses over the 1% when the 99%
| of their objective is achieved.
|
| That is the nature of software. 1% is too much. It is Free
| or it is not
| SEJeff wrote:
| Free software is by its very nature dogmatic. Stallman
| himself makes cringey jokes and references to the "church
| of gnu". It's more of a way of life than a way to develop
| software. By design, a religion is only happy with 100%.
|
| Open source is just pragmatic and is very happy with the
| 99% being open source. It's more corporate and doesn't
| generally care at all about the dogma.
| AnthonyMouse wrote:
| > I feel that free software sometimes obsesses over the 1%
| when the 99% of their objective is achieved.
|
| It rather depends on what that 1% _is_.
|
| The low-level code is what's _most_ important to be free.
| If you have free firmware and drivers and operating system
| but then you still have to run a Windows VM or WINE for an
| old proprietary app, you can only have problems when
| running that app.
|
| If you have opaque blobs interacting with the hardware,
| they can crash the whole system, expose firmware-level
| security vulnerabilities with persistence and the blobs are
| specific to a kernel version so when the vendor stops
| providing updates, you're stuck with an obsolete kernel
| version with known security vulnerabilities. If anything
| needs to be free software, it's that.
|
| > This is especially noticeable when they fight against
| projects that precisely do a lot for open source, like
| github (See GitLab/Savannah), or Android, they are 99% of
| the way there, give them a break.
|
| Android is "open source" but then the devices are Tivoized
| or you run into attestation failures if you actually want
| to run your own version of it. GitHub literally got bought
| out by Microsoft. These seem like legitimate concerns.
| antisol wrote:
| > we all would agree that there's some functions of
| government related to war and security that should not be
| transparent
|
| Yeah I don't know that this premise is true. For a lot of
| examples you might give WRT war or security, I feel like
| some will take the approach that "if you can't do it
| transparently then you probably shouldn't be doing it at
| all". > I feel that if the FSF recognizes
| that there's some areas that are ok to have closed source,
| then they could be taken seriously, otherwise they will
| just be ignored and leave room for precisely the kind of
| misuse of closed source that they fear. This is especially
| noticeable when they fight against projects that precisely
| do a lot for open source, like github (See
| GitLab/Savannah), or Android, they are 99% of the way
| there, give them a break.
|
| Yeah but the problem here is that the FSF has this annoying
| track record of being proven correct, _over and over
| again_. Two of your examples are github and android: github
| got bought out by microsoft, and android is about to be
| hobbled to the point that f-droid won 't work on it
| anymore. If you want to go and look at the history you'll
| see a _bunch_ of other instances of Stallman and the FSF
| saying things that sound paranoid at first, but which turn
| out to be correct in the long run. It 's genuinely
| annoying, life would be easier if they were wrong
| occasionally.
|
| Does it still count as a cult if they're right? Do they
| still count as extremists if they're empirically correct?
| Maybe it's a good thing to have that type of extremist out
| there, fighting for everybody.
| TZubiri wrote:
| "Yeah but the problem here is that the FSF has this
| annoying track record of being proven correct, over and
| over again"
|
| It's not that FSF is proven correct, it's that the FSF
| disapproves of 99.9% of software, it's easy for them to
| look back when there's a scandal and say "see? we told
| you so.". Too many false positives.
| a456463 wrote:
| too many false positives means you should reconsider what
| you call a false positive
| jabl wrote:
| There is a lot of work to do to reverse the trend of increasingly
| locked down computing devices, particularly on mobile.
|
| But from scanning through this press release, this seems nothing
| more than the FSF doubling down on their failed RYF approach,
| which does absolutely nothing for user freedom. In fact it's a
| big negative for freedom, as it ties down resources that could be
| spent doing something useful in doing something completely
| pointless like putting firmwares in ROM and adding another chip
| to load the firmware.
|
| The thing is, firmwares are here to stay. And firmwares that can
| be stored on the filesystem and loaded by the OS during driver
| initialization increases flexibility and reduces BOM cost. So
| that's what device manufacturers are going to do, and RYF will
| not have any effect on that.
| jacquesm wrote:
| Getting governments, banks and other big entities to play along
| here is going to be the main challenge.
| le-mark wrote:
| One might think governments could get on board for the sake of
| digital independence/sovereignty ; but so far that hasn't been
| the reality. One day digital sovereignty could become a real
| priority, then it could happen.
| jacquesm wrote:
| I think that day arrived Jan. 6th 2025. If the message
| doesn't land now it never will.
| permalac wrote:
| I'd like to see an android auto replacement, and them partnering
| with existing free phone approaches.
|
| Two many xkcd already about creating new standards.
| mrasong wrote:
| Cool idea, but I'm skeptical. I just want a phone that works--
| calls, texts, banking apps, and a good camera. If this Librephone
| can't run my usual apps or needs me to wait years for it to work
| with new phones, I'll stick to my current one. Why not team up
| with projects that already exist instead of starting over? Hope
| it works out, but I won't hold my breath.
| rjdj377dhabsn wrote:
| I think you misunderstood what they're planning to do.
|
| Librephone isn't going to be releasing their own OS. It's an
| effort to systematically replace binary blobs so that existing
| projects like GrapheneOS and LineageOS are more free.
| mixedbit wrote:
| With phone hardware lifetime so short, would it be possible to
| catch-up with hardware update cycle? I guess each new version of
| a phone can ship with new versions of binary blob drivers. As
| mentioned in the announcement, reverse engineering the blobs is a
| huge effort, when it is done, hardware may already be out of sale
| and the effort would need to be repeated for new versions.
| mobileturdfctry wrote:
| The fact that there is proprietary software running in "open
| source" mobile phone OSes may not be addressing the source of the
| problem. Because it seems that by funding a project like this it
| almost implies that the parties funding it don't necessarily
| trust the people who own and thus could open source the
| proprietary blobs tomorrow.
|
| The leap I seem to have trouble getting to is this. If you can't
| trust the people responsible for the proprietary software, how
| can you be sure that they won't turn around and start using new
| chips or software once the existing ones are reverse engineered?
| Perhaps it's about patents and the patent holders could be using
| this IP as a cash cow?
| overgard wrote:
| I'm not saying this shouldn't exist, because it should, but does
| anyone actually have any faith that the FSF can actually do
| anything here? They're like 15 years late to the party
| IshKebab wrote:
| Yeah there's zero chance this will succeed. They would be much
| better off lobbying governments to enforce more openness in
| Android and iOS.
| BaudouinVH wrote:
| dear FSF, let's discuss your https://librephone.fsf.org/ web
| site.
|
| It does the job but it's not easy on the eye.
|
| Full-width line of text. Readability nightmare. Here is how it
| looks with just a link to a CSS (I closed my eyes on the
| cssbed.com and picked one at random).
|
| https://librephone.surge.sh/librephone-website.html
| bluenose69 wrote:
| Yup, that's pretty bad. But, as an old fart with old eyes, I
| now use Safari and click the 'reader' version on many sites.
| Frankly, the web in it's early years was preferable to much of
| what I see nowadays. But, like I say, I'm an old fart. Heck, I
| used punch cards throughout my undergraduate days.
| BaudouinVH wrote:
| I use reader mode too. When I do it triggers a "imperfect
| lay-out" alarm.
| whitehexagon wrote:
| I'm currently hacking a toy OS in Zig on the PinePhone, and I
| have to say the documentation is a bit painful, or sometimes just
| missing, for parts of these complex SoCs, and that is meant to be
| a fairly open platform.
|
| But the modem binary blob is a whole other world, and I am not
| sure how they could tackle that, since my understanding is that
| this is partly done for carrier licensing reasons? ie. to avoid
| abuse on the cellular networks. So isn't an open source radio
| driver also going to have to be licensed in the same way, and
| then ultimately shared as another binary blob?
|
| The PinePhone compromise seems to be 'isolating' the modem & blob
| at the end of a USB link. Although I'm not 100% sure how that
| works yet, since I only just got the graphics & fonts working.
|
| But even that is a bit of a puzzler, since I'm currently
| framebuffer-to-lcd based, but I know there is a Mali GPU hiding
| somewhere. I suspect that will also involve another blob. Anyway,
| the framebuffer approach seems fine for now, it is booting in
| ~2s, and the less binary blobs involved the better.
|
| It will be interesting to see what FSF can achieve. But,
| personally I think they would be better focusing on a fully open-
| hardware dumb phone, and build upon that.
| arnaudsm wrote:
| This is exciting, exceptionally the firmware & binary blob
| foundations that are the biggest roadblock.
|
| Concerning the UI, I wish we had another attempt at a web-based
| mobile OS. FirefoxOS was too early, but APIs are much more mature
| now, and WASM offers great performance for low-level stuff. I
| might work on this full time when I retire.
| penguin_booze wrote:
| Ugh, I don't know. From a practical standpoint, I can see why
| basing on Android makes sense. But I really wish we can "somehow"
| extend an existing Linux distribution (or an Android kernel,
| even) with a user space reworked to function well on small
| screens. Maybe that's a pipe dream.
|
| What I'd really, really prefer is to be able to program the
| device with the same ease as developing a local Linux
| application. If I need a UI, I'd rather that be a web front end,
| and not something that needs GBs and GBs of special IDEs and
| other bloatware. That way, we don't need specialised "apps" for
| each and every thing: any service that already has website,
| should work as it is. Just point a browser at it.
|
| And how do I tweak an "app's" UI if I must, rather than beholden
| to it? That's right: web extensions.
| heybales wrote:
| Congratulations, you just invented the open web circa 2006.
| NoGravitas wrote:
| Or FirefoxOS circa 2013.
| woodrowbarlow wrote:
| i agree, except the web part.
|
| Purism did a lot of work to build Phosh, based on Gnome, with
| GTK apps that had fluid layout. on a phone-size screen, the UI
| was suited for touch; but connect it to a screen and everything
| seamlessly switches to a standard Gnome UI.
|
| i would rather see this get mainlined into Gnome, and for it to
| be common-practice to design desktop apps with a fluid layout
| that can adapt to phone screens.
| penguin_booze wrote:
| I'm rooting for the web because it's all plain text
| technologies. And UIs live high up in the stack that one
| benefits from quick feedback, and also isn't forced to use a
| low-level language to develop them. But I suppose there can
| be language bindings from Python etc.
| pabs3 wrote:
| OpenMoko had that more than a decade ago, there were a
| multitude of distros. I ran Debian with X11 and Enlightenment
| on it at one point. QtMoko was probably the best one for the
| Freerunner hardware though, much more suited to the small
| touchscreen.
| tomtom302 wrote:
| Tom is a liar
| symbogra wrote:
| The way I read this is that the FSF has gotten funding for one
| guy to work on this project. Great but as soon as you're doing
| anything hardware related you need to expend a lot of development
| effort just keeping up with new releases from hardware
| manufacturers. It's a never ending treadmill.
| nabla9 wrote:
| Librephone is reverse engineering project that attempts to remove
| remaining proprietary binary modules, not a competing project.
|
| > Triaging existing packages and device compatibility to find a
| phone with the fewest, most fixable freedom problems is the first
| step. From there, the FSF and Savoye aim to reverse-engineer and
| replace the remaining nonfree software. Librephone will serve
| existing developers and projects who aim to build a fully
| functioning and free (as in freedom) Android-compatible OS.
| johnwheeler wrote:
| FSF never does and never will understand good software. The
| problem they have is they don't care about the user as much as
| they care about the developer. They want everything to be easy
| for the developer and they put the user second.
| ktosobcy wrote:
| Great. But IMHO better regulation is still needed: force makers
| to have unlockable bootloader and provided libre drivers for
| their device (for the OS that they originally ship with); force
| makers to provide alternatives - for example using alternative
| "play services" by only providing general API that others can
| provide pluggable implementaions...
| hamburgererror wrote:
| Is there any other way than going through reverse engineering?
| Projects like LineageOS and others have shown this is really
| hard.
|
| Why not simply start from scratch and make a truly open source
| phone? That is, design and build the electronics and the OS that
| goes on top of it. A bit like an iPhone+iOS but fully open
| source. Is this dream really unreachable?
| pshirshov wrote:
| I guess it will be as successful as GNU Hurd and others.
| misano wrote:
| It's too late when we are moving away from phones and shifting
| towards wearable technology.
| charliebwrites wrote:
| > Triaging existing packages and device compatibility to find a
| phone with the fewest, most fixable freedom problems is the first
| step
|
| Maybe this is my PM brain but why go after the most compatible
| devices first vs the most popular devices today?
|
| Surely you'd maximize software freedom by targeting the most used
| devices so those can switch first
| lejalv wrote:
| There are several comments about Linux on phones anos
| PostMarketOS.
|
| Apparently an usable daily driver already, FuriLabs' FLX1s.
| Nobody seems to have mentioned it yet.
|
| https://furilabs.com/
| efreak wrote:
| This is interesting, but the image thing that caught my eye is
| their use of the Apple app store logo (being on a slow
| connection, the video at top didn't load very fast)
| john01dav wrote:
| What I'd like to see is open standards for smart phone software:
| standard ways to have drivers with a stable ABI and API (the goal
| here is to decouple specific OSes or kernels from specific
| hardware, if the drivers are free that's even better but is not
| needed for this goal), a standard way to write data to the
| internal drive and to boot from internal and external drives
| (UEFI could work here), and bootloader locking being a thing of
| the past. We have this or similiar for desktops and laptops. The
| result of this is that I can run any of hundreds of options for
| my OS (any major Linux distribution, various BSD options,
| Windows, and more) even on very old hardware.
| nektro wrote:
| FSF is a joke
| DoctorOetker wrote:
| Does anyone know where the Linaro wiki has disappeared to?
|
| An initiative that supports a (quasi) mainline linux kernel and
| driver support for smartphones seems like the more logical
| initiative before ironing in a smartphone linux _distribution_.
| bolangi wrote:
| Great idea. I'd love to hear something realistic like,
| "Practically everyone who uses a phone or computer is under
| surveillance. While this project may seem late relative to the
| damage done thru unlawful surveillance over previous decades, it
| represents a start that could lead to better privacy for some
| early adopters and gradual shift away from the blobs and
| proprietary technology that place control of our hardware in
| other hands than our own."
| jajuuka wrote:
| I think this mission is doomed to obscurity. FSF is way late to
| the party and is not bringing the type of resources needed to
| accomplish this in an impactful way. Reverse engineering device
| binary blobs will take a long time regardless and by then devices
| will be several generations behind.
|
| Their efforts would be better spent on building up maintainers of
| existing custom ROMs and partnering with open source phone
| hardware initiatives like Pinephone. Maybe even go the route of
| HarmonyOS and run a completely different kernel and support
| Android app emulation. They should be looking ahead and not
| trying to match functionality today and it changes around them.
___________________________________________________________________
(page generated 2025-10-15 23:01 UTC)