Android Chrome retardság

Az évek során megkerülendő az Android alkalmazások használhatósági poklát, írtam pár apróbb JS szösszenetet ami hasznos volt a mindennapi munkában és hobbizásban. Ezek közül pár erősen épített a mobiltelefon különféle beépített eszközeinek(audio, kamera, szenzor) az elérésére.
Aztán volt egy telefonváltás és hirtelen az alkalmazások fele nem ment. Nem foglalkoztam vele, mert nem kellett. Aztán úgy jött az élet, hogy mégiscsak kellettek.

Az első probléma, hogy az Android kivezette a "file://" támogatását. Helyette lett "content://". 
A másik fájdalmasabb kreténség a https erőltetése. Esetünkben, hogy Android Chrome 50-es verzió felett a nem https-en keresztül hostolt oldalak nem kapnak hozzáférési engedélyt az eszköz peridériáihoz, és nincs overdrive lehetőség. Igen, a lokális fileok sem. A vicc, hogy egy ideig még "Content Policy" meta taggal ki lehetett trükközni, de egy ideje az sem megy.

A jelenlegi szituáció az, hogy amennyiben a saját telefonomon, saját telefonom eszközeit, saját magam által írt javascripttel akarom használni, akkor saját https szervert kell telepítenem és erre saját certet  szereznem.

A dolog iróniája, hogy a TCL telefonok, ki tudja milyen kínai gyártó böngészőnek álcázott alap kémprogramja riccenés nélkül teszi a dolgát.

Hogy mi értelme ilyen szintű kreténnek lenni azt nem tudom, de biztos van rá egy 4 betűs magyarázat...

( Nyosigomboc v | 2025. 04. 29., k – 22:24 )

Alternativ bongeszo nem jon szoba, ha amugy is sajat celra kell? Fennec, Brave, stb.

A strange game. The only winning move is not to play. How about a nice game of chess?

( NagyZ v | 2025. 04. 30., sze – 10:28 )

szerintem ez igy rendben van, es PEBKAC.

Alapvetően azért, mert ez is az eszköz biztonságát növeli. Az, hogy a nem HTTPS-ről letöltött JS scriptek nem érnek el perifériákat, az növeli az eszköz védettségét, nem tudnak olyan egyszerűen mindenféle szart beinjektálni. Kell 1-2 extra kör. Nyilván ez nem véd minden ellen, de ez is egy védelmi réteg, és van akit-amit már ez is elriaszt.

Szerintem fusd át az MDN-en a legújabb webfejlesztési és böngészőstandardokat, sokat és sokminden változott. Én se értek egyet mindennel, és nekem is sok fejfájást okoznak ezek (főleg a böngészők HTTPS-erőltetése), de ilyenkor mindig próbálok kettőt hátralépni, és felteszem azt a kérdést, hogy ha nem azért léteznek ezek a dolgok, hogy személy szerint velem kibasszanak, akkor vajon miért? Sokszor segít megérteni, még ha a megértés nem feltétlen teszi könnyebbé is az életemet.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Miért? Mi különbség van egy https-en keresztül és egy nem https-en keresztül letöltött kártékony kód között? Ma már az utolsó scammer is https mögül küldi a szarjait. Miért csak a perifériákat tiltja le? Érdekes módon, tudok képet átméretezni lokális html5 lap segítségével, sőt a kamera engedélyezést is meg tudom kerülni vanilla html5 input methodussal, mert addig már nem futotta nekik, hogy a html5 motort is eltörjék ne csak a javasciptet.

Nem, itt egy dolog van. A JSben megírt lokálisan futtatott 300 byteos html képes kiváltani egy 50-60MB-os, Googlenek pénzt termelő alkalmazást. Ez ami fáj a Googlenek.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Mi különbség van egy https-en keresztül és egy nem https-en keresztül letöltött kártékony kód között

maga az injectalast neheziti hogy nem pure js kozlekedik es beleirhat barki-barmit. sslben kuldott tartalmat modositani azert nem trivialis.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Továbbra sem világos, hogyha a fingóapp tudja módosítani az én fileomat, akkor miért ne tudná módosítani a browser chachet és ilyen esetben miért fogja a browser validnak értékelni és futtatni a cacheben lévő scriptet (lévén a browser szerint az https-en keresztül jött, tehát trusted) és miért nem futtatja a lokális fileomat (nem trusted). Magyarán semmi nem indokolja, hogy miért pont a https megléte validálja a JS kód futtatását. 

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Az app cache-éhez másik app nem fér hozzá, a megosztott tárterülethez viszont bármilyen app hozzáférhet, ami erre engedélyt kért és kapott.

Egyébként nem tudod becsomagolni a html filejaidat egy app-ba? Biztos van erre valami tool vagy template.

Az app chahce exploit témába nem megyek bele, részint mert nem értek hozzá, részint mert volt már erre exploit, de nincs időm/energiám utánamenni.
 

Miért nem csomagolom egy appba?
1. Nincs kedvem egy komplett appot karbantartani.
2. A html+js filet a buszon ülve is tudom reszelni a telefonon. (Hello natív app fejlesztés)
3. Adott az app amit úgy hívnak, hogy böngésző, csak egy mondvacsinált indokkal korlátozták az eszközökhöz való hozzáférést a Chrome-ban.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Persze, ahogy a böngésző chachében lévő kódot sem módosíthatja semmi. Hogyne. Kicsit keverve van a szezon a fazonnal.

A ssl a transzport csatornában védi a tartalmat, ami az eszköznél véget ér. Amint beér az eszközbe a tartalom, onnantól egyenértékű bármelyik másik eszközön tárolt tartalommal.
 

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ha mondjuk exploit írással foglalkoznék, akkor nem igazán látom, hogy ez hogy nehezítené meg annyira a dolgomat.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."