Please disable Duolingo's HTML obfuscation to allow user themes to continue to work
Hi, I am the author of a fairly popular Duolingo userstyle, which was popular with a number of heavy Duolingo users and late night learners. The userstyle was possible because Duolingo uses regular class names on its HTMLs, which allowed userstyles to target elements in the sites reliably even throughout various minor changes. I was committed to support the userstyle as long as I am a Duolingo user and as long as maintaining it does not take up an unreasonable amount of my time and I have maintained this userstyle for the past three years including through the previous major site redesigns that had required me to rewrite everything from scratch.
However, with the new Duolingo updated page, the skill tree and lesson pages obfuscates the HTML class names. Class names that previously looked like
.btn-primary and remains fairly consistent across minor updates now turns into autogenerated names like
._1lig4. This makes it impossible for any userstyles to target page elements properly, as these names would break with every little Duolingo updates.
Petition: Please disable this html obfuscation.
I cannot continue supporting the userstyle if Duolingo obfuscates their HTMLs.
Please upvote, follow, and share this petition to bring this issue to Duolingo's attention.
First of all: Many thanks for creating and supporting the duo dark theme! It has greatly contributed to my positive experience of duolingo. The standard duolingo black-on-white theme causes me eyestrain after a while. There are good ergonomic reasons why classic VDUs use green-on-black or amber-on-black.
I was very sad to see the theme partially break recently, and completely support your petition. KEEP DUO DARK!
While this would make things a lot easier for me to continue tweaking styles and writing scripts, I would also like to point out that even if the obfuscation was disabled, most, if not all, of the names have actually been changed. I took a look at the code in Duo's vendor.js and app.js files (I was working on fixing the Course Switcher script) and in them is code that relates each base 64 string to class names. A lot of them are similar but different, meaning you'd still have quite a lot of work in getting your styles to work. In that regard, it's not too bad to get things working with the new stuff. For example, with the style Duolingo Carbon, it took me about 3 hours total work (across a couple days) to get everything that wasn't working working again.
But yes, things would be a bit better without this obfuscation, but if they're doing it for security reasons and performance enhancements, then I can put up with it. I'd rather have a secure site than one that's easy to modify displaywise. I'd also rather have a fast and working site.
Edit: I'll still upvote this though. It's important that it get seen.
I would be fine with having to rewrite the userstyles whenever there is major redesign (that are sort of expected with userstyles). I do also expect that minor design updates will occasionally break a thing or two. But having autogenerated names likely will mean that even the minor updates would break everything since all the obfuscated names would probably just change every time Duo recompile the site's css/js, I can't devote that much time to fix all the class names in the userstyle every time Duo changes its mind about what padding size to use.
Frankly, I can't think of a single good reason why the obfuscation is implemented the way it is.
Thanks for the clarification! I'm certainly not well-versed in web development so I was just trying to come up with some half-reasons. If you say there really isn't any benefit then I believe you.
Perhaps you can answer a quick question for me? If these names are auto-generated, at what point does the auto generation happen if they're currently hard coded into app.js? I don't want to post a screenshot of Duo's code, but an example would be
"submit-button": "_1tqxD _2cWmF _1AthD _1lig4 _3IS_q"
Everything else is also coded in just like this.
app.js contains only the compiled and minified code, it's not the "human-readable source code". Large, complex web applications like Duolingo never have all their source code in a single .js file, it's usually organized into hundreds or sometimes thousands of smaller files which are then compiled and minified/compressed to a single .js file which makes it faster to download.
Alrighty then! Thanks for the response. I'm still super new to the world of web programming, so this has always confused me a bit. Heck, programming isn't even the career I'm going for (theoretical astrophysics is more interesting for me). Hopefully something comes of all this, but if Duo's track record is anything to go by, it probably won't But one can hope!
Writing any kind of script for Duolingo is a pain in the ass and I wonder if they're purposely making it a pain in the ass. For people who would want to steal content with bad intentions, it's still not that hard and it never will be (data scraping - or even something like botting courses). But rather it mainly increases the difficulty (= time spent) of creating -useful- scripts.
Creating a script that integrates Tinycards and gives advanced reviewing options could be very easy if everything worked in a "normal" way. Even on the old website trying to integrate Tinycards with a script was a pain in the ass, requiring many hours of manual touch-ups for every single course when wanting to create the best quality (i.e. strengthening words through integrated Tinycards, which requires you to at the least manually check automatic matches you make). It might not even be doable anymore through the new website. And it's not like Duolingo is providing any "extra services" themselves, hopefully this will change though.
It also beyond me why they don't integrate useful things users have created. Like the Arekolke-Andrewmof course switching extension, why wasn't such a system integrated into the new website? By default or as an option. It's value is véééry clear.
Edit: "Easier ways to switch language courses" in the list of things they're considering. At least they're aware, that's "something".
I was under the impression that some of the work being done involved moving towards having the same functionality across platforms, rather than the current mess of having 4 or 5 different versions of Duolingo (one on iPhones, one on iPads, one on Android, one on Windows and one on the Web, all with significantly different functionality).
It seems likely that any cross platform tools that would support this cross-platform approach will churn out autogenerated class names, and I doubt that there'll be much interest in changing that approach, especially for what is, from Duolingo's point of view, a relatively tiny part of the Duolingo userbase.
It seems likely that any cross platform tools that would support this cross-platform approach will churn out autogenerated class names
All major UI toolkits in all major platforms (mobile, web, or even desktop) supports efficiently querying UI elements by name. There is no technical necessity for cross-platform tools to use autogenerated class names and not expose the human readable name. Duolingo must have actually had spent some time to run their pages through an obfuscator to end up with the kind of code that it is currently producing.
If similar functionality across platforms is indeed a goal, then supporting 3rd party functionality that only works on one platform would not be a priority, and might even be considered a problem.
That you think that the code has to be run through an obfuscator makes me wonder about your experience with the tools involved - generated class-names are the default, unless you make the additional effort to manually assign names, which is wasted effort as far as Duolingo is concerned.
I am a professional web and mobile developer, I develop software for a living, and I am very familiar with the workflow and technologies involved with these sort of things.
Nobody writes any sort of non-trivial UI code without naming their UI elements; as it's more difficult to write UI code that avoids explicitly naming UI elements. Avoiding naming also makes code more difficult to read, write, and follow and the resulting application difficult to debug; no good developers would last working in environment where explicitly naming UI elements are not allowed. You simply are not going to see professional developers leaving their code to just use autogenerated names from whatever framework they use on non-trivial projects.
The only reason UI code wouldn't have explicit names is simply because the code compiler/minimizer has been configured to strip them for whatever reasons, as human readable names are mostly to the benefit of humans rather than the computer.
If similar functionality across platforms is indeed a goal
The target platform for userstyles is only the web version. Native mobile apps does not support userstyles so I am not concerned about non-web platforms either.
Just wondering: Is there any tool, which one could use to "unobfuscate" this code again? Or would one need to know, which tool Duolingo used in the first place?
The first time I saw these obfuscated class names, I thought that's because of advertisments... So one couldn't block them anymore... But doesn't seem to be the case...