One important advantage with Night Shift is that it doesn't mess up YouTube videos. I get weird artefacts with f.lux when watching videos, and overall Night Shift seems to perform slightly better as well. I'm sad for f.lux but for now I stopped using it.
edit: I don't get the artefacts with NS but I do get the same white border on the mouse cursor after watching a video full-screen for some time
Took me three clicks to view the source code. Have you looked at it? Bloody hell. It's a CSS file. All the hard work is in finding the problem. Which this man has done for you.
In the time it took you guys to comment you could have written the user style yourself after looking at the source code.
I cannot believe the degree of cargo culting that goes on on this website around security.
You're right about me being a security nut. But I don't think it is unwarranted to be paranoid about letting an extension have those permissions. Especially when the extension can auto update without my permission. There's no way for me to stop the extension from updating in the options.
You viewed the source code, but the extension checks for an update every couple hours and updates itself. You might trust the developer to not do anything bad, or not accidentally leak his private key for the extension. The only way to stop it from updating itself is to go to the manifest file and removing the update url.
I'm tired of the anti-security comments that come up against people commenting about bad security practices, even though they're restrictive and paranoid. This is the case when you need to be paranoid. A quick google search give me this[1]
Ever let someone's code have access to everything on every webpage, including all of your financial and personal ones you use? Well you're doing it right now. The only way I'd be okay with letting extensions access and change contents of webpages if they specify the website url they're going to access, and those are the only websites they can access (Reddit Enhancement Suite does this)
I appreciate the developer's time on this and don't mean to disparage their effort. But, how many developers are you going to keep trusting this way? You can't normalize every extension having those permissions! Read and change, not just read all websites.
You know enough to look for the source and check it out. But what about the users who don't know how to do so or can't read code? Even if they can, can they discern malicious code from harmless code? Will you say the same thing you said to me to a user with no understanding of how these things work?
I'd actually love to know how you got to the source code in three clicks. Wish it was that easy to view an extension's source other than digging through the chrome internal data folders.
And I don't think cargo culting is the correct term, or bike shedding. I'd say something to do with tin foil hats would be more appropriate.
Looks like this is something browser vendors should incorporate? One would think that because WebKit is free and open source it should be possible to have this fix evaluated for everyone built into Safari and chrome by default.
"Bike-shedding" may be a more fitting term for what you are complaining about. Cargo-culting would be almost the opposite in my mind; e.g. people mindlessly copying a pile of magic CSS they don't understand.
Anyway, I guess I'm just another security grump, but knowing it's a single simple CSS property only makes me feel further justified that "Read and change all your data on the websites you visit" is unacceptable. I don't think that's restricted to security nerds on HN either -- there are probably would-be users who can't find a CSS file on Github and translate it into a user style, who will also not install the extension, if that's what Chome tells them it "requires." I don't know if that's purely Chrome's fault for not having an extension architecture capable of requesting less scary permissions to get this job done, or if the developer could do better too.
About the permissions, the developer said it was the minimum permission setting they had to give the extension. You can see someone replying to a user's comment on the extension's review page.
I can't say it's chrome's fault in this case. The extension is effectively acting on every single web page, even though it's just CSS.
Really? You can't believe people in a technical community, in 2017, are worried about security? That's actually hard for you to believe? That people who talk about VPNs and data breaches and Edward Snowden and Aaron Swartz, you can't believe that people here are concerned about security?
Hello, I'm the author of the extension. It's ok if you don't trust it. I couldn't find any way to ask for a smaller set of permissions. To my knowledge there is no way to specify this in the manifest. (I can't ask for permission to insert a stylesheet without also having permission to inject JavaScript, even though I don't have any JavaScript.)
I'm sorry if I came off as critical of your work. I did see you commenting on the extension support page and talked about it here[1]. I was pointing out the permission model. I went into a little more detail here[2]. It's just how things are I guess.
Please don't let us security paranoid people stop you from contributing to open source software. And 6k+ users are using it with great reviews so you must already know your work is much appreciated. My gripe was about security practices, not about doubting the security of your specific extension. It is same problem with the way chrome handles all of the extensions' auto-updates.
It happens when you play full-screen videos on a mac. The full screen mode displays in a more direct screen access manner (but only after any overlays, like video controls, have faded out). In this mode, f.lux's color profile changes can cause weird blooming issues, especially in bright ares of the video (like a blue sky). Apple seems to have built their solution in a way that avoids this issue.
It's likely f.lux cannot ever do anything about it. Until Night Shift was available, I've been in the habit of of creating "low color temp" color profiles and manually setting my display to them when it gets late in the day (a crude approximation of f.lux, but ultimately the same thing they are doing). It always produced the same artifact.
Incidentally, I find it strange that f.lux is claiming they output so much less blue light than Apple's Night Shift, since as far as I can tell, all they do is shift the color profile, just like Night Shift does. Anyone who has seen the video issues I'm describing above can attest that there is still plenty of blue light coming out of the screen with f.lux (and manual color profile adjustments). All three accomplish the same thing, it's just that Apple's implementation appears to be cleaner and work in more cases (not surprising -- it's their system, so presumably they know how to integrate with it better than anyone). I think perhaps at most they have a point that the default settings are maybe not "warm" enough, but that's the only flaw I can see.
I have artifact issues with f.lux whenever I'm watching videos in full screen mode. It seems that anything "white" coloured becomes fluorescent. Making the nav / time bar pop up with my mouse seems to make this all disappear. This is on a 2014 MacBook Air running the 2nd latest version of OS X.
I don't entirely understand the reasons for it, but if you have a MacBook Pro that can switch between integrated graphics and discrete graphics, disabling Automatic Graphics Switching under Energy Saver will fix the problem.
It's not very subtle. I just whipped together an example[1]. Note that I had to take a photo of the screen with my phone to show what the screen is actually displaying.
F.lux doesn't "deal" with anything, it just takes your existing ICC/ICM file, alters it, and resets your GPU's LUT with it.
I've had the same issue with an Intel GPU'ed MBPR 13" (ie, no Radeon or Nvidia GPU also), and it rarely happened in OSX, but only during certain HW accelerated overlays (such as YUV acceleration in videos, or OpenGL programs doing sufficiently interesting things).
I don't think F.lux has the bug, but OSX's rendering pipeline does. I had similar issues with color profiles I generated myself that noticeably differed from the screen itself (Apple has yet to produce an actually fucking accurate-to-sRGB screen, I don't care how many Photoshop jockeys praise their lord and savior, St. Jobs).
So, yeah. In other news, my MBPr runs Windows 10 and I'm never going back; and I've also never seen the bug here.
The side effect is: F.lux's Windows version is not feature complete with OSX's, and noticeably redshifts at different times than OSX does depending on what settings you prefer.
It occurs on machines with Intel integrated video only in my experience. Does it on my 2011 MBA and 2016 touchbarMBP, but not my 2012 rMBP. It's well documented here:
It's not Night Shift — this seems to be fixed in 10.12.4.
I filed a bug with Apple on it, and in November of last year they duped it to rdar://22180778 and said to expect a fix in 10.12.4… so I've been waiting eagerly for this update, and it looks like they followed through.
Having recently updated from 10.8 to 10.12 I can tell you it wasn't happening before, but definitely one of the annoyances now. My workaround for now is hovering my mouse over the control bar. For whatever reason that removes the artifacts.
edit: I don't get the artefacts with NS but I do get the same white border on the mouse cursor after watching a video full-screen for some time