>claim to be botnet free
>using android
Why don't you use iOS?
Because it's botnet too
Android is a FOSS operating system, and iOS is a proprietary black box.
Android can be used without any proprietary components, iOS is 100% proprietary components.
Is this even a real question?
>>51255617
>if I ignore the fact Google owns android I'll win this argument!
>>51255617
who cares if the hardware is proprietary, it'll stream your 10-bit chinese cartoons all the same.
>>51255639
You seem to be confusing "Google Android" with "Android Open Source Project"
Is there a single phone with a FOSS baseband? Compiling your own Android version won't help if the hardware is full of backdoors.
>>51255728
aosp doesnt just werks™
>>51255770
AOSP is literally Android without Google's applications. It does just work.
>>51255617
>Android is a FOSS operating system, and iOS is a proprietary black box.
A significant portion of the Android user space stack has moved into the proprietary Google framework. So, Android is basically a black box too, unless you remove support for a shitload of things, including access to most third party apps.
Android on the other hand has some serious flaws:
- Wakelocks are a terrible idea, and now that they're here, they will never really go away, and will always hinder battery life. 6.0 attempts to address this in some limited capacity, but it suffers in two ways: it's opt-in at the choice of the developer rather than the choice of the user; and because wakelocks are still fundamentally the only way to achieve many tasks (rather than having a well designed daemon/service infrastructure with a good timer API) you often cannot get around using wakelocks.
- The base system is fundamentally un-update-able. Security flaws cannot be patched quickly, or often at all. There is critically no way to fix this because of the nature of Android. If Google were to attempt to force the hands of big market players into streamlining updates, it would only further fragment Android. They have no leverage in the most important aspect.
- Android permissions are not very fine-grained. The permission infrastructure is messy. Apps often require permissions they don't need. Or they may need one benign sub-permission, but must request access to whole swathes of the system in order to gain it, opening up security concerns. This is being fixed in 6.0, but applications must opt-in.
Continued below...
>>51255956
- Capabilities are not properly virtualized or virtualizable, so permission revocation is not a neat process. Even in 6.0, where permission revocation is finally being implemented, you can't expect poorly written applications not to break spectacularly when you revoke permissions, because there is no mechanism to prevent this. They should have been virtualized from the very start, but now they likely will never be.
- Many new system capabilities are being written in a very ad-hoc manner with Google-specific APIs. Most improvements currently happening to Android are happening within the Google Services Framework, so you increasingly cannot opt out of using black box Google software. The base system is becoming a less and less powerful thing, while Google's bloated services are more and more imposing. This is problematic not only because of licensing reasons, but because Google's Services framework consume exorbitant amounts of system resources, and Google has no vested interest in avoiding this. At the very least, they benefit from wasting storage space, since they are a prime vendor of cloud storage.
- Android's security practices are considered laughable even by Google's own security people. Source: http://bgr.com/2015/11/04/why-is-android-security-so-bad-2/
>>51255990
- Google has made no serious attempts, nor shows any interest, in protecting user data from third parties. Whether you want Google having your data or not, you probably don't want every market app out there pillaging everything they can possibly get their hands on. Not only is it a privacy concern, but the lack of meaningful infrastructure to prevent it is also a security concern. I cannot, for instance, trust the integrity of my phone whatsoever to store my SSH private key. It would be nice to be able to SSH into my server remotely from my phone when I need to do so and am not at home, but quite frankly, putting my SSH key on my phone would probably be an awful idea because Android has no meaningful protections against malicious intention.
See here: http://arstechnica.com/security/2015/11/user-data-plundering-by-android-and-ios-apps-is-as-rampant-as-you-suspected/
I'm not saying Apple is necessarily not just as bad or worse in many of these aspects or others (I honestly don't know, I have never used an iPhone), but to suggest Android is anything less than a pile of incompetence and absolute shit is just utterly wrong.
>>51255589
I can customize my android and it's still within warranty as long as I don't change the hardware.
>>51255617
>Android can be used without any proprietary components
Not in a cellphone it can't.
>claim to be botnet free
>own a phone
>>51256023
To be fair, yes it can. You can use it as a cellphone without proprietary parts.
You can't really do much _else_ though. As a smartphone, it's basically anemic without Google's black box frameworks.
>>51255886
>>51255728
>>51255617
The problem is that Google is contributing less and less to AOSP and moving more and move into their proprietary applications. I suspect that Google would love if AOSP just died completely.
>>51256034
>claims to be botnet free
>breathes
>>51256041
Na, the cellular drivers are proprietary.
>>51255956
>>51255990
>>51256007
These are just a selection of issues which could be mentioned against Android. They are just the things I had jotted down on a notepad on my desk as I'm writing an essay on the design of Android and the prevalence of anti-patterns at every level.
If you can refute any of them, please do so, and link sources if you can. If you can add to these concerns at all, that's welcomed too.
But really, for a moment, consider your phone as a first-class platform equalled to a desktop. I mean, that is obviously what every smartphone vendor is trying to do with smartphone operating systems.
Now, just imagine, if you hold your phone's OS to the same standards you would hold your desktop OS to, how exactly would Android match up in all honesty?
If Microsoft released a version of Windows with these types of issues, they would be absolutely berated for it.
only way around the botnet is to not use a smartphone
am I wrong?
>>51256041
Other way around. You can use it as a smartphone without any proprietary software just fine, but the actual broadband firmware is proprietary by law.
>>51256148
> the actual broadband firmware is proprietary by law.
> by law
No it's not.
Although baseband firmware is a huge concern in and of itself. OSNews did a decent article:
http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone
>>51256121
>I'm writing an essay on the design of Android and the prevalence of anti-patterns at every level.
What do you mean by 'anti-patterns'?
What is that essay for? Academy? Work?
>>51256186
You can't legally sell a device with modifiable baseband firmware, due to a law that requires that all devices communicating with cell networks must be certified by the FCC.
>>51256249
>What do you mean by 'anti-patterns'?
Design choices which are precisely contrary to the problem they attempt to solve.
>>51256249
>What is that essay for? Academy? Work?
Academic, but I also want to draw attention to these things in general, because nobody really is.
>>51255956
I disagree with wakelocks being a terrible idea, it's just badly implemented. You could fix the majority of wakelock issues with pic related and by implementing a wakelock governer for apps that need to hold a wakelock for an indeterminate amount of time (like a dialer/phone app).
The main problem is that the default method of acquiring a wakelock has no timeout and relies on the application reaching the release. If your app is poorly made and hits an exception before the wakelock is released you can end up with a stuck wakelock this way.
Android is actually really aggressive in putting the processor to sleep, even in the 4.0~4.4 area when I was writing my Hourly Announcer app and was having to deal with this shit I found that I needed to implement a wakelock in order to keep the device awake long enough to start playing an audio file, less than 200ms after waking up from the alarm.
>>51256258
That doesn't mean they can't be openly licensed and the code freely available. It just means that you cannot use your own modified derivation of the baseband firmware without getting it certified.
>>51256276
>The main problem is that the default method of acquiring a wakelock has no timeout and relies on the application reaching the release. If your app is poorly made and hits an exception before the wakelock is released you can end up with a stuck wakelock this way.
This is what we call a flaw. It's the job of the system to abstract these things from applications. Even if the application is misbehaving, this type of fault should never be possible.
Really, the vast majority of use cases for wakelocks _should_ be solved by a proper service infrastructure, but are not. I'm not saying wakelocks can't be useful if otherwise implemented. I'm saying that Android's definition of a wakelock is an anti-pattern.
>>51256316
I'm going to take a nice big post-coffee shit. If anyone has a counter argument to what I've said, I'll respond to it in a few.
>>51256272
Nice. Will you make a thread here about it when you publish it?
>>51256316
But isn't it because it is abstracted from the application that's the problem?
The system is what is actually handling the wakelock, the application receives just a token to use as reference. The problem is the loss of this token means the loss of ability to release the wakelock unless it is on a timeout.
iOS , android, its all the same garbage shit with different names
both violate your freedoms and anything else, fuck em senpai
You know what we should do /g/? Make a FOSS phone OS from the ground up. Or at least base it on something like Sailfish. How hard can it be? Couldn't someone just take Arch ARM and add support for phone networks? I'd be down to use that, even if I couldn't use google play apps. The only thing I need my phone to do is play music, and browse the web. Maybe take pictures as well.
>>51256532
I'll start on the logo
>>51256361
I don't know how many people here are really interested in serious discussions. I'm really trying to prompt people within key groups to sit up and pay attention. Lots of people know Android is problematic, and know there's rampant bad design throughout, and know it's a mess, but they'd rather just ignore the problem, or hope somebody else will call it to attention. No meaningful work is being done in the academic circles to address these problems and say "no, you don't do it like that" and "no, this is blatantly irresponsible of you, Google" and "here, this is how you SHOULD fix this".
Windows didn't get a proper security model on its own. It took people criticizing it since XP and earlier for Microsoft to get in line, and it's not perfect nowadays, but it's a whole lot better than it used to be.
Well, Android is basically the Windows 98 of the smartphone world right now, and nobody's pushing for meaningful improvement, yet.
The other players in the smartphone ecosystem probably need to hear these lessons too, because it's still an immature ecosystem, and these same mistakes are being repeated even in little internal research projects as companies try to develop possible competitors to or successors of Android. Do we want the next generation of mobile OS to be just as bad?
(Sorry, I guess I kinda broke into rant there.)
>>51256435
Sounds to me like they sit at the wrong level of abstraction.
>>51256532
>You know what we should do /g/? Make a FOSS phone OS from the ground up. Or at least base it on something like Sailfish. How hard can it be?
As always, if you can't do it, it won't be done. No matter how great it would be in theory.
>>51255589
Implying IOS it's the botnet.
>>51255589
android and ios are equally botnet at highest level.
>http://techscience.org/a/2015103001/
