Flash vulnerabilities and html5/web standards
I've stopped doing lessons thanks to the storm of zero day exploits for Flash. I was hoping Duolingo would move to html5 and open web standards but so far it looks like that's a no. With flash uninstalled I still get the type what you hear questions despite the fact there is nothing to hear with flash removed. It would be nice to get some feedback from the Duolingo team on whether they plan on making this site safe for users by moving away from vulnerable and unsafe plugins.
Interesting, I was wondering as before if flash was blocked the site would complain about it. However I too am in Firefox and get no audio from Duolingo. I know audio is functioning because it works in many other sites I use though all using html5 <audio> tags etc.
Makes no sense... Duolingo will not push down malware to your PC using Flash. Last time I heard, DL was not run by Ukrainian cyber-gangs... Some dodgy sites and hacked sites will use Flash vulnerabilities, but you can set Flash not to autostart, and allow it to launch only when you deem it safe.
That's not how all this works man. Even having flash set to only run when asked does not secure you. This isn't about DL this is about the Hacking Team exploits for sale combined with tons of other zero days and many proof of concepts. Flash has always been a target on your back but as of the Hacking Team reveal things have got way out of hand and it has nothing to do with Duo's site.
That said Duo's site if compromised could become another attack vector. I do not expect Duo to protect me it's our own responsibilities to be vigilant online but trusting external network sources as being untouchable by exploits or "bad people" is a set up for bad things. Comically look at the fact Microsofts own privacy and security site got exploited about three weeks ago. I'm guessing that one was for the ironic lulz.
As a final note in many ways allowing sites to run < [audio] > or < [video] > (it keeps removing the tags) can be dangerous as well as @font-face. Chrome users went years without being able to correctly see sites using custom fonts due to Google's stance on the serious exploit-ability of @font-face.
As someone that has done white hat hacking (hate that term) and systems for over 20 years, ya that's how it works. If you are connected to external networks, you are vulnerable. If someone else can gain physical access, there is no question you're wide open.
Same industry, same years. Man, am I jaded... I wish I'd become a ballet dancer or some other reasonable occupation instead. But now, after so many years protecting government cyber infrastructure, I find most IT-security related claims exaggerated, overhyped. I still remain vigilant.
Well man you're clearly less jaded than me so count your blessings. I've seen too many trusted sites start doling out malware simply because their hosts did something stupid on their configs.
I'm not paranoid like some of my friends were but I still try to not blatantly trust things. The sad reality is I don't have time to sift through source and keep up with it all anymore.
Even if I was still doing it you don't catch everything all the time. I mean that's the point of hacking, finding that bit of logic that everyone has overlooked and how it can be twisted.
@rocko2012 I'm going to test a few things if you've got html5 audio going. I'm currently running FF38 just because it was in the repo's but I'll nuke it and toss on current to see if it's functioning in 39.
Nope no audio in 39...le hrmmm. Knowing they have implemented it at least lets me know the issue is on my end rather than them clinging to flash so it's a step forward.
Update: Ahhh got it, they are using canvas for audio! -or possibly not.
Updated Update: (said in Robert Stacks voice) Updated Firefox, disabled canvas blocking, got audio. Went to re-enable but whitelist the site FF is reporting Canvas blocking was enabled thus conflicting with the previous assertion.
Looks like FF disabled Noscipt rather than Canvas upon update thus everything worked. Canvas doesn't appear to be the audio delivery method but rather some js on some cloudfront servers. So if you are having the same issues i.e. no html5 audio it's possible some js (javacsript) blocking is going on. Sadly the cloudfront.net servers being used are a bunch of random crap like 4kj1kj2jkh8j9h54fc7df8o.cloudfront.net and I've seen some DNS blocking against domains with random letter number domains because it's so commonly used for spammers and exploits. In my case it was simply I had to white list other domains in no script where the html5 assets were being pulled from.