Hacker News Reader

Comment by izacus | Hacker News Reader

> It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).

The competition in this case is Apples iOS, for which even HackerNews users love to harp over and over and over again how amazing it is and how little battery it uses because it doesn't allow apps to use anything but APNS, run anything in background or even include GPL source code.

This is what's Android competing against - an completely locked down operating system which cannot deliver any kind of GPL code. And every time it allows more freedom to developers it's punished in the market by losing against iOS and mocked on this very website about how it allowes their app developers to drain battery and access data.

What exactly do you expect Google to do here?

View on HN

I don't think you're focusing on the entire picture.

Some people here like iOS for the reasons you described. However I'm willing to bet, unless you can show me otherwise, that it's a vocal minority. I don't know of anyone personally who is happy that Apple disallows GPL code.

Comparing Apple's digital Fort Knox with Google's unsupervised free-for-all is a false dichotomy.

There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.

Please forgive me for being unnecessarily obtuse this early on a Monday morning.

Where does Apple say that GPL code isn’t allowed on the App Store? I ask entirely out of my selfish need to avoid unpleasant surprises later on.

Apple doesn't say it directly, but the way how they deliver apps to devices incompatible with GPL licensing terms.

See for example https://apple.stackexchange.com/questions/6109/is-it-possibl... .

Apple has been slowly phasing out GPLed software from their own software, such as Catalina's migration from Bash to Z Shell, but even writing third party apps with the GPL has apparently been problematic in the past: https://thenextweb.com/apps/2013/07/18/vlc-for-ios-will-retu...

It's what I've heard rehashed around HN, but afaik the actual policy is more or less as described here:

https://forums.developer.apple.com/thread/18922

Essentially it works like it should anywhere else: If you don't publish source code and someone complains, you're out. In an ideal world Google Play would hold itself to the same standards.

However, the App Store does impart restrictions which are incompatible with GPL, so it's not so much that Apple doesn't allow it as it is that GPL doesn't allow it.

Apple has no official statement on this of course, but we know how they feel about GPL code given that they've removed every bit of it from their OS over the last few years.

They haven't been removing GPL code actively, they decided not to take the risk of using GPL version 3 software, so they've let the respective versions of bash, rsync etc. linger at their last released GPL version 2 releases.

E.g. Git is on GPL version 2 still (and probably forever), and Apple continues to update that in a relatively timely fashion.

Apple just switched to zsh, which is not GPL other than a few optional shell functions. Expect this trend to continue.

The App Store came after the GPL. Also, Apple could let developers opt out of the restrictions.

But they don't, and that's what this conversation is about.

You attributed the incompatibility to the GPL. Apple created the incompatibility. Apple could easily fix it. The FSF can't change existing versions of the GPL.

Someone should probably tell VLC if GPL is disallowed, since they have been shipping across tvOS and iOS for years.

I think VLC core had a large amount of code rewritten, to change the license (https://news.ycombinator.com/item?id=4787965), which required a large effort from the VLC team.

Free Software Foundation says that GPL is not allowed in AppStore and they may request GPL software to be removed from App Store. https://www.fsf.org/news/2010-05-app-store-compliance

The issue is that the Apple dev ecosystem creates encumbrances that prevent users of GPL binaries from relinking them. That is a GPL violation and such binaries are not compliant with the license.

They don’t- it’s the FSF restricting developers freedom. Not Apple.

How? I'll debate FSF ethics as much as the next guy, but they clearly state they want end user freedoms such as the freedom to modify the application you use. Apple clearly doesn't want that if you use specific GPL versions.

This is an Apple problem, not FSF.

End user freedoms but not freedoms for the person who actually creates the code.

> There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.

Is this not the happy medium Google is trying to hit?

Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.

By default things are restricted to deliver a happy user experience in the context of the average person that just wants a product that works. But you're free to do whatever you want. There's (usually) even controls to remove restrictions from apps manually without doing the custom ROM route, but there is always the ultimate power user toggle there of "flash a custom ROM"

That's what I thought when I bought my Sony phone. Except when you unlock it you run a crippled version of the phone.

Huawei recently stopped allowing bootloader unlocks.

Unlocking the bootloader is becoming increasingly rare.

To be honest, ignoring the back and forth between the discussions here, am the only one that doesn't get WHY the firebase library isn't open source? It could just be GPL right? Most of the interesting stuff happens in the backend anyway, so what's the issue.

Am I also the only one that thinks this gives google the chance to lock out/cripple third parties like huawei or other non certified android vendors from distributing Android apps that were built for the play store.

I don't know the ins and outs of this, but wouldn't that still mean that the app would have to rely on google infrastructure to do push notifications? That might be a fix for the licensing problem, but it wouldn't address the problem that that would move virtually all remaining google-free (-ish) messengers into googles direction, with the potential for centrally siphoning of (meta-) data

No, the app can continue to use third party push notifications if the OS allows it to.

> Unlocking the bootloader is becoming increasingly rare.

This is a bit of "you get what you buy" territory. Google's devices have official bootloader unlock capability and always have, with instructions here: https://source.android.com/setup/build/running - already updated for the Pixel 3a & 3a XL even. You take your risks when you buy something that doesn't advertise that.

> Most of the interesting stuff happens in the backend anyway, so what's the issue.

I think most of the interesting stuff on the device is even in Google Play Services and not in the firebase library. I have no idea why the client SDK can't be open source, but how much does that even matter?

I just bought a new Pixel 3a only to find out that my cell provider locks the bootloader until I've paid for 3-4 months service with the phone, despite previously having an account with them.

This was not mentioned at any time during the purchase and they would not take my phone back.

Unfortunately that's the problem with getting any phone via a cell provider. You are typically beholden to them in some fashion for a few months.

Buying unlocked phones from the start can be an expensive downside, but being free from contracts and carrier bullshit can be a huge upside.

For completeness' sake: even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.

If google was trying to hit some sweet spot (I'm not willing to give them the benefit of the doubt here any longer) then they would not spout such obviously wrong BS to scare users into submission. Conversations and telegram both put the work into doing push notifications The Right Way (TM) so scaring users about this is stupid at best.

> even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.

You don't have to be a kernel hacker to build & flash AOSP. Google has a guide on it: https://source.android.com/setup/build/running

But whether or not you consider this a "power user" or not is obviously less clear cut. How you define "power user" does of course change things. The point is just that there is the ultimate escape hatch of flashing a custom ROM, and it's not THAT hard to do, especially with all the tools out there to flash things like LineageOS super easily. You may not understand what it's doing, but it is at least sitting on officially supported things for the devices Google sells.

Not sure why you are bringing this up. The point of this thread is the misleading warning or other OS level changes that are forced upon you if you don't use FCM. Changing that behaviour needs changing AOSP.

Then it's a real shame they haven't paid attention to the documentation for NotificationBuilder, because there's a straightforward solution to the problem they're complaining about.

> Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.

A bit of a tangent but I'm a "power user" and still can't get rid of the stupid warning in the beginning. Definitely not a happy medium.

I don't know of anyone personally who is happy that Apple disallows GPL code.

And this is what you call a geek bubble. In the grand scheme of things most people don’t know what the GPL is and out of those, only a minority care about it running on their phone.

Most of my friends are not "geeks", and do not exist in the technological space that I do. I'm not speaking from within a bubble.

So you have friends that are not geeks who know about the GPL and care? This is the opposite of the “No True Scotsman”. Anyone who knows about and cares about the GPL is s geek.

> Anyone who knows about and cares about the GPL is s geek.

No, that would be a regular No True Scotsman.

> So you have friends that are not geeks who know about the GPL and care?

Did I say that? No, I didn't say that. I said I don't know anyone who is happy that Apple disallows GPL. This includes people who have no idea what the GPL is.

The difference is Apple has been the same from the beginning. There was no bait and switch. People who bought Apple products knew what Apple was and will be and what the terms were.

With Google there is a bait and switch (and it doesn't really just apply to this particular story). They came to market defining themselves as the open alternative to Apple to get market share and developer interest (and evangelism), and now that they've achieved dominance the terms are changing.

There's no surprise that there's going to be massive pushback (and probably antitrust implications).

Apple has the majority market share in the US. I think they need to be forced to open up for alternative app stores.

This data says that Android is bigger.

https://www.statista.com/statistics/266572/market-share-held...

Exactly. We see the same pattern with Chrome and the new course it's taking.

The reverse is also true: whatever sufficiently good product that doesn't generate money is basically doomed by them no matter how many users depend on it. (Reader, Inbox, Talk, ...)

Who exactly is buying Android phones based on the premise of openness vs "they're cheaper", "it was a subsidized new phone from my carrier"?

Personally I've always bought Android (and while it lasted Firefox OS) phones because of the option to easily tinker with the phones. If/When pure linux phones make a come back I'll be moving on to them. Of course nerds being nerds is an outlier.

An ideal platform would use a foss compatible framework. It would allow the user to configure which server to use to push notifications(one server for all apps, since that is needed for battery reasons). Notifications would be encrypted with the apps key.

>allow the user to configure

This may be an ideal solution for you but its really not for most people.

That something is configurable doesn't negate the ability to have sane defaults that most people won't touch.

Often times even having configuration options creates surface for security issues.

A good example of this is that there were scams that involved having people paste some script into their chrome devtools and steal data. This worked fairly effectively. Facebook ended up doing some magic to show a warning message in the devtools console to tell people that no, you really shouldn't paste random stuff here, it will do bad things.

Configurability does come with a cost. And "the ability to reroute all push notifications through an arbitrary MITM" is a security cost that I expect wouldn't be worth it.

I very much doubt that Google is making the GCM push code proprietary for these reasons.

No the truth tends to be more banal - making everything replacable in configurable means more (paid) engineering work for Google engineers for what's, essentially, building infrastructure for competition. What would be the compelling business case for Google to do more work to enable removal of their own product?

Hence why I said encrypted.

The impulse to protect people from themselves is a dangerous one. In the article itself we see that in practice it is used to push inescapable spyware.

"But our spyware is better than their spyware!"

Google says they will protect you. But the truth is they are just concern trolling to shut down marginally worse competitors.

For kids and elderly that can't make decisions on their own it could be default -locked to some entity contractually bound to good ior. Locked with an administrator password. That would be a reasonable compromise.

Google actually released Capillary, which makes E2E encrypted FCM messages easier to implement: https://security.googleblog.com/2018/06/end-to-end-encryptio...

But yeah, if you want to avoid Google's servers, then it's not enough. But in that case, you're probably on Google-free LineageOS anyway right?

Is the solution to begin, to a degree, treating adults as children?

To answer the question shortly: Yes

But I actually think you are mis-portraying the situation is because I don't think the average adult has the ability to comprehend these things. It's not the difference between adults and children, but adults and expert adults.

Here are some analogies to other parts of society that we don't have a problem with:

Seat belt laws Hard hat required construction area Safety guideline in Handling of hazardous materials

We basically said society doesn't trust you to decide for yourself about your safety - you just have to follow the rule.

Except a large portion of society thinks seat belt and hard hat laws are bullshit and shouldn't even be legal to enforce. Hazardous materials handling is completely different though.

>It's not the difference between adults and children, but adults and expert adults.

Part of me wants to challenge the existing groupings of adults and children where all that matter is if you have been around the sun 18 times or not. This is but one weakness in the existing grouping that furthers my questions, such as why do we allow the non-expert adults a vote over laws, but deny a 17 year old the same?

I think if you take the groups of children, adults, and expert adults you will find upon reducing them to only two groups based on similarity that you are left with experts and non-experts.

This is possible to build on Android right now and something I've thought about myself. There is nothing stopping you or me from implementing it, and I've always thought that Amazon should have done it to make it easier to port applications into their ecosystem.

I use an iPhone currently but I'm wishing for an Android instead, precisely because Android allows some Free Software apps that have no equivalent for iPhone.

But yes, I agree, Android's competition is iOS and that's freaking sad.

Two things:

1. According to the reddit post the firebase library makes no difference to battery life

2. It is perfectly possible to provide strong guarantees around battery usage and resource consumption with open source code

I would like a choice between consistent and curated vs open and free with both respecting privacy.

Unfortunately, the choices today are limited.

Good thing Huawei is cut off, we might get some much needed options that are not tied to Google Play Services.

Have you considered those two groups aren’t the same?

I did, but then I'd expect the GPL group to actually comment with the same zeal on Apple articles... but Apple criticism seems very muted in comparison.

The GPL group has given up on Apple, whereas they adopted Android because it was pitched as an open source platform.

> What exactly do you expect Google to do here?

Let app developers and users have a choice.

That was exactly the state of the Android until 6.x or so and I've had multiple frustrating hours of mentoring Android developers on how to do notifications respectfully just to be ignored with "eh, I'll poll every 10 minutes, it's easy and it works!".

And this has been my experience constantly:

- "Eh, I'll just demand full storage access for my game, it's easier to unpack files in root of sd card" - "Eh, I'll just constantly reconnect HTTP no matter what the current device state is" - "Eh, I'll just download 600mb on mobile, it's easier than checking"

There are some developers that did right by users, but enough Android devs are constantly ignoring the best practices of development and users privacy because it's "easier" and requires less code.

Because of that I fully understand Google's new stance: developers haven't proven themselves trustworthy and it seems Apple's way is the only way to defend users against abuse.

Defending users by actively lying about battery usage is not acceptable. Battery meter in 8 was accurate and flagged battery eating apps accordingly. This new thing is actively lying when you don't use Firebase, as if nobody can ever correctly implement push notifications.

I'm not sure what you're talking about exactly? What's the "new thing" in your post?

(Btw, the on-device battery meter is horribly inaccurate and always has been. Multiple values, like screen power use, are hardcoded by OEM and tracking app power use is not reliable in any case because those graphs are incapable of measuring cascading power efficienty effects coming from using the radio or Play Services.

Use Battery Historian if you want more useful battery use debugging.)

It's really really really hard to attribute battery usage correctly when it comes to push notifications.

> This new thing is actively lying when you don't use Firebase

It is lying, alright.

That said, I don't think that this lying notification is the best example of Android designers being nefarious jerks. The notification lies to user about non-existing "battery drain", but it only does so when developer tries to get around the requirement to show notification with foreground Service. It is shown when you set notification to be hidden via low-priority. I have also seen it when notification icon was fully transparent. It is basically a retaliation against developer misconduct (when developer tries to run persistent background process without telling user). Ideally, this should encourage developers to show a proper foreground Service notification, which the user may consequently hide via notification settings.

I do believe you when you say a lot of devs are taking the easy way out and wasting device resources. But some devs do things right. And those devs are the ones being penalized. Perhaps worse, the user's choice of apps has been constrained.

It would have been so much better if the Play Store and SDK and Android platform could have features that clearly highlight these resource-hogging apps as bad actors. That's the kind of killer feature I expect from Google. I don't feel like they're living up to their reputation for hiring brilliant programmers. Instead they're taking out a really large hammer and hitting everyone with it.

Reply on news.ycombinator.com