Problem: Firefox and other privacy respecting browsers have anti-fingerprinting measures that report out UTC timezone. While users can disable anti-fingerprinting, it also makes their privacy worse. In an age where surveillance capitalism is the norm, users shouldn’t have to compromise the privacy of their browser just for proper forecasting.
Solution: Have an optional setting that allows a user to set a timezone for forecasting. If set, forecast uses the set timezone instead of the timezone pulled from the browser.
Edit: Other Japanese studying resources like BunPro and Kistunio have this implemented if an example reference is desirable:
Fingerprinting Protection. Been in the browser for a number of years since they upstreamed it from Tor Browser alongside a few other things.
Not really? Not many people regularly deal with UTC based events. Guarantee you if you were to ask Firefox Wanikani users what the current time was in in UTC, 95% wouldn’t know.
That’s the point of requesting it here in #wanikani:feedback … 3rd party scripts have no guarantees about being maintained and are subject to being broken due to API changes, etc. From a 1st party perspective it’s pretty easy to implement:
It’s not as easy as you might think btw, the WK team have a lot on their plate right now it seems, as far as I can tell, they are rethinking most parts of the review process to refine it. Besides you would need at least a place where you can set the timezone, probably in the settings, and you would need to store that in a database somewhere. Then this would be another place where bugs could appear from then on.
Sure, but as a .NET webapps developer for a Fortune 50, adding a simple col to the UserProfileSettings DB table, tweaking the CreateUserProfile stored procedure to by default make timezone null, a SP to get/set timezone, and a timezone selector UI element on the existing settings page is about as basic as it gets from a developer complexity/requirements perspective. The logic is already there to create a Forecast based on a given timezone, all one is adding is an optional col to the UserProfileSettings table w/ basic get/set to make it user provided if desired instead of browser provided. The surface for new bugs is next to nil. There are two general cases: null or not null (and not null is a provided, selectable list, so users can’t provide bad inputs). And again, because the Forecast logic already exists, it’s just browser timezone based, the Forecast case handling should already exist if they have decent devs.
The real question is whether or not the ROI is justifiable for a day’s work on this given the small % of global Firefox/Librewolf/Tor Browser users, and what’s on WK’s current roadmap.
“Review Forecast” is not a third party feature (userscript) that is time zone dependent, it’s an out of the box, first party feature that is time zone dependent, hence why I’m requesting the enhancement here in feedback and not a userscript that is time based thread:
It’s just that WK makes the assumption that the browser always reports the ‘correct’ timezone and I’m here reporting suggesting that WK like Bunpro and Kitsun have change that assumption given other threads have reported this as an issue in the past, but gotten the brush off by forum goers to disable privacy features such as:
Edit: It’s certainly possible though that WK could also make the user set timezone visible to userscripts to provide a better experience though, although this isn’t required for a minimal viable enhancement