AMP is bastardized HTML used as an excuse to making a website fast in the first place. I totally agree. Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." [1] Who gave them the authority? AMP worries me greatly. [1] https://github.com/ampproject/amphtml/blob/master/builtins/a...
They've been pretty good about accepting PRs to support any ad network from what I've heard: https://github.com/ampproject/amphtml/pulls?utf8=%E2%9C%93&q...
Yes, just as ABP has been good about accepting PRs to add "unobtrusive ads" - until they started demanding money.
NEVER give this power to a central authority that's not democratically controlled.
That depends. What about blog posts that have inline JS demos?
One example: in my static blog I provide very nice maths using MathJax, but I also provide fallback PNG renders of the formulae. The small JS my blog has, it reads these pictures' alt texts and renders the latex if found. This stuff is not rocket science, people just don't want to spend time on this kind of stuff.
You might want to switch to katex instead - and katex can also be run on the server to return HTML directly.
I'm using the same techniques for my apps to enable accessibility access (which is needed for window management), although I'm asking users for confirmation before doing so. It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users. Why not displaying a simple yes/no popup similar to the "allow access to co…
> Why not displaying a simple yes/no popup Because granting accessibility access is far more dangerous than granting access to contacts / calendar. The latter just exposes some of your user data. The former gives the app a huge amount of control over your computer.
What exactly is so dangerous? Any app can take screenshots , listen to keyboard entries, send keys, move the mouse pointer and upload stuff to a server without any AXApi permission.
Forbidding window movement doesn't add any security at all.
Anyways, all I want a simple prompt explaining what the Accessibility API does and yes/no buttons.
The fact that any application can spoof the os password prompt makes me wonder why they don't have a prominent feature to show the prompt is from the OS. On windows there is the secure desktop with the dimming effect.
Note that that is not what that "effect" is for. It's not, strictly speaking, even an actual "effect". Windows is creating and attaching another "desktop" to your screen, and putting the dialog there. The alternate "desktop", the "Secure Desktop", is inaccessible from any other software on the computer, so a piece of malware can't say "Ask for permission to do blah, then find the 'Allow' button and click it" The "dim…
This is true, but in terms of how the user interacts with the dialog, they can more or less associate the dimmed background and Secure Desktop dialog box with a "from the OS" behaviour. This happens because as you said, the secure desktop is "inaccessible from any other software on [your] computer."
I don't actually know if I fully believe that. I haven't seen the internals of how it's implemented, but at the very least most users can assume that only the OS can bring up the prompt, and only the user can make it go away.
Is the "secure desktop with dimming effect" not spoofable?
Not really. Sure you can make a replica of it but it won't behave the same because you'll be able to minimize or close it but the secure desktop you can't do jack to until you either accept to decline whatever it's asking.
>you can make a replica of it but it won't behave the same because you'll be able to minimize or close it
but it would still achieve its purpose of phishing a root password
Great summary. But it's still some kind of hack. If every app I installed did this then my mac is closer to getting hacked. Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.
How's that any different compared to Linux? AFAIK apt packages can run arbitrary scripts as root.
No respectable package would put up a fake sudo prompt only to stash away your password for later use.
Non-clickbait title: "How Dropbox uses the root access that you give it during installation to give itself Accessibility authorization without triggering the usual popup".
Not exactly. If you remove dropbox from the accessibility auth list while the client is still running (without removing /Library/DropboxHelperTools) it just adds itself back in. Also it prompts for the password after installation.
So it's more like "how dropbox uses the root access you give it after installation to install software which will permanently re-add itself to accessibility even if you attempt remove its authorization".
They've been pretty good about accepting PRs to support any ad network from what I've heard: https://github.com/ampproject/amphtml/pulls?utf8=%E2%9C%93&q...
Yes, just as ABP has been good about accepting PRs to add "unobtrusive ads" - until they started demanding money. NEVER give this power to a central authority that's not democratically controlled. And yet, some people still do that mistake.
I agree that their current process should become more democratic, and that this is a real concern. There is also benefit in moving quickly to try and solve a real problem and prove that this approach will work. I'm still cautiously optimistic.
I was under the impression that the kernel extension was a separate product, it's being included in the standalone Dropbox application? You do have a point about giving it administrator privileges, the post however shows very clearly that they are abusing your trust which is enough for people to think twice before using their application..
What kernel extension? Dropbox has a Finder plugin for badges, but what would they need a kernel extension for?
Note that that is not what that "effect" is for. It's not, strictly speaking, even an actual "effect". Windows is creating and attaching another "desktop" to your screen, and putting the dialog there. The alternate "desktop", the "Secure Desktop", is inaccessible from any other software on the computer, so a piece of malware can't say "Ask for permission to do blah, then find the 'Allow' button and click it" The "dim…
This is true, but in terms of how the user interacts with the dialog, they can more or less associate the dimmed background and Secure Desktop dialog box with a "from the OS" behaviour. This happens because as you said, the secure desktop is "inaccessible from any other software on [your] computer." I don't actually know if I fully believe that. I haven't seen the internals of how it's implemented, but at the very le…
The very specific UAC one is secure, at least from anything that doesn't already have basically full control over your system, as it runs in the context of the SYSTEM account. The effect, and even much of the "alternate desktop", is trivial to reproduce, and is not as secure. One notable example is KeePass, which has an option to use a "Secure Desktop" for master password entry, but as it's done from the current user, is not secure against an attacker that understands what it's doing, though it will "bypass" a keylogger that's not designed to log "alternate desktop" interactions.