... We are turning into our parents.
"When I was your age, we DROVE to the store and used REAL MONEY and bought the DVD! And we LIKED IT THAT WAY!"
First of all, there was NO UI to activate this feature. The only access was through third-party apps that allow you to launch arbitrary activities (for those not familiar with Android, think application windows) in other apps.
So it was obviously unsupported by Google. The first thing I think of are Chrome's Labs at chrome://flags which carries this warning:
WARNING These experimental features may change, break, or disappear at any time. We make absolutely no guarantees about what may happen if you turn one of these experiments on, and your browser may even spontaneously combust. Jokes aside, your browser may delete all your data, or your security and privacy could be compromised in unexpected ways. Any experiments you enable will be enabled for all users of this browser. Please proceed with caution. Interested in cool new Chrome features? Try our beta channel at chrome.com/beta.
And THOSE are UI-exposed, unlike App Ops. The same warnings would apply to App Ops, if not worse.
Android permissions were built on the assumption that they were all-or-nothing: either the user would install the app and grant all permissions, or the user would deny the permissions and not install the app. It isn't like webpage permissions where the user may decline to allow a page to display desktop notifications or go fullscreen and the page can react to that.
Because apps expect permissions to always succeed, the common approach to making permission-limiting frameworks is to make the app think it still has permission by serving it dummy data, like an empty contacts list, or a blank image purportedly from the camera, so the app still operates.
Google is saying some apps were not compatible, which tells me App Ops still needs work, which explains why they have not formerly released it.
Some people have been using App Ops and now find the UI crashes when you load it, but the underlying feature is still applying the settings. Considering it was an unsupported and experimental feature this is not surprising, and it is not surprising Google removed access. Back when Google Chrome was brand new, occasionally Google would ship Dev builds that would crash on launch for a not insignificant portion of the user base. Such is the risk of alpha software (or in this case, an alpha feature).
- It will NOT change the way the system handles PDF files.
- It has NOTHING to do with how the browser views PDF files on the web (the Chrome PDF viewer is already the default).
- It only affects how Chrome handles when you choose to open a downloaded PDF file.
Likely this was done to be consistent. Any security the Chrome PDF viewer could offer could be easily bypassed by an attacker forcing the file to download. If the user clicks it, it opens in the system PDF viewer.
I believe Adobe Reader has its own sandbox so this might seem a bit weird... but at least one thing Chrome has going for it that Reader has not is that Chrome is more likely to be up-to-date (I forget how Reader updates itself, if it does at all) AND it pulls the latest Chrome PDF plugin with it.
On a PC there's no pressing need since I have lots of disk space, and it's easy to keep apps from running in the background.
On Android is another story. Very limited space, and apps can run in the background very easily and are hard or impossible to kill in some cases. I recently uninstalled outlook.com app since I never used it (I installed it intending to, but never did) and it was sucking battery life. I also uninstall apps which provide duplicate functionality that I already have in an app I prefer. Large apps have to really be persuasive to stay as well.
I use an extension to download videos from YouTube. Those tend to be blocked from the Web Store, so you have to install them manually from other websites (this is the bit that is getting blocked). I hope there is at least a command line switch left in to disable this behavior! It's very "walled garden" and I don't like it.
BTW, the summary says "local extensions" but that is incorrect. It just blocks non-Chrome Web Store web extensions. Extensions you are actively developing and load via "Load unpacked extension" will still work.
Actually, that might have to be the fix for my YouTube extension I use. Oh well.
Chrome already blocks malicious downloads. Not sure how this is new. Maybe it's a more advanced version of the existing feature.
The existing feature already looks like the current screenshot, except the text might be different. And yes, you can allow downloads using the drop down on the right.
Possibly this is integration of anti-virus hooks? I think the existing version might just use a Google list of known safe and dangerous downloads.
Yeah Steam is pretty good at running even if you nuke its registry entries (or reinstall Windows) and nuke everything except Steam.exe. It'll redownload all of its missing components and regenerate its registry stuff (though you need to relogin and auth with Steam Guard).
I did have a bit of a hiccup with Steam yesterday when most of their servers seemed to go down for a bit but it was only for like 15 minutes, then they were back up. Though my TF2 hats took a bit longer to come back.
No marketspeak here, but if you're not familiar with the technical details you might be a bit lost. First of all, in order to understand the solution, you need to identify the problem.
The problem is that, currently, refresh rates are STATIC. For example, if I set mine to 60Hz, the screen redraws at 60fps. If I keep vsync disabled to allow my gfx card to push out frames as fast as it can, my screen still only draws 60fps, and screen "tearing" can result as the screen redraws in the middle of the gfx card pushing out a new frame (so I see half-and-half of two frames).
As described, let's say my gfx card is pushing out 25fps. Currently the optimal strategy is to keep vsync off, even though this can result in screen "tearing", because with low fps bigger problem emerges even though screen "tearing" is fixed, with vsync on.
Every time my gfx card pushes out a frame, since vsync is on, it waits to ensure it will not be drawing to the screen buffer while the screen is updating. Since it waits, the screen only draws complete frames. So at 60fps the screen updates in 1/60 second intervals, and the gfx card render at 1/25 second intervals. So, at the beginning of a frame render, the gfx card renders... and the screen redraws twice, and then the gfx card has to wait for the third opportunity to draw before syncing up again. Since it is waiting instead of rendering, I am now rendering at 20fps (since I lose 2/3 refresh opportunities) instead of the optimal 25fps. If I disable vsync, I get tearing, but now 25fps.
This "G-sync" claims to solve that issue by making refresh rates DYNAMIC. So if my gfx card renderas at 25fps, the screen will refresh at that rate. It will be synchronized. No tearing or gfx card waiting to draw.