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...

Hozzászólások

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?

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. "

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. "