Electronics-Related.com
Forums

Why apps?

Started by Jeroen Belleman January 8, 2022
Tom Del Rosso wrote:
> Don Y wrote: >> >> It is amusing that no one has developed a sandbox that you can >> interpose between any/every app and your actual resources. This >> would allow the user to see *which* resources are ACTUALLY being >> accessed as well >> as allowing you to "dummy up" some bogus resources to appease/confuse >> the app. >> "Yeah, my address book has just one contact in it -- and that >> happens to be the email address of the app's CEO! Please feel >> free to spam him." >> (of course, the next app has the email of THAT app's CEO in its place) >> >> I.e. turn every phone into a honeypot. > > Google's OS and Apple's OS probably wouldn't allow it. If more people > had Linux phones it could be done, but they cost around $800 which gives > an idea how much Google and Apple make from your phone. > >
Nah, you can get a Pinephone for $200. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
In article <src2v1$a58$1@gioia.aioe.org>, jeroen@nospam.please says...
> > For years, interaction with the internet worked through a > universal browser. Lately, every service, gadget or whatnot > wants you to download their special-purpose app. Why?? > What's the deal? It seems like a huge step backwards to me. > > Jeroen Belleman
They don't have to tell you what "cookies" they are storing...
On 08/01/2022 13:18, Jeroen Belleman wrote:
> For years, interaction with the internet worked through a > universal browser. Lately, every service, gadget or whatnot > wants you to download their special-purpose app. Why?? > What's the deal? It seems like a huge step backwards to me. > > Jeroen Belleman
Spyware. Profiling and selling personal data. Just look at the ridiculous permissions many of them request by default. I agree it seems to be a retrograde step to have everything as an app and it clutters up the screen to hell with random icons some of which only make sense to the dope headed Californian designer on an acid trip. A bit like with browser cookies most people just click OK without even a second though about why a supermarket would want access to your photos, email and phone contacts list, microphone and webcam. The odd one can be useful like an app for finding the nearest bank machine which has its compressed database and map data in the phone. (memory is cheap so some things do work better this way) Unfortunately in the UK they are closing banks and their machines left, right and centre so you do have to update it fairly often if you want to be directed to a still working one as opposed to a blanking plate where a hole in the wall bank machine and a bank used to be! Cash has become a lot less common thanks to Covid - everyone prefers contactless payment these days. Limit for that now raised to &pound;100. -- Regards, Martin Brown
On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:

> It is amusing that no one has developed a sandbox that you can interpose > between any/every app and your actual resources. This would allow > the user to see *which* resources are ACTUALLY being accessed as well > as allowing you to "dummy up" some bogus resources to appease/confuse > the app.
Yeah, and Java was envisioned (write once, run anywhere...) as an interface between every app and actual resources. The three B's kinda ruined that. Bugs, bloat, business. Can't live with 'em, can't live without 'em. Bugs buried in a third-party library with no one accepting responsibility means that software and firmware can become untenable, and unfixable. Bloat in use of oddball functions means you need versions of firmware, software, and addons to match some arbitrary list of specifications or the new (or even old) app won't run. There's no clear listing available, of course.... Business decisions (or outright collapses, or purchases/mergers) take away infrastructure, so the box can't run. Or, phone-home functions are required to un-brick the thing, and there's no one home when the checks don't arrive regularly.
On 1/9/2022 12:38 PM, whit3rd wrote:
> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote: > >> It is amusing that no one has developed a sandbox that you can interpose >> between any/every app and your actual resources. This would allow >> the user to see *which* resources are ACTUALLY being accessed as well >> as allowing you to "dummy up" some bogus resources to appease/confuse >> the app. > > Yeah, and Java was envisioned (write once, run anywhere...) as > an interface between every app and actual resources. > > The three B's kinda ruined that. > > Bugs, bloat, business. Can't live with 'em, can't live without 'em. > > Bugs buried in a third-party library with no one accepting responsibility > means that software and firmware can become untenable, and unfixable. > > Bloat in use of oddball functions means you need versions of firmware, software, > and addons to match some arbitrary list of specifications or the new (or even old) app won't run. > There's no clear listing available, of course.... > > Business decisions (or outright collapses, or purchases/mergers) take away > infrastructure, so the box can't run. Or, phone-home functions are required > to un-brick the thing, and there's no one home when the checks don't arrive regularly.
All of these are "survivable" *if* you have control over the design. The ENTIRE design. For a business, that means owning source licenses to all hardware and software. Sadly, for a *consumer* (| user), it means the same thing! Because having all of that reside in the arms of a vendor does YOU no good if the vendor decides not to support it any longer. [I think anyone who buys a "smart appliance" is begging to be screwed-over in the future. How long does a vendor support a "smart TV"? Do the codecs keep being upgraded/repaired? Or, does the vendor move on to developing Model N+1 with the newer codecs and leaving the older model(s) to languish? (i.e., treat your TV as a DUMB *monitor* and move all of the smarts *out* of it and into an appliance that YOU can control)] Gotta wonder about these smart refrigerators, thermostats, "Alexa", etc. How much of the functionality is *in* the device and how much relies upon some other service? (when that service goes away, you've got a dumb little box that can't even be repurposed to fill its original role!) [Of course, the vendor can rationalize moving the smarts out of the device and into a service as a means of driving the per unit cost down AND facilitating improvements to the service without "push updates". And, you're just *renting* the device, after all...]
On Saturday, January 8, 2022 at 5:37:19 PM UTC, Phil Hobbs wrote:
> Jeroen Belleman wrote: > > For years, interaction with the internet worked through a > > universal browser. Lately, every service, gadget or whatnot > > wants you to download their special-purpose app. Why?? > > What's the deal? It seems like a huge step backwards to me. > > > > Jeroen Belleman > The way they ask for ridiculously broad permissions should be a clue. > > "Why does Walmart need access to my camera, phone, and messages?" > > One guess. > > Cheers > > Phil Hobbs > > -- > Dr Philip C D Hobbs > Principal Consultant > ElectroOptical Innovations LLC / Hobbs ElectroOptics > Optics, Electro-optics, Photonics, Analog Electronics > Briarcliff Manor NY 10510 > > http://electrooptical.net > http://hobbs-eo.com
One reason could be, sloppy programming. Developers use old past-practices or carry-overed modules, and would rather assume they "need it" to get the product working & out the door, rather than stop, consider the user's privacy & security concerns. my organization has a a digital lab division, working on these consumer issues. They released a "Digital Standard" document, which we are rolling out as way to evaluate connected products. WiFi routers, TVs, apps, etc. Printers, for example, largely the situation I describe above. cheers, RS
Phil Hobbs wrote:
> Tom Del Rosso wrote: >> >> Google's OS and Apple's OS probably wouldn't allow it. If more people >> had Linux phones it could be done, but they cost around $800 which >> gives an idea how much Google and Apple make from your phone. >> >> > > Nah, you can get a Pinephone for $200.
Wow. I only looked at the high end with switches to power off components. -- Defund the Thought Police Andiamo Brandon!
On 1/9/2022 22:27, Don Y wrote:
> On 1/9/2022 12:38 PM, whit3rd wrote: >> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote: >> >>> It is amusing that no one has developed a sandbox that you can interpose >>> between any/every app and your actual resources. This would allow >>> the user to see *which* resources are ACTUALLY being accessed as well >>> as allowing you to "dummy up" some bogus resources to appease/confuse >>> the app. >> >> Yeah, and Java was envisioned (write once, run anywhere...) as >> an interface between every app and actual resources. >> >> The three B's kinda ruined that. >> >> Bugs, bloat, business.&nbsp;&nbsp; Can't live with 'em, can't live without 'em. >> >> Bugs buried in a third-party library with no one accepting responsibility >> means that software and firmware can become untenable, and unfixable. >> >> Bloat in use of oddball functions means you need versions of firmware, >> software, >> and addons to match some arbitrary list of specifications or the new >> (or even old) app won't run. >> There's no clear listing available, of course.... >> >> Business decisions (or outright collapses, or purchases/mergers) take >> away >> infrastructure, so the box can't run.&nbsp;&nbsp; Or, phone-home functions are >> required >> to un-brick the thing, and there's no one home when the checks don't >> arrive regularly. > > All of these are "survivable" *if* you have control over the design. > The ENTIRE design. > > For a business, that means owning source licenses to all hardware and > software.
But this is not realistic unless you are the galaxy emperor... We do not depend on anyone for software, so what. Cut us the silicon and we are dead.
> > Sadly, for a *consumer* (| user), it means the same thing!&nbsp; Because having > all of that reside in the arms of a vendor does YOU no good if the vendor > decides not to support it any longer. > > [I think anyone who buys a "smart appliance" is begging to be screwed-over > in the future.&nbsp; How long does a vendor support a "smart TV"?&nbsp; Do the codecs > keep being upgraded/repaired?&nbsp; Or, does the vendor move on to developing > Model N+1 with the newer codecs and leaving the older model(s) to languish? > (i.e., treat your TV as a DUMB *monitor* and move all of the smarts > *out* of > it and into an appliance that YOU can control)] > > Gotta wonder about these smart refrigerators, thermostats, "Alexa", > etc.&nbsp; How > much of the functionality is *in* the device and how much relies upon some > other service?&nbsp; (when that service goes away, you've got a dumb little > box that > can't even be repurposed to fill its original role!) > > [Of course, the vendor can rationalize moving the smarts out of the device > and into a service as a means of driving the per unit cost down AND > facilitating improvements to the service without "push updates".&nbsp; And, > you're just *renting* the device, after all...]
They are all going this way as far as they can manage it of course. Design software people use (not us, we have our own) is nowadays based on yearly subscriptions, so is office etc. Exceptions/ways through it still exist I guess but for how long. The picture is turning pretty dystopian and all we can do is just live the rest of our lives the best we can, I don't think we can do much to avoid a catastrophe. Let's take it as easy as we can - while it lasts :-).
On 1/9/2022 2:57 PM, Dimiter_Popoff wrote:
> On 1/9/2022 22:27, Don Y wrote: >> On 1/9/2022 12:38 PM, whit3rd wrote: >>> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote: >>> >>>> It is amusing that no one has developed a sandbox that you can interpose >>>> between any/every app and your actual resources. This would allow >>>> the user to see *which* resources are ACTUALLY being accessed as well >>>> as allowing you to "dummy up" some bogus resources to appease/confuse >>>> the app. >>> >>> Yeah, and Java was envisioned (write once, run anywhere...) as >>> an interface between every app and actual resources. >>> >>> The three B's kinda ruined that. >>> >>> Bugs, bloat, business. Can't live with 'em, can't live without 'em. >>> >>> Bugs buried in a third-party library with no one accepting responsibility >>> means that software and firmware can become untenable, and unfixable. >>> >>> Bloat in use of oddball functions means you need versions of firmware, >>> software, >>> and addons to match some arbitrary list of specifications or the new (or >>> even old) app won't run. >>> There's no clear listing available, of course.... >>> >>> Business decisions (or outright collapses, or purchases/mergers) take away >>> infrastructure, so the box can't run. Or, phone-home functions are required >>> to un-brick the thing, and there's no one home when the checks don't arrive >>> regularly. >> >> All of these are "survivable" *if* you have control over the design. >> The ENTIRE design. >> >> For a business, that means owning source licenses to all hardware and >> software. > > But this is not realistic unless you are the galaxy emperor... We do not > depend on anyone for software, so what. Cut us the silicon and we are > dead.
You can always find another source for silicon. If the design is locked up behind closed doors, NDAs, <whatever>, then having all the silicon in the world won't help you if the vendor stops selling the item that you need. We designed a $300K device that relied on a $5K software license. Vendor stopped issuing licenses. What recourse did we have? It's not that the "item" disappeared from the face of the Earth... just was no longer available for our LEGAL use. We either stop selling our existing product *or* redesign it to use some other replacement for that licensed component. Of course, vendor would love to sell us some NEW component to take its place. But, would we want to open ourselves up to his intransigence on a *future* decision to stop selling THAT license?
>> Sadly, for a *consumer* (| user), it means the same thing! Because having >> all of that reside in the arms of a vendor does YOU no good if the vendor >> decides not to support it any longer. >> >> [I think anyone who buys a "smart appliance" is begging to be screwed-over >> in the future. How long does a vendor support a "smart TV"? Do the codecs >> keep being upgraded/repaired? Or, does the vendor move on to developing >> Model N+1 with the newer codecs and leaving the older model(s) to languish? >> (i.e., treat your TV as a DUMB *monitor* and move all of the smarts *out* of >> it and into an appliance that YOU can control)] >> >> Gotta wonder about these smart refrigerators, thermostats, "Alexa", etc. How >> much of the functionality is *in* the device and how much relies upon some >> other service? (when that service goes away, you've got a dumb little box that >> can't even be repurposed to fill its original role!) >> >> [Of course, the vendor can rationalize moving the smarts out of the device >> and into a service as a means of driving the per unit cost down AND >> facilitating improvements to the service without "push updates". And, >> you're just *renting* the device, after all...] > > They are all going this way as far as they can manage it of course. > Design software people use (not us, we have our own) is nowadays > based on yearly subscriptions, so is office etc. Exceptions/ways > through it still exist I guess but for how long.
You stick with what you already have/had -- insofar as it is able to meet your ongoing needs. Or, embrace more "open" offerings... often with the need to make some commitment (time or money) to ensuring their continued availability, development, etc. (Too often, folks buy into FOSS for $0 -- thinking it "free" and not realizing that it can go away just as easily, without support, as any other offering!)
> The picture is turning pretty dystopian and all we can do is > just live the rest of our lives the best we can, I don't think we > can do much to avoid a catastrophe. > Let's take it as easy as we can - while it lasts :-).
On 1/10/2022 0:06, Don Y wrote:
> On 1/9/2022 2:57 PM, Dimiter_Popoff wrote: >> On 1/9/2022 22:27, Don Y wrote: >>> On 1/9/2022 12:38 PM, whit3rd wrote: >>>> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote: >>>> >>>>> It is amusing that no one has developed a sandbox that you can >>>>> interpose >>>>> between any/every app and your actual resources. This would allow >>>>> the user to see *which* resources are ACTUALLY being accessed as well >>>>> as allowing you to "dummy up" some bogus resources to appease/confuse >>>>> the app. >>>> >>>> Yeah, and Java was envisioned (write once, run anywhere...) as >>>> an interface between every app and actual resources. >>>> >>>> The three B's kinda ruined that. >>>> >>>> Bugs, bloat, business.&nbsp;&nbsp; Can't live with 'em, can't live without 'em. >>>> >>>> Bugs buried in a third-party library with no one accepting >>>> responsibility >>>> means that software and firmware can become untenable, and unfixable. >>>> >>>> Bloat in use of oddball functions means you need versions of >>>> firmware, software, >>>> and addons to match some arbitrary list of specifications or the new >>>> (or even old) app won't run. >>>> There's no clear listing available, of course.... >>>> >>>> Business decisions (or outright collapses, or purchases/mergers) >>>> take away >>>> infrastructure, so the box can't run.&nbsp;&nbsp; Or, phone-home functions are >>>> required >>>> to un-brick the thing, and there's no one home when the checks don't >>>> arrive regularly. >>> >>> All of these are "survivable" *if* you have control over the design. >>> The ENTIRE design. >>> >>> For a business, that means owning source licenses to all hardware and >>> software. >> >> But this is not realistic unless you are the galaxy emperor... We do not >> depend on anyone for software, so what. Cut us the silicon and we are >> dead. > > You can always find another source for silicon.&nbsp; If the design is locked > up behind closed doors, NDAs, <whatever>, then having all the silicon > in the world won't help you if the vendor stops selling the item that > you need. > > We designed a $300K device that relied on a $5K software license. > Vendor stopped issuing licenses.&nbsp; What recourse did we have?&nbsp; It's > not that the "item" disappeared from the face of the Earth... just > was no longer available for our LEGAL use. > > We either stop selling our existing product *or* redesign it to > use some other replacement for that licensed component.&nbsp; Of course, > vendor would love to sell us some NEW component to take its place. > But, would we want to open ourselves up to his intransigence on > a *future* decision to stop selling THAT license? > >>> Sadly, for a *consumer* (| user), it means the same thing!&nbsp; Because >>> having >>> all of that reside in the arms of a vendor does YOU no good if the >>> vendor >>> decides not to support it any longer. >>> >>> [I think anyone who buys a "smart appliance" is begging to be >>> screwed-over >>> in the future.&nbsp; How long does a vendor support a "smart TV"?&nbsp; Do the >>> codecs >>> keep being upgraded/repaired?&nbsp; Or, does the vendor move on to developing >>> Model N+1 with the newer codecs and leaving the older model(s) to >>> languish? >>> (i.e., treat your TV as a DUMB *monitor* and move all of the smarts >>> *out* of >>> it and into an appliance that YOU can control)] >>> >>> Gotta wonder about these smart refrigerators, thermostats, "Alexa", >>> etc.&nbsp; How >>> much of the functionality is *in* the device and how much relies upon >>> some >>> other service?&nbsp; (when that service goes away, you've got a dumb >>> little box that >>> can't even be repurposed to fill its original role!) >>> >>> [Of course, the vendor can rationalize moving the smarts out of the >>> device >>> and into a service as a means of driving the per unit cost down AND >>> facilitating improvements to the service without "push updates".&nbsp; And, >>> you're just *renting* the device, after all...] >> >> They are all going this way as far as they can manage it of course. >> Design software people use (not us, we have our own) is nowadays >> based on yearly subscriptions, so is office etc. Exceptions/ways >> through it still exist I guess but for how long. > > You stick with what you already have/had -- insofar as it is able > to meet your ongoing needs. > > Or, embrace more "open" offerings... often with the need to make some > commitment (time or money) to ensuring their continued availability, > development, etc. > > (Too often, folks buy into FOSS for $0 -- thinking it "free" and not > realizing that it can go away just as easily, without support, as > any other offering!) >
Well we have dps for power only but it comes with everything necessary to do all the software for pretty sophisticated products without needing a single bit of software from anyone else. How does product lifetime licensing sound? :-)