5 ms·
I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users. Back in the Android 5 (or so) days, I knew what permis
by c0l0 6y ago
I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users.
Back in the Android 5 (or so) days, I knew what permissions an app I was going to install on my mother's phone was going to ask to be granted _once_, and be done with it. Nowadays, an app might ask for some kind of new permission "on first use", and users on mobile are developing the same habit as users of desktop browsers during the dark ages of expired HTTPS certificates and broken Java Applet signatures had developed out of necessity: "default-ack/OK all the things".
The problem is that these days, even very technical people think that you could realistically expect to lie with dogs, and get up without fleas - i.e., install applications and software you cannot trust, and get away without having something bad (like loss of privacy, or maybe exfiltration of data) happen. All thanks to "modern" security constructs like sandboxing.
But that is not going to happen - sandboxes have been shattered and broken in the past, as they will continue to get circumvented in the future. There simply is no replacement for trust (in an application, its developers, its distributor, and its operator (if any)), and there are no technical solutions that could somehow replace it in full.
Yes, you can make it incrementally less bad to have a hostile agent/app on your machine or phone, but the trouble you're trying to prevent that way will never go away completely.
I guess some people just liked to feel "in control" when clicking away their "Norton Professional Antivirus 95 blocked 17 Viruses from damaging your machine today!" messages back in the day, and some apparently cherish clicking "grant 'Sexy FileManager Free Pro' access to your Photos and Videos" today. Personally, I'm actually rather sick of it, and all the security theatre that "modern" application delivery mechanisms like app stores/mobile platforms or stuff like snaps/appimage/younameit would have you participate in. I'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions. I know I can't audit everything, but I feel like I'm much better off with that kind of trade-off, than with the non-solution to the problem I tried to describe above.
Edit: Removed a leftover part of a restructured sentence.
- WrtCdEvrydy 6y agoThe problem isn't the sandbox, it's inherently the issue with lack of fine grained permissions and being unable to revoke permissions after installation. Wanna see a real permission model, look at the BB10 Android Player model. After installation, you could revoke permissions and the player would basically act as if the data from that permission was just empty. App asks for contacts, here's an empty contacts list. Edit: I just did a small hackathon and ended up having to request full BLUETOOTH Access and LOCATION access to connect to a label printer... how is this long term sustainable.
- com2kid 6y agoThe reason for location permissions is because BT can track your location through Bluetooth beacons. See https://developer.android.com/guide/topics/connectivity/bluetooth https://developer.android.com/guide/topics/connectivity/blue... This is just Android being transparent. "Bluetooth usage may allow apps to track your location." Which is perfectly true. There has to be a balance between explaining to the user, e.g. that there are multiple ways their location can be tracked, and permission request overload. I don't imagine explaining to everyday users the details of the Bluetooth protocol is viable.
- cestith 6y ago> I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users. Are you sure you didn't mean "EPOC" pain? Maybe "EPOC32" pain? ;-) - a Psion owner
- Zenst 6y agoAlso if a Series 5 Psion, an early owner of mobile ARM in its younger days.
- edeion 6y agoEven though it's sort of an aside, I'm glad someone mentions Psion. I'd love to check whether their keyboards are on par with the legend. I wonder how many others relate, at the global scale :)
- Zenst 6y agoFor the time, it was good, maybe better mechnisms available now, but darn - it was built to last and my 5MX still works. Though a lot of psions market was retail/stock warehous stuff, their handheld terminals had a huge market. So robust design was key. Only design issue on the 5MX that griped me was the stylus holder spring being not as industrial designed. Apart from that, all works well. Since then, dreamed of some comparable device, basic linux, enough for vi and terminal stuff, wifi/bluetooth and well, happy with the screen. Alas all devoplment of anything close, tend to wack in CPU's that would be classed as a supercomputer of the 5MX time, power hogging colour screens and you end up with devices that will last a day perhaps, but not the month the 5mx would pull with comparable usage with the rs232 adapter. Hence a cheap terminal, basic local editor wifi device in that form factor and if it could do bluetooth and double as a keyboard for a smartphone, well, a simple device like that would tick my boxes and maybe many others.
- cestith 6y agoMy 3, 3a, 5, and 5MX all still work (as do my Atari Portfolios and HP LX series palmtops, save one 200LX with physically damaged screen. I too keep wanting to see something like the 5Mx, or the PS-1000, or something similar with modern specs. I don't need the screen to be fast, just useful and low power. The 16-color E-Ink screens I keep reading about in Chinese tablets should work. Big battery for the form factor wouldn't hurt, but we used to use AAs. A dual-core or quad-core A53 with all solid-state storage, a nice legible low-power screen, and a great little keyboard would be quite a find.
- autoexec 6y ago> 'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions. Trusting 3rd parties to decide what you can trust isn't ideal either. It's what Google and (especially) Apple have for mobile apps now. They decide what you can safely install and we're just supposed to trust them. That's clearly not working. While you have the added benefit of being able to trawl over thousands of lines of code looking for something suspicious, that's not exactly scalable or even possible for the majority of users. In the end, what exactly are you looking for anyway if not signs that an application is making connections or accessing files that it shouldn't. In that respect, it's far better to have the OS just tell users when an application is doing those things (connecting to the internet, reading their personal files, or activating their cameras). The more transparency in what an app is doing the better because the reality is that we cannot trust every app we install. How could we possibly?
- icebraining 6y agoI think you have to believe in sandboxes if you use the modern web; each site you load is effectively a program you are running on your machine, with only a sandbox protecting it.