Spotify ondersteunt Safari niet meer

De op het web gebaseerde speler van Spotify werkt niet langer in combinatie met de Safari-browser op macOS. Apple-gebruikers die de dienst in de browser willen gebruiken, moeten overstappen op alternatieven, is het advies van Spotify.

Wie open.spotify.com opent in Safari 10 op een Mac-systeem, krijgt een melding dat de browser de Spotify Web Player niet ondersteunt. De dienst raadt aan een andere browser te gebruiken of over te stappen op de Spotify-applicatie voor macOS.

In een reactie op vragen van gebruikers hierover bevestigt de supportafdeling van Spotify dat Safari niet langer ondersteund wordt. Dat meldt een gebruiker op het forum van de dienst. Als reden noemt het bedrijf alleen dat 'er functies toegevoegd of verwijderd worden om Spotify beter te maken'. Hij kon niet zeggen of specifieke functies voor ondersteuning terugkeren.

De gebruiker verwijst naar een uitlegpagina om de Spotify Web Player werkend te krijgen bij problemen, waar gesproken wordt over een Widevine-plug-in. De Widevine Media Optimizer is een tool die door Google is ontworpen voor de decryptie van mediastreams, maar Safari acht de plug-in niet veilig genoeg en accepteert de installatie daarom niet.

Reacties (230)

Er is een heel simpele technische verklaring voor: het type encryptie.

Spotify wil blijkbaar overal DRM doordrukken. In webbrowsers is dat te begrijpen, anders is iedereen direct met je AAC/OGG Vorbis aan de haal. Er is één standaardframework voor DRM (de HTML5 Encrypted Media Extensions). Je hebt daarmee een interface die zegt hoe content decryption modules werken.

Er zijn verschillende content decryption modules, afhankelijk van de browser:
Chrom(e/ium), Firefox, Opera: Widevine (Google)
Edge: PlayReady (Microsoft)
Safari: FairPlay (Apple).
(Flash: Access - Adobe)

Widevine en PlayReady werken allebei gewoonlijk met DASH en gebruiken meestal AES-CTR als encryptiemethode. De encryptie en 'inkapseling' is gelijk, enkel de manier waarop de key wordt opgehaald en verwerkt is anders. Dit zorgt ervoor dat je met één bronbestand Widevine en PlayReady-browsers kan ondersteunen met enkel wat minimale verschillen in JS.

Apple is met FairPlay nét dat beetje anders. Apple verwacht dat je voor FairPlay je bronbestanden online zet in HLS-formaat (met TS-segmenten). De encryptie moet sample-AES zijn (of eventueel AES-CBC in recente versies). (Voor Netflix heeft Apple een uitzondering gemaakt en ondersteunen ze ook DASH met AES-CTR, maar niemand anders kan/mag dat.)

Spotify heeft hierbij dus duidelijk gekozen voor de oplossing die maar de helft aan storage kost: enkel Widevine en PlayReady.. Om Safari nog te ondersteunen zouden ze ofwel Flash in leven moeten houden (in 2017 geen optie), of alle audio dubbel op hun CDN zetten (een versie voor Safari en een versie voor alle andere browsers). Ook op macOS is Chrome de meest populaire browser, Safari in het algemeen heeft een relatief klein aandeel op desktop. Om voor weinig extra users veel extra storage te gebruiken is gewoon niet logisch.

Waarschijnlijk was alle audio vroeger zelfs al beschikbaar in een formaat dat compatibel is met DASH/AES-CTR (voor gebruik met Flash). De hele catalogus zonder Flash beschikbaar maken in Safari zou willen zeggen dat ze alles moeten her-encrypten.

Bron: ik werk op professioneel vlak erg veel met bovenstaande DRM in browsers.

(Bonus: het gaat ook helemaal niet om een plugin. Widevine Classic werkte inderdaad met een plugin die je zelf moest installeren, maar wordt niet meer gebruikt. Widevine Modular zit ingebakken in je browser (Chrome/Firefox/Opera), PlayReady zit ingebakken in Edge en FairPlay zit ingebakken in Safari. Allemaal exact hetzelfde qua functionaliteit, gewoon een ander protocol rond key retrieval.)

[Reactie gewijzigd door AmbroosV op 11 september 2017 15:37]

Het is dus met andere woorden de fout van Apple, die weigert om FairPlay via Dash streams toe te staan aan andere contentaanbieders. Ik vind het persoonlijk wel een goed standpunt van Spotify. Dash is een perfect werkende standaard, waarom moet alles dan weer anders op iOS?

Ook ik werk regelmatig met DRM streaming naar mobile devices en ik kan je vertellen, het is echt vervelend om zowel Dash+Widevine/PlayReady (voor Chrome, Firefox, Edge, Android) als HLS+FairPlay (Safari, iOS) te moeten ondersteunen. Alles zou zoveel makkelijker en goedkoper zijn moest Apple ook gewoon Dash ondersteunen.

Maar nee, Apple heeft liever weer haar eigen protocol in handen

Yep, wij zitten in exact dezelfde situatie en doen alles dubbel op dezelfde manier.

Apple heeft vorig jaar op WWDC heel trots aangekondigd dat ze CENC en fMP4 gingen ondersteunen en zo interopable gingen zijn met DASH. Een paar dagen later bleek dan dat ze enkel een klein deel van een nieuwe versie van CENC ondersteunen dat enkel beschikbaar is vanaf Android N (en iOS 10), en dus in de praktijk pas binnen ~4 jaar interessant gaat zijn voor contentproviders wanneer ze alle oudere platformen kunnen laten vallen.

Op het gebied van DRM-standaarden heb je echt gewoon de kampen "Apple" en "al de rest", en dat is niet leuk.

(En ik weet dat ik het al gezegd heb, maar toch, Netflix mag van Apple wél DASH met AES-CTR gebruiken in Safari en op iOS. Er zijn al pogingen gedaan om het te reverse engineeren maar het lukt tot nu toe niemand. Het is toch compleet idioot dat ze de functionaliteit om de standaarden te ondersteunen gewoon hebben liggen maar weigeren te documenteren en zo iedereen naar hun eigen (matige) standaarden pushen?)

[Reactie gewijzigd door AmbroosV op 11 september 2017 19:32]

Precies. Apple nodigt je graag uit om iTunes te gaan gebruiken hoor je muziek.

Precies. Apple nodigt je graag uit om iTunes te gaan gebruiken hoor je muziek.

Of gewoon spotify te installeren.

waarom moet alles dan weer anders op iOS?

macOS

Het is gezeur dat dat moet om Spotify te gebruiken. Het is Apple die vooruitgang actief tegenwerkt, dan vind ik het persoonlijk inderdaad goed dat Spotify voet bij stuk houdt en mensen aanspoort om andere browsers te installeren.

Wat dacht je van gewoon Chrome?

Die komt er hier niet op

De meest gebruikte browser is not steeds Safari op macOS hoor, en niet Chrome. Ergens wel logisch omdat je dit manueel extra moet installeren.

Als ik Safari was, zou ik een binaire plugin ook niet vertrouwen. Zijn we net een beetje af aan het stappen van binaire browserplugins door het uitfaseren van Flash en Java, wil zo'n Spotify er weer een nieuwe plugin in schuiven. Eentje van een advertentiebedrijf nog wel (Google).
Maar wat ik dus niet snap is, waarom is dit Safari-specifiek? Vertrouwen Firefox en Edge die plugin wel dan? Vooral Mozilla zou nooit zomaar een binaire DRM-plugin toelaten.

Ja, Widevine zit ook in Firefox.

Edit: hier is een mooi overzicht van welke browser welke DRM CDM ondersteunt. Spotify zou dus bijvoorbeeld wel Safari kunnen ondersteunen, maar dan moeten ze naast Widevine (Chrome, Firefox) en PlayReady (IE, Edge) ook FairPlay implementeren.

[Reactie gewijzigd door lonaowna op 11 september 2017 13:59]

Vooral Mozilla zou nooit zomaar een binaire DRM-plugin toelaten.

Volgens mij zit je er ver naast. Ten eerste is er niet zoiets als Open Source DRM (als je de code zelf kan compilen kan je veel meer doen dan weergeven op een scherm of afspelen: je kunt de code aanpassen om de content op te slaan). Ten tweede ondersteund Firefox een gesloten DRM van Adobe. Knarsetandend, maar ze zagen ook geen andere optie.
https://www.pcworld.com/a...ntegrated-by-default.html
Firefox licht het zelf netjes toe:
https://blog.mozilla.org/...s-management-and-firefox/

[Reactie gewijzigd door 84hannes op 11 september 2017 13:29]

Open Source DRM kan perfect. Het zijn enkel de sleutels die je niet zomaar kan vrijgeven. Je zal dus nooit een open source DRM oplossing kunnen compileren en daarmee de bestaande vervangen, puur omdat de cryptografische sleutels niet meer overeen zullen komen.

Klopt. En wat is de waarde van open Source als

• je niet kan verifiëren dat de code en de binary bij elkaar horen?
• je geen aanpassingen kan doorvoeren?

Vanuit academisch standpunt is het nog steeds interessant, maar praktisch gezien verlies je twee belangrijke eigenschappen die open source zo uniek maken.

De waarde is dat anderen de code weer kunnen benutten. Open-source betekent niet dat je aanpassingen moet kunnen doorvoeren.

De waarde is dat anderen de code weer kunnen benutten. Open-source betekent niet dat je aanpassingen moet kunnen doorvoeren.

Jij ontkent doodleuk de belangrijkste eigenschap van open source !

Open source betekent juist dat je zelf de software die je gebruikt kan compileren (en verifiëren dat er geen trojan in zit, en geen spyware, etc. etc.), en óók dat je zelf die software kan aanpassen en daarna compileren en gebruiken. Dat geeft je de mogelijkheid om zelf bugs te verwijderen, zelf verbeteringen aan te brengen, of de software zelf verder te onderhouden als de oorspronkelijke maker daar geen zin meer in heeft.

De mogelijkheid tot het benutten van de code elders is inderdaad een eigenschap van open source, maar nu net niet een van de aller-belangrijkste eigenschappen.

Jij ontkent doodleuk de belangrijkste eigenschap van open source !

Absolute onzin. Je hoeft helemaal niets te kunnen wijzigen aan de originele broncode, dat is nog nooit een verplichting geweest bij open-source. De maintainer besluit zelf of ze pull requests aannemen, daar hebben minnende meelopers op Tweakers.net niets over te zeggen.

Open source betekent juist dat je zelf de software die je gebruikt kan compileren

Ja, dat zei ik al: anderen kunnen de code weer benutten. Je kan er een kopie van maken en daar alles mee doen mits je de licentievoorwaarden volgt.

Ik denk dat je mijn reactie verkeerd hebt geïnterpreteerd/mijn reactie misschien iets te 'kort maar krachtig' was. Maar het is simpelweg onwaar dat open-source vereist dat jij mag pushen naar mijn project als ik dat niet wil. Bij populaire online hosts zou je zelfs mijn account moeten bemachtigen om zoiets voor elkaar te krijgen.

Maar het is simpelweg onwaar dat open-source vereist dat jij mag pushen naar mijn project als ik dat niet wil

Dat klopt zondermeer. Maar daar ging het ook helemaal niet over. Zie onder.

Ik denk dat je mijn reactie verkeerd hebt geïnterpreteerd/mijn reactie misschien iets te 'kort maar krachtig' was.

Ik heb jouw reactie dan inderdaad anders geïnterpreteerd dan jij bedoelde. Ik ging er echter vanuit dat jij hetzelfde bedoelde als 84hannes op wie jij reageerde. En die had het duidelijk over het wijzigen van de broncode in de zin van het creëren van een nieuwe versie van de programmatekst, niet over het publiceren van zo'n nieuwe versie in een bepaalde repository. En dat zijn twee verschillende dingen. Originele broncode betekent niet 'originele repository'.

De betekenis van 'broncode' is: de programmatekst, die (meestal) de basis is van het programma in binaire vorm. Een repository daarentegen is een plaats waar de broncode (programmatekst dus) zich (toevallig) bevindt. Daar kunnen er meerdere van zijn, waarvan er wellicht één (of meer) door de gemeenschap als primaire locatie wordt gezien. Ik kan ook een eigen privé repository hebben. En daar kan de oorspronkelijke eigenaar/schrijver van de broncode dan weer niets in wijzigen zonder mijn toestemming. Als het gaat over het wijzigen van broncode, dan gaat het (dus) over het maken van een een nieuwe versie van de programmatekst, en dat staat volledig los van waar die bewaard wordt, en dus los van het al dan niet wijzigen van de toestand van een bepaalde repository.

Je hoeft helemaal niets te kunnen wijzigen aan de originele broncode

Je bedoelt dus dat het geen vereiste is dat je de originele repository kunt wijzigen. Dat klopt. Het is echter wel een vereiste dat je de originele broncode (= programmatekst die de basis was van de binaire versie die jij hebt gekregen) kunt wijzigen, en de gewijzigde versie kunt compileren en kunt publiceren (in je eigen repository!).

Wat belangrijk is, verschilt van mens tot mens. Voor jouw is dat het kunnen hercompileren maar voor een ander kan dat evengoed het hergebruik zijn. In geval van streaming media is er allesinds 1 argument dat niet opgaat en dat is het kunnen onderhouden nadat de originele aanbieder gestopt is daar je zonder die aanbieder toch geen content meer hebt.

Het kunnen aanpassen van de software en hercompileren is 1 element van open source software, maar zeker niet het enige.

Wat belangrijk is verschilt inderdaad van mens tot mens. Voor andere mensen is het misschien alleen belangrijk dat de software gratis is, en die malen niet om de broncode. Betekent dat dat open source dan ineens 'gratis' betekent, en dat de broncode er niet meer to doet ? Nee.

Het kunnen aanpassen en hercompileren is één element van open source, en inderdaad niet het enige, maar het is geen optioneel element. En dat is wél wat Blizz beweert. Als je de software niet zelf kunt compileren en dan gebruiken, al dan niet na hem zelf aangepast te hebben, of geaudit te hebben, dan is het geen open source. En dat is niet afhankelijk van wat voor een individu als jij of ik belangrijk is.

Als jij, net als blijkbaar Blizz, denkt dat dit niet zo is, dan raad ik je aan je eens in te lezen over dit onderwerp. (of in het engels).

Open source betekend niet perse gratis. Ben meerdere projecten tegen gekomen die volledig open source waren maar voor de gecompileerde code moest dan een klein bedrag betaald worden. Je kon kiezen gratis zelf compiled of een betaling doen als verkapte donatie.

als je geen aanpassingen mag doen is het geen open source.

https://opensource.org/osd

Het is een licentie. Om open source genoemd te worden moet het aan tien criteria voldoen.

Criterium 3 "Derived Works:The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software"

Voldoe je niet aan de voorwaarden dan mag je het geen open source noemen.
Persoonlijke voorkeur heeft er niets mee te maken.


-

Firefox verbiedt nu alle binaire plugins, behalve Flash. Dat is een tijdelijke actie, totdat Adobe met een alternatief komt vergelijkbaar met de Flash oplossing in Chrome.

Het gaat niet om het al dan niet binair zijn van plugins. Het gaat erom dat oude plugins, zoals Flash, hun eigen proces draaien. Het zijn feitelijk windows (of Linux, macOS) executables die een klein deeltje van je browserscherm gebruiken voor hun projecties. Wat ze daarnaast doen is onmogelijk te verifiëren en dus onveilig.

Dat klopt niet helemaal. Het verbiedt inderdaad alle "ouderwetse" NPAPI plugins, zoals Silverlight en Java (behalve Flash).

Deze DRM "content decryption modules" zijn ook een soort binaire plugins, maar ze kunnen een stuk minder dan de ouderwetse NPAPI plugins: enkel een gecodeerde stream op het beeld weergeven.

Kijk bijvoorbeeld maar eens in about:plugins in Firefox, dan staat daar ook "Widevine Content Decryption Module provided by Google Inc." bij.

Waarom niet? Flash werkt toch ook in FF?

Het gehele process wat gebruikt wordt voor flash is oud en zo lek als een mandje, apple heeft het vanaf begin af aan al niet toegelaten op iOS, maar steeds meer websites zijn aan het overstappen naar alternatieven zoals HTML 5.
Als je ergens dan niet meer op zit te wachten is het dat iemand dan nog even aankomt met het oude protocol.


Das hetzelfde als Versie 5 van een boek als lesmateriaal vereisen maar leeringen met Versie 3 de les in komen die een groot deel van de stof mist.

Zijn er nog steeds mensen die flash gebruiken ?

De vraag of oude technologie nog steeds gebruikt wordt is een beetje overbodig; natuurlijk wordt dat nog steeds gebruikt. Het kost geld om te vervangen en werkt (voorlopig) nog steeds.

Dat Flash een reputatie heeft als een gevaarlijk stuk software wil niet zeggen dat programma's die erin geschreven zijn niet nuttig zijn voor de mensen/bedrijven die ze gebruiken.

Het klopt dat Flash een gevaarlijke reputatie heeft (en terecht!), maar er zijn inderdaad zoals je zegt nog veel tools die geschreven zijn in Flash waarvoor het weinig zin heeft deze te vervangen.

Als je in deze tijden nog nieuwe flash-applicaties ontwikkelt, verdien je echter gestenigd te worden. Er zijn geen geldige argumenten meer voor Flash te vinden, zowel ontwikkeling als support voor gewone webapplicaties is tegenwoordig veel gemakkelijker en beter.

Op het "consumenten" internet is het misschien een stuk minder geworden (alhoewel het volgens mij voor van die spelletjes sites voor kinderen het nog vaak gebruikt wordt).

Maar in de zakelijke wereld wordt het nog volop gebruikt. Denk aan Intranetten met grafiekjes en dingen of bepaalde beheer tools... Vervangen kost geld, zeker ook omdat veel bedrijven met software zitten die niet zomaar even van een update te voorzien is. Vaak komt het neer op een complete vervanging van een systeem. Dus kiezen ze ervoor, zolang het nog werkt om het te blijven gebruiken.

Ja, vast. Ik heb al ongeveer een jaar geen Flash geïnstalleerd en heb er zelden problemen mee (de 'betere' sites ondersteunen nu gewoon netjes html5 video, de rest heeft gewoon pech).

Vanaf Firefox 57 gaat Flash sowieso niet meer werken (want alleen WebExtension add-ons worden dan nog ondersteund). Dus deïnstalleer het nu maar gewoon, over een paar maanden tot een half jaar kun je het toch niet meer gebruiken.

Tenzij je de ESR blijft gebruiken

users running the Firefox Extended Support Release (ESR) will be able to continue using Flash through the final end-of-life at the end of 2020.

Dat is een beetje overtrokken denk ik. Zeker ook omdat ik denk dat je het "wat .. van plan is" zelf ook niet in een lijstje hebt zien staan maar doortrekt op basis van wat ze de laatste tijd toegevoegd hebben. Anders zie ik graag een lijstje van toekomstige bezwaarlijke (privacy-technische) features.

Ik ben ook niet blij met een aantal recente features. Maar voor mij vallen ze nog mee (met een paar instellingen). En juist zo kan ik bijhouden en commentaar geven op wat ze telkens weer bekokstoven.

Hoe zit het dan met netflix? Die vertrouwt toch ook op DRM om zijn content weer te geven, wat de browser moet ondersteunen. Of gebruikt gaat spotify over op een fallback in flash wanneer je safari gebruikt?

Netflix ondersteunt verschillende CDM's (Content Decryption Modules). Voor zover ik weet ondersteunen ze in ieder geval Widevine (chrome/firefox/android), PlayReady (IE/Edge/chromecast/verschillende settop boxes en smart TV's/playstation/xbox) en Fairplay (Safari/iOS).

Het zou een hoop helpen als er een open standaard komt, maar dat is om verschillende technische redenen vrij ingewikkeld. (Niet onmogelijk overigens)

Het zou kunnen dat Spotify tot voor kort in Safari flash oid heeft gebruikt, maar aangezien Flash in de toekomst wordt uitgefaseerd, snap ik dat ze daar van afstappen. Ik vermoed dat het uiteindelijk wel de moeite waard is voor ze om fairplay te implementeren, tenzij ze hier andere bezwaren dan alleen kosten voor implementatie voor hebben.

Het zou een hoop helpen als er een open standaard komt, maar dat is om verschillende technische redenen vrij ingewikkeld. (Niet onmogelijk overigens)

Die is er vanaf de browser kant. Dat is de mogelijkheid om content decryption modules te gebruiken i.c.m. web video. Er is een officiële W3C specificatie voor usw.

Het probleem ligt - zoals altijd, eigenlijk - bij de content-providers die hun media moeten aanbieden in verschillende smaakjes; één voor elke CDM. En dat is een onoverkomelijk iets. Om een stream door een decryptie-module af te laten handelen, zal deze ook speciaal voor dat type module ge-encrypt moeten zijn.

Vraag is in hoeverre je dat kunt standardiseren zonder dat elke vorm van DRM eigenlijk op hetzelfde neer gaat komen. Wss. is het beste wat je kunt doen een complementaire standaard voor Content Encryption Modules verzinnen.

[Reactie gewijzigd door R4gnax op 11 september 2017 20:33]

Wat voor Safari geldt, is ook zo voor SeaMonkey (een Mozilla fork) ongeveer sinds de nieuwe webplayer is Widevine vereist en die is er niet voor SeaMonkey.

Ik kreeg in de vakantie ook een mail dat ze mijn drie (!!) Pioneer speakers ook niet meer ondersteunen. Daarnaast kreeg ik een paar weken geleden op alle smart-tv's de melding dat de Spotify app verwijderd was..

Goed bezig Spotify!

Spotify is niet degene die speakers of tvs ondersteund. Spotify biedt een platform waarvan speaker- en tv makers gebruik kunnen maken. Dat kan ook niet anders. Spotify kan geen duizenden verschillende apparaten gaan ondersteunen.

Pioneer heeft besloten niet mee te gaan met Spotify, net als de makers van je smart-TVs. Dat is geen keuze van spotify maar van de fabrikanten.

Zie hier ook meteen de reden om helemaal weg te blijven van dit soort apps op je apparaten. Beperk die apparaten gewoon lekker tot hun kernfunctionaliteit; het tonen van beeld en het hoorbaar maken van geluid. Welk beeld of geluid dat zou moeten zijn wil je veel liever laten bepalen door apparaten die dáár dan weer goed in zijn zoals een dedicated mediaspeler of een vergelijkbaar iets.

Ik heb nog nooit een app gehad die plots niet meer door mijn HTPC ondersteund werd.....

Ik kreeg de mail niet van Pioneer, maar van Spotify zelf die de ondersteuning voor apparaten schrapt "om me in de toekomst beter van dienst te kunnen zijn"(...).

Mijns inziens heeft dit niets met Pioneer zelf te maken maar met Spotify die mij, als betalende abonnee, benadeelt door een stuk uit de software te snijden. Samsung doet het wel bewust door mij een TV te verkopen met allerlei kreten en apps op de doos om deze vervolgens in zogenaamde "updates" stilletjes te verwijderen.

Dat je als fabrikant geen updates meer uitbrengt is prima. Maar ga geen functionaliteit van het apparaat schrappen..

Stel je voor dat je een nieuwe Opel koopt en bij de eerste beurt halen ze je navigatie systeem of radio eruit omdat deze niet meer ondersteund gaat worden.

De waarheid ligt waarschijnlijk zoals gewoonlijk weer in het midden. Ik heb geen direct inzicht in wat er precies gebeurd is, maar ik vermoed dat Spotify een overstap heeft gemaakt naar een ander DRM systeem. Specifiek een andere CDM (content decryption module). Ze zullen daarmee de oude CDM willen uitfaseren en hebben hoogstwaarschijnlijk hun partners (oa Pioneer) hierover geinformeerd.
Pioneer staat dan voor de keuze om een update voor hun devices te bouwen om de nieuwe CDM te ondersteunen. En in dit geval hebben zij er vermoedelijk voor gekozen om geen uitgebreide software updates meer aan te bieden. Omdat Spotify je ten minste even wil informeren over de impact hebben zij vervolgens de mail verstuurd.

Ik weet persoonlijk niet helemaal wie ik daar de schuld van zou geven. Beide partijen hebben er in ieder geval niet alles aan gedaan om het werkend te houden.

Mij tip zou zijn om een chromecast audio aan te schaffen. Das lekker portable en kun je uiteindelijk op elk type speaker aansluiten, mits het een 3.5mm jack of optische ingang heeft. Hiermee zou je zelfs een bestaande hifi installatie slim kunnen maken en het kost vrij weinig.

Dit, ik heb een smart TV gekocht een paar maanden terug. Blijkbaar al wat ouder model, wist ik veel, wordt nu al doodgegooid met meldingen over apps die dadelijk niet meer ondersteund worden.
Nou heb ik dat ding gekocht om als beeldbuis te dienen en boeit dat hele smart verhaal me geen drol maar als je de verwachting had al die smart shit te gaan gebruiken ben je redelijk in de aap gelogeerd.

[Reactie gewijzigd door Koffiebarbaar op 11 september 2017 13:11]

Inderdaad, dan is zo'n Chromecast toch een fijner alternatief.
Sinds ik zo'n ding heb van 3 tientjes, gebruik ik geen enkele TV app meer: die zijn veel te traag en omslachtig te bedienen.

Ik gebruik daar mijn playstation voor maar dat is verder zelfde laken een pak inderdaad. Al die fragmentatie in TV land zorgt alleen maar voor verplinterde support tot dusver. Ronduit waardeloos eigenlijk want zo zit je toch nog met extra apparaten onder je smart TV terwijl het elegante er nou net aan moet zijn dat je alleen nog maar zo'n beeldpaneel hebt.

Klopt, het digitale tijdperk maakt dit soort zaken best ellendig eigenlijk. Vergelijk het maar eens met de DAB autoradio's die met het invoeren van DAB+ ineens waardeloos zijn. Terwijl oldschool FM nog steeds overal op werkt (vooralsnog). Ik heb de afgelopen jaren met stijgende verontwaardiging gelezen hoe TV fabrikanten steeds sneller hun TV platforms verlieten en dat apps maar zelden lekker werken.

Een voordeel van een apparaat als een Chromecast is dan wel dat je "maar" 30 euro weggooit, in plaats van een complete TV, en dat hij nog redelijk netjes is weg te werken. Maar het blijft een keuze uit twee kwaden.

Gewoon ff een vraagje tussendoor, maar is het nu zo dat Google die Chromecast op de markt heeft gebracht om mijn bwoserhistory te verzamelen? Wordt alles wat ik bekijk via die Chromecast doorgestuurd nar Google?

Sowieso niet meer dan de standaard apps op de smart-TV dan wel smartphone is mijn perceptie. In de settings kun je wel dingen uitzetten mbt data collectie.

Op het moment dat je op het cast-icoontje klikt op je foon of ipad, dan stuurt hij de url van de stream volgens mij direct naar de chromecast: het apparaat moet namelijk op hetzelfde netwerk zitten.

Ik denk dat het vooral de diensten zelf zijn die data collecteren (zoals een Spotify). Ik vond deze link, geen idee of het nog klopt:
http://thewirecutter.com/...vices-and-you/#chromecast

Alleen jammer dat een groot deel van de hedendaagse TV's met 'smart apps' worden meegeleverd . . .

Ik ben erg blij dat ik vorig jaar voor de slaapkamer een 40" "stupid" TV heb kunnen kopen. Met alle voordelen van dien: Sneller opstarten, lager verbruik, sneller van kanaal wisselen.....

Helaas schijt dat in alles groter dan 40" tegenwoordig onmogelijk te zijn

https://myhumax.info/humax-pure-vision-display/

Thank me later!

Ps: voor degene die niet het verhaaltje erbij willen lezen. Dit zijn 4k tv modellen tot 49" die "dom" zijn. Dus geen advertenties en andere smart tv anticonsumenten bullshit

[Reactie gewijzigd door mikesmit op 11 september 2017 14:32]

Win! Deze gaat na de afknapper van mijn Sony op de verlanglijst.

Ik ben blij dat ik eens echt een keer de community kan helpen!

Kijk, goed plan.

Nu nog een OLED 65" en ik neem hem.

Dan wil ik graag weten welke TV dat is en waar je 'm gekocht hebt. Hier in Alkmaar zie ik alleen maar van de hele kleintjes die dat niet hebben. Alles groter dan 80cm is hier 'smart' . . .

Er worden m.i. gewoon geen nieuwe TV's meer gemaakt die niet tot een zekere mate smart functionaliteiten hebben m.u.v. misschien schermen voor zakelijk gebruik zoals infoboards die je als jan doorsnee niet zomaar even kan kopen. Zeker niet bij de usual suspects.

Heeft allicht met geld van doen. Lees al verhalen over een Philips die dadelijk gewoon advertenties gaan serveren naar je smart ellende.

[Reactie gewijzigd door Koffiebarbaar op 11 september 2017 13:51]

Zie mijn reactie op Croga

Je kan misschien geen stupid TV's krijgen, maar je kan wel een HEEL groot scherm halen waar je bijv. een Horizon box aan doet (toch HDMI) en dan heb je nog een "dommere" TV dan wat jij nu hebt
Hier ga ik overigens ook voor bij mijn volgende TV, al zal dat nog lang niet zijn omdat ik zo'n 55" 4K LG TV heb x)

[Reactie gewijzigd door thomas1907 op 11 september 2017 14:51]

Als ik één ding niet zie zitten is een onzinnige extra box van de provider. Daar is de CI+ module voor. Ja, dat vereist weer een Smart-TV. Maar laat mij maar lekker gewoon de afstandsbediening van de TV gebruiken.

Of je gebruikt de prima AB van de 4K receiver van KPN glas.

Een power knop voor de tv box en een power knop voor tv en receiver. Geluid van tv staat uit en volume knop op de AB bedient gewoon de receiver.

Dit is zeker niet altijd waar, Netflix en Spotify halen ook zelf eerder gecertificeerde apparatuur uit de lijst met apparaten die ze ondersteunen omdat bijv. nieuwere DRM technieken niet werken op deze apparaten en ze de ondersteuning voor de oudere technieken opheffen.

Het is zeker zo dat (vooral) smartTV fabrikanten ook functionaliteit schrappen, maar content providers als Netflix en Spotifly doen dit zelf ook.

Ik zie dat anders...

Spotify en Netflix evolueren hun software. Dat moeten ze. Zeker als het over beveiligings technieken gaat.
De verantwoordelijkheid voor de app op het smartdevice ligt bij de fabrikant. Die weigert het apparaat te updaten om de evoluerende software te ondersteunen.

Spotify en Netflix halen apparatuur uit de lijst omdat ze geen keus hebben. Ze moeten evolueren en de fabrikant weigert mee te evolueren. Dan ga je uit de lijst. Maar de verantwoordelijkheid daarvan ligt daarmee nogsteeds niet bij Spotify of Netflix. Die ligt nogsteeds bij de fabrikant. App-makers reageren slechts op wat die fabrikant (niet) doet.

En zeg nou niet dat de fabrikanten die functionaliteit niet kunnen toevoegen. De apparaten werken allemaal met een updatebare firmware en hangen allemaal aan het internet (anders zouden ze ook geen spotify of netflix kunnen gebruiken). Ze kunnen dus zonder moeite een nieuwe firmware maken die de nieuwe technologiën wel ondersteund.

De gebruiker verwijst naar een uitlegpagina om de Spotify Web Player werkend te krijgen bij problemen, waar gesproken wordt over een Widevine-plug-in. De Widevine Media Optimizer is een tool die door Google is ontworpen voor de decryptie van mediastreams

[OT]
Kon het bijna niet geloven!
Een binary (lees platform afhankelijke) plugins in een webbrowser?

Wat lees ik op de Widevine (eigendom van Google) website:

"At this time there is no plugin available for Linux, Chrome or Opera."

Staan we op het punt om Flash en Silverlight voor content distributie te begraven komt Google met Widevine.

[Reactie gewijzigd door Carbon op 11 september 2017 13:24]

Wat voor keuze hebben ze? Ik denk niet dat google zoveel cash stopt in opensource codecs omdat ze zo graag DRM in hun browser willen.

Het is gewoon weer hetzelfde verhaal met de content industrie die loopt te janken over illegale content en eisen stelt aan de distributie platformen.

Hier specifiek van spotify vind ik nog niet zo erg, maar dat het nu ook over displayport/hdmi gaat gebeuren met een speciaal chippie in je beeldscherm gaat me echt te ver. Niet te stoppen weer natuurlijk..

Wat voor keuze hebben ze? Ik denk niet dat google zoveel cash stopt in opensource codecs omdat ze zo graag DRM in hun browser willen.

De HTML5 DRM "standaard" pushen?

En welke standaard is dat juist? Welke html5 compatibele feature gebruik ik als ik wil verzekeren dat mijn digitale media niet verspreid kan worden buiten wat ik zelf stream naar de rechthebbenden?

[Reactie gewijzigd door boe2 op 11 september 2017 14:24]

Over many objections, W3C approves DRM for HTML5

Hrmm, heb je hem wel gelezen?

EME is not itself a DRM system. Rather, it is a specification that allows JavaScript applications to interact with DRM modules to handle things like encryption keys and decrypting the protected data. Microsoft, Google, and Adobe all have DRM modules that comply with the spec.

De modules van Google, Microsoft en Adobe zijn respectievelijk Widevine, PlayReady en Primetime. Klinkt bekend? Dit is juist waarom de W3C approved standaard zo controversieel is. De interface is een open standaard, maar heeft per definitie proprietary modules van derden nodig om te functioneren.

De interface is een open standaard, maar heeft per definitie proprietary modules van derden nodig om te functioneren.

Helemaal niet. Het staat jou vrij om je eigen EME-compatible module te schrijven en publiceren onder een open source licentie.

Alleen zul je tegen het adoptie-probleem aan gaan lopen: de content industrie zal haar media streams ook aan moeten bieden in een vorm die met jouw module kan werken. En daar zullen ze niet genegen toe zijn in het geval van een opensource oplossing, waar een te reeël risico bestaat dat iemand een aangepaste versie zal maken die in essentie de DRM zou gaan bypassen.

Hoogstwaarschijnlijk heeft dat meer met technische problemen te maken dan met de roadmap van het bedrijf. Ik zou ook liever een HTML5 standaard zien dan een domme plugin.

Chrome zal het ingebouwd hebben. Linux... tja. Best wel foei van Google, maar ze ondersteunen desktop Linux al niet zo best. Google Drive en co. Opera? Mijn huidige standaard browser. Jammer.

Ondersteunde platformen Google Widevine

Windows Vista en hoger
Mac OS X 10.9 en hoger
x86 en x64 Linux

bron

Probeer het maar eens te installeren op een op een linux systeem met ARM CPU
Wordt dus niet ondersteund!
Binary only extensions hebben niets te zoeken in een webbrowser voor publiek gebruik.

Dat zei je niet in je originele post maar whatever. Je zou je af moeten vragen wie bedacht heeft dat er überhaupt een DRM module moet komen in plaats van een willekeurig bedrijf te eisen dat het ook op je broodrooster werkt.

Op zich niet zo heel raar, gezien Safari een beetje de nieuwe IE aan het worden is wbt webcompatibiliteit.

WebKit (de engine van Safari) zit toch ook gewoon in Chrome (tegenwoordig weliswaar geforked en bekend als Blink)? Zit daar zo veel verschil in?

Er zit vrij veel tijd tussen iets wat in Webkit zit en wat vervolgens in Safari wordt toegevoegd. Bovendien is Apple erg selectief met wat ze wel toestaan, waardoor we nu een punt bereikt hebben waarop je applicaties van hacks moet gaan voorzien om hem werkbaar te maken op Safari omdat ondersteuning uitblijft of waarschijnlijk nooit zal komen. Ze doen dit om hun apps te blijven pushen, want zo kunnen ze er nog veel aan verdienen. Voor Google maakt dat weinig uit, dus die blijven gewoon lekker bouwen aan het web.

Bovendien zit je op iOS vast aan de Safari Webkit engine en dat leidt ertoe dat je dus ook geen alternatieven kunt aanbevelen aan gebruikers. Stel functionaliteit X werkt momenteel niet meer, dan houdt het daar op voor iOS gebruikers (bijvoorbeeld als er een nieuwe update van het OS is)

Edit: ook nog vergeten te vertellen dat er nog verschil zit tussen de Safari voor websites en die voor hybrid apps. Als je een Cordova app maakt, heb je met een andere engine te maken. Sterker: als je een website aan je homescreen vastmaakt, krijg je met de andere engine te maken. Daarom hadden wij een probleem met SVG sprites die wel in normale Safari werken, maar niet als je hem pinned. Erg handig (not)

[Reactie gewijzigd door Martinspire op 11 september 2017 16:00]

Kan je een betrouwbare bron geven waarop staat dat:
- Google dit doet
- Apple dit niet doet?

Google verkoopt bv je browser geschiedenis en wat je op websites doet aan de hoogste bieder en de Amerikaanse overheid.

Nee, dat doen ze niet. Dat zou hun eigen advertentie-onderdeel benadelen. Google gebruikt de gegevens om advertenties van de hoogste bieder op de juiste plaats te laten zien.
Het verdienmodel van Google is advertenties, niet gegevens.

Detail: Google verkoopt jouw data niet door, ze gebruiken jouw data zelf om middels hun eigen ontwikkelde algoritmes targetted advertenties te verkopen. Google weet alles van jou, maar geen enkele klant van Google krijgt dat te zien.

Als Google hun data zou verkopen, raken ze hun business model kwijt.

Dit is een groot en wezenlijk verschil met dataminers die geen business model hebben en wel tegen de hoogste bieder hun databasejes verkopen. Dan gaan jouw gegevens het internet over.

https://privacy.google.com/your-data.html

[Reactie gewijzigd door InflatableMouse op 11 september 2017 13:19]

"Google verkoopt bv je browser geschiedenis en wat je op websites doet aan de hoogste bieder"

De hoogste bieder is zichzelf, want ze hebben zelf het meeste baat bij zelf alle kennis in handen hebben. Anders gaan de mensen die die gegevens opkopen zelf ook analyse daarop uitvoeren. Het enige wat Google verkoopt, zijn de resultaten van hun eigen analyse. Of je dit wel of niet fijn vind, laat ik in het midden, maar data is Google's belangrijkste bedrijfsgeheim. Google bewaart het misschien wel beter dan sommige overheden.

"en de Amerikaanse overheid."

Ook niet. Google wordt hiertoe, met veel horten en stoten, toe gedwongen. Als het bekend wordt dat Google vrijwillig data afgeeft aan overheidsspionage kunnen ze wel inpakken. Bovendien is het ook een nieuw platform om aan te vallen, dus meer vatbaarheid om opeens je belangrijkste bedrijfsgeheimen kwijt te raken. Google zal nooit vrijwillig data opgeven.

Zover ik weet is dit niet waar, wel steeds mensen die het roepen, maar ik kan nergens vinden dat ze die gegevens door verkopen (is namelijk hun core business die gegevens weten en gebruiken voor AdSense), zou je een linkje kunnen geven waar dit geverifieerd wordt?

Edit, spuit 11

[Reactie gewijzigd door bskibinski op 11 september 2017 14:51]

Toch wel. Zo doet mijn HSBC account het prima in Chrome, maar in Safari werken sommige functies niet. (Waaronder de nogal belangrijke Confirm knop bij het doen van een betaling.)

Waar de schuld ligt weet ik niet, maar het geeft in elk geval aan dat er wel verschillen zijn.

In principe is er met Safari niet direct iets mis als je een website ontwikkelt, echter als je PWA's ontwikkelt is Safari ondersteunen gewoon een stuk moeilijker dan Chrome en FF.

Een confirm knop die niet werkt zal dan dus waarschijnlijk de schuld van de ontwikkelaar zijn en niet zozeer van de browser.

In principe is er met Safari niet direct iets mis als je een website ontwikkelt

Apple heeft er enorm een handje van om regressies in de meest basale zaken te introduceren en deze vervolgens vrolijk 2 major releases onopgelost te laten om zich in totaliteit te focusen op hun nieuwe visuele tierelantijntje dat enkel en alleen onder Safari zal bestaan en dus praktisch nooit op websites ingezet zal worden.

Ook als je 'gewoon' websites bouwt krijg je met dit soort ge-eikel te maken. Zo heeft Safari in iOS 8 een bug gehad die auto-magisch een length property bij tovert op objecten die enkel numerieke properties bevatten. Deze is tot aan iOS 9 niet gefixed en heeft zijn potentieel om bugs te realiseren met verpletterende effectiviteit gerealiseerd.

Zo ongeveer elke array-iteratie functie in zo ongeveer elke library viel hier aan ten prooi. Zie o.a. het hieraan gerelateerde issue bij jQuery.

[Reactie gewijzigd door R4gnax op 11 september 2017 20:12]

ik denk dat het hard al is gegaan

Want volgens mij is heel veel ontwikkel power van webkit dus weg gegaan naar blink/chromium

En daar zijn ze nu al een tijdje mee bezig, zou best wel eens al flink bij elkaar weg gelopen kunnen zijn

Je zegt het zelf al, WebKit en Blink zijn niet hetzelfde. Blink stamt alleen af van WebKit.

De versie van WebKit in safari loopt altijd behoorlijk achter, bovendien steekt google behoorlijk wat energie in het ontwikkelen van Blink.

Het probleem is daarbij dat Blink inderdaad een fork is van WebKit, waarbij Google en Safari dus voor een eigen implementatie van bepaalde zaken kiezen. De basis is dus op veel plekken hetzelfde, maar de functionaliteit wordt per vendor zelf bepaald. Google en Apple zien daarin hun eigen "versie" van hoe iets moet worden opgebouwd, waardoor de browserondersteuning en veiligheid dus sterk kunnen afwijken.

"beetje" is een understatement.
Ik snap wel dat het gratis bij iOS meekomt... je kan hier toch werkelijk geen geld voor vragen.
Meest onmogelijke browser. IE had tenminste nog zijn "conditional comments".

Wat is er precies eigenwijs aan Google?
Chrome is samen met Firefox veruit de meest html5-compatible browser.
Persoonlijk snap ik ook niet waarom iemand Safari zou prefereren boven één van deze twee (geldt nog meer voor IE natuurlijk).

Opera werkt op 3 punten even goed als Chrome op het gebied van de HTML5 test: https://html5test.com

Firefox 475 (versus 523 Opera en 526 Chrome), Safari maar 409

[Reactie gewijzigd door Vhond op 11 september 2017 13:13]

Opera 47 komt nu op 526, Edge komt bij mij op 473...

Het aantal punten is natuurlijk niet het belangrijkste. Sommige dingen willen de browsers ook niet ondersteunen. Jammer dat html5test.com daar geen verschil in maakt.

[Reactie gewijzigd door cruysen op 11 september 2017 14:30]

Noemenswaardig is dat Safari 11 op Sierra al een aardige inhaalslag heeft gemaakt, namelijk: 455. Safari Technology Preview op Sierra scoort inmiddels 469.

Noemenswaardig is dat Safari 11 op Sierra al een aardige inhaalslag heeft gemaakt, namelijk: 455. Safari Technology Preview op Sierra scoort inmiddels 469.

Noemenswaardig is ook dat Apple er een handje van heeft om, wanneer ze een nieuwe versie van Safari uitbrengen, de meest stomme regressies te introduceren die de meest basale features om zeep helpen en vervolgens patches hiervoor niet verwerken in een hotfix, maar gebruikers gestrand laten zitten tot een nieuwe major versie.

Hoe basaal? Nou; de array length bug in iOS Safari 8.x was een leuke. Google maar eens!

Een andere leuke was het feit dat in Safari 6.1 -- ik dacht tenminste dat het 6.1 was; al weer een hele tijd geleden... -- een pre-increment operatie zoals ++i door de optimizing JS compiler zonder verdere controle omgezet werd in i++, ook op plekken waar dat een effect op de betekenis van de code zou hebben.

Nu in iOS Safari 10 hebben ze weer een nieuwe leuke regressie in flexbox layout, waardoor de bijhorende align-items instelling niets doet als je deze toepast met een <button> element als de display:flex container. Stom genoeg - en gelukkig - werkt de align-self nog wel op de inidividuele flex items binnen een ge-flext <button> element. Hopelijk gaan we die nog gefixed zien voor Safari 11, maar Apple kennende wordt dat iets voor Safari 15 of 16 of zo...

[Reactie gewijzigd door R4gnax op 11 september 2017 19:58]

Omdat je op de mac niets beter hebt?

Chrome is een resource hog die gewoon veel te veel batterij draint, Firefox heb ik eens geprobeerd en was trager als safari maar is wel even geleden dus dit kan verholpen zijn

Ik deel je ervaring absoluut niet, gebruik al jaren zowel Chrome als Firefox op macOS. Werkt allebei uitstekend. En die ervaring deelt eigenlijk iedereen in mijn omgeving die ook op macOS werkt. Dus dat je "op de Mac niets beters hebt" klopt echt niet.

Waarom? Chrome loopt vaak voor wat betreft ondersteuning van de nieuwste APIs e.d.

Je bedoelt dat ze hun eigen uitbreidingen op API's door willen drukken en het in de standaarden proberen te krijgen door hun grote marktaandeel... (net als IE dus, die z'n eigen versie van HTML op probeerde te dringen)

Google heeft gewoon zin om te wachten op de trage ontwikkelingen binnen de markt. Heel goed te begrijpen en ik ben blij dat ze wat sneller gaan dan de rest.

Dus jij bent blij dat Google van het web hun eigendom probeert te maken via het doordrukken van allerlei niet-standaard API's die alleen werken in hun eigen browser? Ik heb liever een wat langzamere ontwikkeling, zolang het web maar open blijft.

Kun je hier concrete voorbeelden bij benoemen?

Natuurlijk implementeert Chrome functionaliteit voordat de standaard gereed is. Dat doet elke browser. Sterker nog, het is deel van het W3C proces: een specificatie kan de _candidate recommendation_ fase pas verlaten zodra er meerdere implementaties zijn.

Het ontwikkelen van functionaliteit op basis van theorie is een vergissing, iets wat zeker op het Web niet moet gebeuren gezien het brede bereik van het platform. Op het moment dat een functie vrijgegeven wordt kan het bijna niet meer teruggenomen worden, dus praktische ervaring en iteratie met kleine percentages van de gebruikers zijn cruciaal.

Niemand is gebaat bij langzame ontwikkelingen. Dat zorgt voor veel meer 'schade' dan die paar standaarden waarvan afgeweken wordt.
Google houdt 't web prima open. Als ik een site ontwikkel, dan moet deze in alle browsers werken, ook Firefox, en gebruik ik helemaal geen onderdelen van Chrome die nog niet binnen een standaard zitten. De features die Chrome als extra biedt zijn meestal heel specifiek voor hun eigen services.
Als web developer vind ik dit ook helemaal geen kwalijke ontwikkeling, in tegenstelling tot het IE debacle. Internet Explorer ontwikkelde niet door, was onwijs buggy en probeerde shortcuts te nemen door gedrochten te ondersteunen als ActiveX. Je kan haast zeggen dat er plugins als Flash zijn ontstaan omdat ze met hun eigen ontwikkeling te veel achterlagen en externe partijen het gat gingen vullen.
Google pakt dat heel anders aan. Die liggen juist voor, willen door, en forceren niemand om hun weg te volgen. Als er een partij is die weet wat ze aan het doen zijn op dit gebied, dan zijn zij het wel.

En het voordeel daarvan is? dat developers functionaliteiten gaan gebruiken die helemaal geen standaard zijn en alleen werken in Chrome? dan moet je niet zeer hypocriet een vingertje gaan wijzen naar Microsoft met IE indertijd.
We willen juist naar een echte standaard toe die overall werkt en daar past niet in dat google met chrome maar weer een beetje doet waar ze zelf zin in hebben. Je ziet het nu al steeds vaker dat developers te lui zijn om hun sites op andere browsers ook maar een beetje te testen, ach het werkt in hun favoriete browser dus waarom zouden ze nog fatsoenlijk testen op browsers die zich wel netjes aan de "HTML5" standaard houden.

Noem 1 developer die alleen voor Chrome ontwikkelt, en noem 1 website die het alleen in Chrome doet.
Mocht je zo een website vinden, dan is die waarschijnlijk dusdanig high-tech dat het juist vet is dat zoiets kan in Chrome. Zelfs Google Maps met 3D en streetview en allerlei complexe technieken werkt gewoon in alle browsers. Je ziet echt spoken die er niet zijn.
Chrome doet dit al jaren, en tot nu toe is er geen enkel probleem ontstaan. Mensen vergelijken het te veel met IE, maar we zitten in een hele andere situatie.

Sites werken regelmatig niet fatsoenlijk op andere browsers omdat de ontwikkelaars alleen op chrome getest hebben. Ja het wordt wel getoond, maar bepaalde opties werken gewoon niet of maar deels, of worden verkeerd weergegeven.
Ik zie geen spoken, want ik loop er bijna wel dagelijks tegenaan in zowel Edge (thuis) als IE11 (werk).
Ja juist, chrome doet dit al jaren en het leidt regelmatig juist tot problemen, en meldt je die problemen dan krijg je 9 van de 10 keer het antwoord, "gebruik maar chrome, want daar werkt het wel". En het is juist hypocriet om altijd dan MS met zn oudere IE aan te halen als Chrome nu exact hetzelfde doet, alleen geniet Chrome nu de voorkeur van een hoop devs, en daarmee vinden ze het dan ook helemaal geen probleem.
Zo laconiek als jij reageert doet mij vermoeden dat jij waarschijnlijk voornamelijk dus chrome gebruikt.

Het maakt niet uit wat ik gebruik, het gaat erom dat wat ik bouw werkt bij al onze bezoekers. Wij hebben te maken met miljoenen pageviews per dag en ondersteunen vrijwel alles waarvan er meer dan ~1% in gebruik is.
Ik gebruik zelf Chrome omdat het in het gebruik in elk opzicht prettiger is dan Microsoft browsers (en omdat we geen Windows gebruiken). Daarnaast fervent gebruiker van zowel Firefox als Vivaldi.
Geef eens wat voorbeelden van sites die het alleen goed doen in Chrome omdat ze 'te nieuwe' technieken gebruiken. Ik ken er serieus geen een, maar ben wel heel benieuwd welke technieken deze sites dan zouden gebruiken.

De reden dat Chrome aangeraden wordt aan mensen is omdat

• video's het altijd doen, dat komt door brede ondersteuning voor formaten binnen html5, en flash zit ingebakken.
• de browser op vrijwel elk systeem gewoon lekker vlot werkt en je geen last hebt van rare traagheid of andere problemen.
• de render engine verreweg het verst is doorontwikkeld waardoor standards compliant websites het altijd doen zoals bedoeld en geen rare quirks te zien zijn.
• de browser kwa veiligheid door vele updates en actieve bugfixprogramma's over het algemeen toch wel voorop loopt.

De reden dat een site het in de laatste Firefox of de laatste Edge niet goed doet heb ik werkelijk al jaren niet meer gehoord.

Dat zei MS ook met ActiveX

Issue is wel dat je daarmee de kans loopt gedrochten te creëren als de IE6 situatie in het verleden op de lange termijn waarbij je gewoon IE6 geïnstalleerd moest hebben staan omdat anders bepaalde webapplicaties gewoon weg niet werkten.

Gelukkig gaat het momenteel steeds vaker om kleinere features. Daar waar ze aan het begin van HTML5 aardig wat grote zaken hebben doorgedrukt inderdaad. Maar we hebben nog een paar hordes voor we er helemaal vanaf zijn. Vooral op het gebied van media en protocols (http2 bv) gaan we nog wel wat krijgen, maar de vraag vanuit de branche is daarbij kleiner. Veel CSS features waren erdoor gedrukt, al zijn ze met Flexbox of pointerevents wel weer uitgekomen op een andere standaard.

Google werkt zelf veel (mee) aan webstandaarden, dat is iets anders dan louter eigen technieken gebruiken.

Als het w3c het ermee eens is, is het toch juist mooi dat er initiatief vanuit google komt?

Kun je een voorbeeld noemen van wat jij eigenwijs vindt?

[Reactie gewijzigd door twicejr op 11 september 2017 12:43]

Louter eigen standaarden er door drukken? Zoals het proprietaire CSS alvast in Internet Explorer 3 zat? Zo simpel zit het leven niet in elkaar. Microsoft heeft heel veel standaarden er op de zelfde manier door gedrukt (XMLHttpRequest waar AJAX en dus het moderne web op gebaseerd is bijvoorbeeld).

Chrome is nu groot genoeg om standaarden er door te drukken terwijl ze nog op de tekentafel liggen. Op het moment dat anderen ze gaan implementeren dan is het opeens van "tja wij hebben het al zo gedaan en 12 miljoen pagina's hebben dat al op die manier gebruikt...".

Chrome is nu groot genoeg om standaarden er door te drukken terwijl ze nog op de tekentafel liggen. Op het moment dat anderen ze gaan implementeren dan is het opeens van "tja wij hebben het al zo gedaan en 12 miljoen pagina's hebben dat al op die manier gebruikt...".

Zet je alu-hoedje maar af. Google probeerr echt niet om de rest van het W3C om te krijgen via dat soort strong-arm taktieken.

Google is zelf een initiatief begonnen om het soort experimentele features waar jij het over hebt, in Chrome niet langer standaard publiekelijk aan te bieden onder zgn. vendor-prefixed properties. In plaats daarvan worden ze enkel beschikbaar gesteld achter runtime flags die standaard uit staan en die gebruikers enkel individueel aan kunnen zetten via het verborgen chrome://flags opties scherm. Zo hou je ze weg bij het grote publiek, maar geef je ontwikkelaars toch de mogelijkheid om met implementaties van specifacties die in draft fase verkeren, te spelen en vervolgens via de Web Platform Incubator Community Group (WICG) feedback op die specificaties in wording te geven.

Mozilla heeft deze strategie overigens voor bepaalde high-impact features ook omarmd.

[Reactie gewijzigd door R4gnax op 11 september 2017 19:46]

"Als het w3c het ermee eens is, is het toch juist mooi dat er initiatief vanuit google komt?"

Op zich wel, ware het niet dat het W3C gedomineerd wordt door Google. Kijk naar de meetups en de github repos, het is ongeveer 2/3e Google. Laatst was er een belangrijke bijeenkomst in Azie.12 afgezanten van Google maar liefst, terwijl andere "grote" spelers op 1 of zelfs 0 bleven steken.

Het is niet zo zat ze niet aan open standaarden werken, dat doen ze zeker. Maar Google bepaald welke dat zijn, in welke volgorde.

Vroeger maakt zowel Chrome als Safari gebruik van webkit. Tegenwoordig maakt Chrome gebruik van blink wat een fork is Webkit. Safari gebruikt zijn eigen versie van webkit, dus die twee kunnen inmiddels al aardig uit elkaar gegroeid zijn.

bron 1: https://en.wikipedia.org/wiki/Google_Chrome
bron 2: https://en.wikipedia.org/wiki/Safari_(web_browser)

[Reactie gewijzigd door Laurens-R op 11 september 2017 12:49]

Geen idee waar dit vandaan komt, aangezien Chome juist als de standaard wordt beschouwd.

Chrome als de standaard? Onzin natuurlijk. Chrome loopt vaak voor op de standaard, gaat vaak goed maar soms gaan ze de verkeerde kant op.

Dit is een reactie die beaamd dat het de nieuwe "IE" is, meest gebruikte wil niet zeggen dat het de standaard is. Het W3C bepaald de webstandaarden, de browser makers implementeren die en ja Blink is vaak de eerste die dit doet alhoewel Gecko (Firefox) vaak niet ver achter ligt.

Ontwikkelaars hadden een hekel aan IE omdat Microsoft nogal vaak van de standaard afbrak. Daarnaast waren de specificaties van het W3C niet altijd waterdicht waardoor er browser verschillen optraden.

[Reactie gewijzigd door Xthemes.us op 11 september 2017 13:15]

Mijn woordkeuze was niet bijzonder goed, merk ik. Ik bedoelde ermee dat Chrome het erg goed doet en in mijn optiek de beste is. Het is niet voor niets dat het de nummer 1 browser is onder web developpers.

Heb je hier ook onderbouwing voor?

Ik heb zelfs vaker problemen met Firefox, dan met Chrome hoor.. Chrome wordt tenminste nog actief ontwikkeld..

Ik heb zelfs vaker problemen met Firefox, dan met Chrome hoor.. Chrome wordt tenminste nog actief ontwikkeld..

Mozilla is op gebied van ontwikkeling van nieuwe browsertechnologie met hun Servo architectuur juist vele malen vooruitstrevender bezig dan Google met Chrome is. Google staat gewoon een flink stuk harder van hun toren te tetteren dan Mozilla, die hun werk veel meer in stilte doen.

Zou maar zo kunnen, maar ik heb vaker dat Firefox crashed in een maand, dan Chrome doet in een half jaar. 1 ding is zeker: Ik ga daar m'n hele pc niet voor opnieuw installeren

Er zijn twee "IE's" op dit moment:
1. Safari die pas laat upstream (in zoverre nog daarvan sprake is) van WebKit binnen krijgt.
2. Google met Chrome(mium) en haar (web) services die HTML5 proposals (die dus niet stable noch standaard zijn) doordrukt waardoor andere browsermakers die ook moeten implementeren (en dus als standaard moeten beschouwen).

Linksom of rechtsom bepalen grote techreuzen de standaard ipv een onafhankelijke groep.

[Reactie gewijzigd door RoestVrijStaal op 11 september 2017 20:34]

Hier ben ik niet echt mee eens, het Chrome deel in elk geval.

Google is een aanjager van moderne API's. Zij bedenken en implementeren iets waarvan zij denken dat het goed is en dan gaat het naar de standaardencommissie en die neemt het dan over, past het aan (Web Components bijvoorbeeld) of verwerpt het.

Dat Safari achter loopt (ze zijn op het vlak van Service Workers eindelijk wakker geworden) is wel kwalijk.

Nee Chrome implementeerde het al voordat het bij de standaardencommisie ligt, daarom liggen Safari en ook IE achter want die willen eerst de commisie afwachten.

Nu haal je Service workers aan maar die is nog steeds niet final, vind je het dan gek dat andere browsers het nog niet implementeren?

Ja dat is wat ik zeg toch? Wat vind jij het juiste pad dan? Dingen op papier bedenken, standaardencommissie erbij betrekken, wachten tot het eens is, implementeren, aanpassen (want je kan van te voren niet alles bedenken) en dan meerdere versies in omloop hebben?

Ik vind het wel goed zo, het houdt het tempo er in en tijdens het gratificeren kan de community middels hands-on ervaring feedback leveren.

Je wilt juist niet dat er standaarden geïmplementeerd worden die nog niet af zijn. Als er websites zijn die hierop gebouwd zijn kunnen die na een update helemaal uit elkaar vallen. Het is ook idioot dat Chrome standaarden zou implementeren die nog niet af zijn. Waar ik wel een voorstander zou zijn is dat deze features achter een flag zitten zodat de gebruiker dit eerst aan zou moeten zetten. Hierdoor kunnen ontwikkelaars wel al met de standaarden spelen maar weten ze dat het nog niet af is.

Dat is ook vrij naief om te doen. Het is aan de webdevs om er mee te spelen, kijken hoe en of het werkt, wat er aan schort. Je moet niet een niet-finalized functie niet in productie nemen zonder fallback, dat weet iedere dev.

Als een dev geen niet-finalized functie mag gebruiken waarom zouden ze dan wel een niet-finalized standaard mogen gebruiken.

Omdat het gewoon 'kan'

WebRTC is daar een leuk voorbeeld van. Er is jaren over gekibbeld, en toen het eenmaal af was en op schaal gebruikt werd, kwamen ze er achter dat een IP mee sturen naar de client toch wellicht niet zo'n slim idee was, waardoor er toch wel aardig wat aan de specs veranderd moest worden.. En men had dus net zo goed niks aan die standaard van WebRTC..

Standaarden zijn niet pas interessant als iemand op de 24e verdieping er een handtekening onder heeft gezet.. Soms is het hele idee van een standaard zelfs maar een 'bootstrap', zodat er goed gekeken kan worden wat uberhaupt mogelijk is als het in een browser beland (Kijk naar WebAssembly), ik speel er nu al een half jaar mee en krijg tonnen aan ideeen over hoe ik het in mijn projecten kan gebruiken.

Ik ben het met @418O2 eens.. Het is helemaal niet erg om meer te implementeren dan de standaard, immers zal er voor de leken die alles maar wat proberen tot het werkt, toch geen documentatie op W3 voor ze klaar staan, dus met andere woorden, ze zullen er waarschijnlijk nooit achter komen dat het in de browser zit.

Zolang de browser boeren maar de standaard volgens als die eenmaal COMPLEET is, en er niet van afwijken zoals IE graag deed, dan kan er letterlijk helemaal 0.0 verkeerd gaan. Maar het geeft wel de ruimte om programmeurs alvast aan het denken te zetten en de techniek 'warm' te maken.

Maar dat gezegd, ik vind wel dat browsers als Chrome een 'unfinished feature' warning moeten geven in de console, net als ze nu doen met deprecated functions etc

[Reactie gewijzigd door DutchKevv op 11 september 2017 14:32]

Dan vind ik het disabled van features toch beter. Anders krijg je weer browser-specifieke implementaties zoals je wel eens ziet met CSS met de -moz-, -ms- en -webkit- prefixes.

ze hebben nu ook al meerdere versies in omloop: stable, beta, dev en canary.
waarom zouden ze de functionaliteit die nog niet standaard is niet in de beta zetten?

Omdat dat niet de functie is van die stappen. Het is de bedoeling dat de beta doorschuift naar stable als het getest en stabiel bevonden is.

Waarom zouden ze die functies niet doorzetten? Dan kom je nooit vooruit

[Reactie gewijzigd door 418O2 op 11 september 2017 13:14]

omdat je dan juist krijgt dat websites die functionaliteit gebruiken, waardoor er aanpassingen gedaan moeten worden om het in browsers te laten werken die wel de standaard aanhouden.
bovendien hoeven niet alle functies uit een beta door te schuiven. als bepaalde dingen niet geaccepteerd worden als standaard, kunnen ze dat prima laten zitten totdat het wel kan.

Alleen heb je het probleem dat een site wel op de ene browser werkt en niet op de andere.
Je wilt maar 1 browser nodig hebben. Het was vroeger ook altijd een issue met netscape en IE. Microsoft verzon zelf dingen buiten de standaard om. en website-bouwers maakten daar gebruik van. Vervolgens werkte de website alleen onder IE op Windows. Elk andere andere browser op een willekeurig OS werkte dus niet.

Dat wil je toch ook niet?

Dat is nu toch ook niet zo? Hoe wil je anders nieuwe standaarden creeeren? Op papier en dan wachten tot iedereen het heeft geimplementeerd?

Wat erg gebruikelijk was, tot een aantal jaar geleden, was dat je de 'experimentele features' opt-in maakt, in plaats van opt-out.

Je laat web developers experimenteren met de functies en belooft niemand dat ze over een jaar nog bestaan. Door ze opt-out te maken, of zelfs te forceren op al je gebruikers, dwing je de adoptie van technologie die al dan niet volwassen genoeg is om op zichzelf te staan. Tegelijkertijd zorgt het voor een hoop compatibiliteitsproblemen ten opzichte van andere browsers, en het geeft je als het browser met het grootste marktaandeel een 'unfair advantage' tegenover andere browsers die gegarandeerd altijd achterlopen op de 'nieuwe' APIs.

[Reactie gewijzigd door Laloeka op 11 september 2017 13:28]

Het probleem is alleen dat Google met chrome z'n dergelijk groot marktaandeel heeft dat hun beslissingen bepalen worden voor de toekomst van het web. Ongeacht wat de commissie beslist kan het gewicht dat google bepaalde zeken gewoon forceren.

Het probleem is een beetje dat Google met hun dominante browser positie in hun eentje bepalen wat de final word van nieuwe features. Bij de w3c worden meestal meerdere oplossingen voor een probleem bedacht, maar hier zie je dat de positie van Firefox, opera en edge (ik noem ie niet meer) niet voldoende is om Chrome van implementatie te veranderen.

Ps. Ik heb het expres niet over de bedoelingen van Google want wij kunnen niet weten of ze het goed bedoelen of niet, maar momenteel bepalen zij wat de nieuwe webstandaarden worden en hoe ze eruit zien

Maar waarom lijkt bijvoorbeeld Firefox hier dan wel in mee te gaan? Firefox heeft het imago dat het achterloopt ook niet, maar Mozilla is toch altijd een voorstander van open standaarden in plaats van proprietary?

Iets kan pas een standaard worden als er een voorbeeldimplementatie van is.

Waar haal je dat vandaan?

Je kunt prima alle regels op papier zetten zonder ook maar één regel code geschreven te hebben. Dat is hoe het al decennia gaat in de computerindustrie.

Dan kom je er alleen bij implementatie of praktijkgebruik achter dat er wellicht dingen in missen of architectureel niet kloppen. In de praktijk testen is toch beste in mijn ogen.

Waar haal je dat vandaan?

Het process van het W3C zelf.

Op eigen kracht kan een specificatie slechts tot candidate recommendation verheven worden. Er moeten tenminste twee individuele implementaties binnen concurrerende browser-producten publiekelijk beschikbaar zijn -- niet komen; maar zijn -- wil een specificatie tot de recommendation status verheven worden.

Dat is tegelijkertijd het hoogste niveau van stabiliteit. Het W3C kent geen 'standaarden', enkel 'aanbevelingen'.

[Reactie gewijzigd door R4gnax op 11 september 2017 20:20]

Maar zij is het bijna altijd al geweest. HTML5 was al grotendeels geïmplementeerd door alle browsermakers lang voor de definitieve spec klaar was. En die standaarden ontstaan vandaag net door de ontwikkeling die gebeurd bij de browserbouwers en niet omgekeerd. Neem nu HTTP/2 dat een doorontwikkeling is van SPDY. Hadden we google niet gehad dan hadden we vandaag waarschijnlijk nog altijd geen HTTP/2 standaard.

Chrome is gebaseerd op het open source Chromium. Ik vraag mij altijd af wie nu de echte aanjager is van de moderne API's en de ontwikkeling daarvan.

Voor wie het niet kent, het moederschip: https://www.chromium.org/

Dat (chromium) is volgens mij gewoon een Google project? (al dan niet indirect)
Gros van de gebruikers installeert overigens gewoon Chrome met het Google label.

[Reactie gewijzigd door Koffiebarbaar op 11 september 2017 13:06]

Chromium is zeker geen Google project. Integendeel zelfs.

Google pakt de de open source bron code van Chromium op en voegt er van alles aan toe tot Chrome.
https://nl.wikipedia.org/wiki/Chromium_(software)

Mac gebruikers kunnen dus ook voor het open source Chromium gaan wanneer zij Spotify willen gebruiken.

[Reactie gewijzigd door Corrigan op 11 september 2017 13:18]

Dat klopt niet helemaal..
https://www.reddit.com/r/chrome/comments/1xsxjv/best_browser_google_chrome_vs_chromium/

Lees de eerste comment maar, goede uitleg.

[Reactie gewijzigd door Kapitein187 op 11 september 2017 13:30]

Wat klopt er dan niet? Veel van de Google developers schrijven mee aan Chromium code.
Het verschil is dat Chromium wordt beheerd door de open souce gemeenschap en Chrome door Google.
Google voegt aan Chrome nog het nodige aan toe, zoals automatische crash report aan Google en de optionele gebruikers tracking. Chrome is daardoor geen open source meer.

Hier staat het beter uitgelegd:
https://www.howtogeek.com...ween-chromium-and-chrome/

[Reactie gewijzigd door Corrigan op 11 september 2017 13:46]

Het verschil is dat Chromium wordt beheerd door de open souce gemeenschap en Chrome door Google.

Dat verschil is er niet. In de praktijk wordt Chromium ook beheerd door Google. De broncode wordt gehost op chromium.googlesource.com. De benodigde infrastructuur (servers, opslag, rekenkracht) worden geleverd door Google. De meeste contributies worden gedaan door werknemers van Google.
Zelfs de bron die jij aanhaalt bevestigt de grote invloed van Google op Chromium:

while it’s not Google-branded, Chromium is still very Google-centric.

WebKit wordt gesponsord door Apple, maar lijkt minder "last" te hebben van commerciële belangen van Apple.

Klopt. Maar er zal vast een verschil zijn, anders was het er niet.
Als ik wat verder op internet lees dan is dit de formule: Chrome = Chromium + meer extra Google stuff.

Ik gebruik beide naar tevredenheid. Chromium op Manjaro Linux en Chrome op een Chromebook.
Fijn als er keuze is. Jammer dat Spotify dat niet doet en de keuze voor de consument wil maken.

Het zelfde gedrag dus als de hoogtij dagen van IE, roestvrijstaal heeft weldegelijk een punt.

Behalve dat er nu overleg is tussen vendors en Google wijzigingen in standaarden doorvoert.

Ja onder het mom dat het goed staat voor de publieke opinie (zoals zonnepanelen op je pompstations plaatsen). Maar alles wat ze doen is uit een machtpositie en het vergroten van die macht en daarmee de winst.

Ik heb het idee dat je beeld alleen is gebasseerd op het DRM-vraagstuk. Verder snap ik niet wat je probleem is. Ze komen met veel nieuwe features die worden geadopteerd door alle andere browser-makers en dat gaat echt niet met het pistool op het hoofd.

Nee alles is gebaseerd op meer advertenties verkopen en zorgen dat ze meer marktaandeel krijgen. Al hun gedrag (goed en kwaad) is daar op gebaseerd. Ik geloof niet dat een bedrijf zoveel macht moet hebben. Het corrupte Amerikaanse systeem, dat politiek gekocht kan worden is door Google zeer breed omarmd (net als anderen). De tijd dat Google dat leuke bedrijfje was dat tegen de grote reus aan het vechten was is voorbij hoor. De reden dat ze hun browser doordrukken, gratis besturingssysteem en goedkope apparaten pushen is hetzelfde, macht macht macht.

Google handelt vooral in het belang van Google. Widevine is van Google. Google was ook een grote proponent voor Digital Restriction Management te ondersteunen in browsers, via plug-ins zoals Widevine. Mozilla heeft schoorvoetend eraan toegegeven, en ondersteunt het nu ook; tegen het marktaandeel van Google kunnen ze niet op.

Ondertussen is de consument weer het slachtoffer. DRM wordt nu weer geregeld door plug-ins in de browser, terwijl we juist vanwege security, portability en usability af wilden van dit soort plug-ins! Sowieso heeft DRM geen enkele toegevoegde waarde voor de eindgebruiker. Voorbeeld: Spotify die nu DRM oplegt, terwijl een veelgebruikte browser dat niet ondersteund.

Ik heb DRM uitgeschakeld in mijn browser. Het viel op dat de video's op de NPO-website, zelfs de media die door NPO zelf geproduceerd is zoals het journaal niet zonder deze DRM te bekijken zijn. Absurd!

Ik ben het dus eens met @RoestVrijStaal.

Spotify zonder DRM gaat niet werken vrees ik. Dan regel je met een vriendengroep een abonnement, downloadt die ene persoon alle content en deelt die met de rest. Weg verdienmodel. Wil je geen DRM, gebruik dan geen Spotify. Genoeg DRM-vrije alternatieven zoals iTunes of de ouderwetse CD.

Dan regel je met een vriendengroep een abonnement, downloadt die ene persoon alle content en deelt die met de rest.

Wie doet dat nog? Natuurlijk zijn er nog genoeg mensen die zelf media downloaden, maar de tijd dat hele hordes Napster gebruikten ligt ver achter ons. De meeste consumenten (zeker de niet-techneuten) willen gewoon streamen. Wat een gedoe¹ om GiB's aan bestanden te verspreiden tussen je vrienden!

Als je al de piratenroute neemt, waarom zou je dan Spotify zelf gebruiken? Genoeg alternatieve piratenbaaien waar ook niet-Spotify-content te vinden is immers.

Spotify zou zomaar DRM-vrij kunnen streamen en nauwelijks verlies aan inkomsten zien.

1: Voor de gewone consument dan natuurlijk.

Leuk verhaal. Als je dat dat je de rechthebbenden van al die muziek/films/series kan wijsmaken krijg je misschien DRM-vrije media in de toekomst.

Dat mag je zijn. Ik ga verder niet met je in discussie, want we gaan het niet eens worden over het nut van DRM en de mogelijkheid tot bescherming van je intellectuele eigendom.

Maar waarom lijkt bijvoorbeeld Firefox hier dan wel in mee te gaan? Firefox heeft het imago dat het achterloopt ook niet, maar Mozilla is toch altijd een voorstander van open standaarden in plaats van proprietary? *knip, verkeerd draadje*

[Reactie gewijzigd door Stoelpoot op 11 september 2017 14:14]

Firefox gaat in een hoop dingen ook mee hoor. En ook Edge doet goed mee en is open ( https://developer.microso...oft-edge/platform/status/ )

de vendors zijn, zoals gezegd, tegenwoordig goed met elkaar aan het overleggen

Oh, ik zat bij een verkeerd draadje. Foutje bedankt.

Over het Chrome-team zelf doe ik geen uitspraken (ik heb ooit zelfs ergens gelezen dat veel developers het niet eens zijn met wat Google doet), maar Google in het algemeen is zeker geen aanjager van gestandaardiseerde API's... Google is actief bezig met de user experience van hun services in andere browsers slechter te maken. Enkele voorbeelden:

• Ze maken voor meerdere van hun services (Google Earth, Hangouts...) gebruik van hun eigen NaCl, wat dus niet werkt op andere browsers. Voor Hangouts specifiek wijken ze voor het WebRTC-gedeelte ook af van de standaard op een manier die enkel in Chrome ondersteund is.
• Ook Allo is enkel beschikbaar voor Chrome, maar ik heb niet onderzocht waarom
• Op Firefox voor Android sturen ze bewust inferieure HTML door voor hun zoekmachine. Hier is absoluut geen technische reden voor, als je je user agent aanpast, werkt het wel.
• De nieuwe video previews op Youtube werken niet. De reden is hiervoor dat ze WebP gebruiken, goed wetende dat andere browsers hier (nog) geen ondersteuning voor aanbieden.

[Reactie gewijzigd door TimVdE op 11 september 2017 17:50]

Je hebt gelijk, het gaat naar de standaarden commissie. Weet je wie daarin zit? Google. Met overweldigend veel meer vertegenwoordiging dan iedere andere speler. Sterker nog, een Googler (Ian nogwat) heeft het veto op de HTML5 spec.

De vraag is natuurlijk hoe precies je die macht afpakt van een browserboer die gewoon het leeuwendeel van de markt in handen heeft op verschillende vlakken, en weer teruggeeft aan w3c.

Ik vind overigens stiekem dat Google het best oké doet, ook al is het op zijn Microsoft's al die vage shit van websites waar je persé IE (Chrome) voor moet hebben heb ik nog niet terug zien komen dus schijnbaar kunnen ze best met de veranderingen van Google omgaan.

[Reactie gewijzigd door Koffiebarbaar op 11 september 2017 13:09]

De desktopapplicatie van Spotify is in feite gewoon Chrome met een custom interface, toch?

dat is volgens mij gewoon een electron app ja

Spotify maakt gebruik van het Chromium Embedded Framework. Geen Electron.

Bron: https://www.quora.com/How...hat-JavaScript-VM-is-used

Ah dat wist ik niet. Vond het al te performant voor Electron.

Inderdaad, en in ieder geval zijn grote delen van de client broncode gewoon in te zien (op Mac) door de .spa files te unzippen.

Wellicht dat zo een onofficiële client te bouwen is

Ja (nee eigenlijk, zie reactie van @Kren. Rest van deze reply geldt nog steeds), en dat was de reden dat ik de web-player gebruikte met safari. Chrome draai ik enkel als ik iets wil testen op chrome, mijn batterij gaat meestal 2 - 2.5u minder lang mee met Chrome (of Spotify of welke andere Electron app dan ook). Dat vind ik gewoon niet acceptabel, ik wil erop kunnen vertrouwen dat mijn laptop 12 uur meegaat met mijn workflow, en als Spotify dan (in de achtergrond, zonder iets af te spelen) nog steeds veel CPU cycles trekt, klopt dat gewoon niet, al helemaal niet in 2017. Ondersteunt Electron AppNap? Waarom gebruikt het zo veel in de achtergrond?

[Reactie gewijzigd door jeffhuys op 11 september 2017 13:23]

En de Genres & Moods / Running op Android is ook plots verdwenen. Wat een firma.

Spotify gebruikt ogg voor Android, iOS en desktop, maar AAC voor de web player. Ze zouden ogg kunnen gaan gebruiken voor web als ze Safari support droppen. Ogg is vrij van royalties, ook voor grootschalig gebruik (zoals in browsers), in tegenstelling tot andere codecs.

https://support.spotify.c...e/high-quality-streaming/
http://diveintohtml5.info/video.html#what-works
https://arstechnica.com/g...tml-5-video-codec-debate/

Niet alleen Safari, maar ook op de browser van mijn LG OLED WebOS TV werkt het niet meer, waar ik al op over ben gestapt nadat ze plots de WebOS app hebben verwijderd, zonder een alternatief te bieden...

Idem bij sommige Samsung TV's. Bewuste keuze van Spotify!

Samsung Smart tv app going away?

[Reactie gewijzigd door Carbon op 11 september 2017 13:52]

Klopt. Over de LG WebOS app zeggen ze het volgende:

As we look to improve the overall Spotify experience, we removed our app from LG TV systems on July 3rd 2017. We hope to have a better version of Spotify on these devices in future.

Dus geen ervaring is beter dan een mindere ervaring... Wellicht was het slim geweest eerst een betere versie uit te brengen en dan de oude app te verwijderen