21–30 of 94 posts
Earlier quoted context omitted.
Looks like its getting the current time from the json response. How dare Google distribute the current time ?
The parent comment isn't talking about the payload being returned, it's about what domain Google is hosting user content on.
Earlier quoted context omitted.
It's a shame that it isnt easier to check for the correct hash on downloaded software. I know it's a one liner in the terminal, but that scares prople.
In KDE / Dolphin you can right click on a file, select 'properties' and then there is a tab for different checksums.
Earlier quoted context omitted.
Looks like its getting the current time from the json response. How dare Google distribute the current time ?
The point is that it's an arbitrary user submitted script. In this case it was just the time, but it could have easily been a botnet command and control message or some other malicious content. It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.
But it is being served under googleusercontent.com?
Doesn't fix the root cause, but could have caught it much sooner.
The standard macOS password prompt surely needs to change. It's become too familiar and I'm sure I've filled it in hastily before without wondering why or what for. It needs to be implemented in a way that is impossible for nefarious apps to replicate.
On Windows NT you had to press Ctrl-Alt-Delete at the login prompt because that was a key combination that no other application could intercept. Nowadays you work as a non-privileged user but then you have to enter your admin password in various dialog boxes with no way of knowing if its legit (sometimes ubuntu shows you an ugly-looking (i.e. wrong styled) gtk input dialog during updates. But only sometimes. Thats ve…
Earlier quoted context omitted.
Yes, should show the users login photo at the very least...
And maybe dim the background, as wel as giving information about the creator of the application and if its codesigned. oh wait, that was too obtrusive and annoying
For power users it's annoying and disruptive. For users that might benefit the most from it they quickly learn to press ok always whenever they are prompted for something, no matter what it's asking.
In my opinion, an ideal OS would have absolutly no confirmation dialogs what so ever, but instead it would have unlimited systemwide undo for any action. Look at Gmail vs Microsoft 360 webmail. One is a pleasure to use, the other a pain in the but. Some of that difference comes from dialogs and extra steps in 360 where GMail instead lets you undo.
Add powerful application isolation like in iOS, but make it as simple for the user to pass data between programs as it conceptually is to pipe text from one command to another in Unix, except that you shouldn't have to set up the pipeline first, instead you open a program work on something, pass it to another program work on it and so on. Each program also has an isolated location in the fs for persisting user data but since the only way for one program to access data from another program by the user explicitly sending it over, no application can access something it shouldn't have without the users interaction. So like iOS in that respect also. Of course the user can still be socially engineered into giving some data to a program that shouldn't have it but I don't think it could possibly be worse than what we have today.
There are a bunch of other problems and challenges also that I've not gotten around to consider, but I feel that an operating system like the one I described, if open source under an acceptable license (ISC, BSD, MIT or similar preferably) existed, I'd gladly throw away the portability advantages of POSIX in change for it.
Does the Mac have any ability to warn when someone attempts to install malicious software, other than the usual warnings about unsigned software? Windows 10, for example, will scan every attachment before opening it, catching a lot of stuff before it can do any harm.
Which is its own attack vector: https://news.ycombinator.com/item?id=14296959
If the user is about to execute a malicious file anyway, then scanning it before only adds protection.
Earlier quoted context omitted.
The parent comment isn't talking about the payload being returned, it's about what domain Google is hosting user content on.
The response from script.google.com is a 302 redirect to script.googleusercontent.com. IOW, google.com itself does not serve that user content.
It's not like users will accidentally type in script.google.com and get mad if it fails. Those script URLs are being used only by app developers, who will test their apps and fix script source URLs that are broken. Calling a googleusercontent script at google.com should return a 4xx status code telling them to use the googleusercontent domain.
Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.
Earlier quoted context omitted.
The response from script.google.com is a 302 redirect to script.googleusercontent.com. IOW, google.com itself does not serve that user content.
But why does Google redirect that? Why not just return an error? It's not like users will accidentally type in script.google.com and get mad if it fails. Those script URLs are being used only by app developers, who will test their apps and fix script source URLs that are broken. Calling a googleusercontent script at google.com should return a 4xx status code telling them to use the googleusercontent domain. Google.co…
I think you should read this again and then take a moment to think about the services people primarily visit google.com for.
Also, what exactly are "trusted domains"? Why do they matter to users clicking links?
On a website there's no way for an user to verify where a link is going to take them without actually clicking the link. The tooltip for example tends to be relatively easy to spoof.
This Handbrake outbreak could have been easily avoided. For instance, Handbrake could create a separate server on say, Amazon EC2 and have it download the file from their website every 30min or so, and check the checksum. If it's not right, then it flips a kill switch on the website. Doesn't fix the root cause, but could have caught it much sooner.