Comment No, sorry (Score 1) 576
Nope it's too late - they are already here having strategically taken over Comcasts call center in a bid to drive us off the planet.
Nope it's too late - they are already here having strategically taken over Comcasts call center in a bid to drive us off the planet.
Let me be the first to say that Yandex sounds like a bunch of whiny losers if this is their comparison. Google isn't imposing anti-competitive contracts on OEMs and using secret APIs to give their products a home turf advantage. They've open sourced the entire OS and most of the problems getting a competing product on an Android device is due to OEM malfeasance.
Google play services are not open source and whose APIs are by design required to run an increasing number of Apps. Google play services are available for bundling exclusively at Googles pleasure on their terms.
If you don't have Google play not only is the Google appstore unavailable multiple Google services integrating with Google play services are also unavailable to you.
If Microsoft had competed with Be and Netscape back then like this, I'd be running Firefox on BeOS R10.5 not Windows 7.
They are clearly leveraging their position to enforce artificial dependencies and behaviors favorable to themselves just like Micro$oft did years ago and just like Microsoft it's all closed source.
Except there isn't anything to indicate that Google is actually spying on you when you use their internet service.
This would be redundant. Virtually every website on the planet already reports to Google for one reason or another.
SCP moves one file. SSH doesn't move any. RDP makes every file the target has access to directly accessible as a file share on the client even if you don't want it to.
CryptoLocker running on the client wouldn't have seen the files the target could access at all had the connection been VNC, X, or ssh.
So this is just a security by obscurity play. The assertion is since a particular instance of malware lacks a feature set enabling it to detect and subvert SSH connections from a compromised client then SSH is more secure than RDP even though both offer functionally equivalent access.
Sounds like all the wrong lessons have been learned from this security breach.
Also worth noting RDP maps the clients local resources to remote server not the other way around.
Wow, you are desperately working to miss it!
Right back at ya.
The file sharing that allowed the nasty on the remote terminal to get at the fileserver was not required and was not part of the reason for allowing that RDP connection. But it was there because RDP in the wild overshares by default.
SSH and X don't tend to overshare by default. You can do port redirection, but only by explicitly asking for it.
Can you explain the difference between a share allowed with an RDP connection and the use of SCP over SSH which is enabled and allowed by default?
If you own the client and the client logs on to something it would seem to me this is game over you must assume everything the client has access was compromised unless you have reason to believe otherwise... as we already know SSH provides file system access by default to all clients. I'm failing to comprehend the difference.
Did you invent RDP or something? You'll break your back bending that far backwards to absolve it of the incident I wrote about.
I fail to understand how the repercussions of social engineering attacks are the fault of a remote access technology unrelated to initial compromise.
Especially given root cause from your story seems to be acceptance followed by execution of unauthenticated, untrusted messages.
You CAN do that with ssh but it's far from the default setting.
Name a popular Linux distro which fails to enable ssh, port redirect and scp by default. I dare you to name one.
suse, debian, ubuntu, fedora, centos all DEFAULT setting. Every unix system I've ever used or connected to in the past decade offers port redirect and file system access via ssh.
Yes, it presents hazards never even dreamed of by X or VNC.
X has always been a breathtaking hazard for reasons entirely the fault of X.
In one case I know of (no, I am bound to not name names here), RDP was a vector for a CryptoLocker attack. A reasonably secure operation (AV on email, IDS, strong user training, etc) granted an outside support person a
AV and IDS are worthless against targeted attacks.
temporary RDP connection to diagnose a problem. It seems the support person opened a bad email on his own machine while connected and CryptoLocker took advantage of the RDP forwarded file shares to encrypt the fileserver.
You can do the same with SSH.
Personally I'm looking forward to the shit storm of global, coordinated backlash against TPP when the politicians are done jerking off.
More importantly those VPN logs are subject to seizure by law enforcement with the appropriate warrant or other legal instrument deemed valid by the Government and the Courts of Law. Show me a VPN service provider that is not subject to lawful access by law enforcement.
I wish that were true. Given US government track record of obtaining everyone's call records without any legal showing the more likely scenario is warrantless seizure of "any tangible thing" justified by invoking 3rd party doctrine or batshit insane abuse of Article II.
... https everywhere, constant VPNs and full encryption for everything...
Trivially blocked by your service provider. This continuing single point of failure is the obstacle to overcome. Not much can be accomplished before then.
I invite them to try. Commercial companies which exist to make money can't just block something everyone uses and expect to remain a viable company with paying customers.
Everywhere I look people still blissfully using completely insecure authentication methods for VPN access effectively broadcasting plaintext passwords to anyone snooping the wire... but hey at least if someone tricks you into connecting to their evil network Microsoft has your back.
Would love an education how this bug is worthy of mention while other much more egregious issues such as true type vulnerabilities affecting anyone who browses to an attacker controlled website were also patched.
Hard to believe such a racist comment is posted from an account with positive karma, but even harder to believe this has been upvoted. WTF??
Hard to believe people still feed trolls.
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
What happens if you POST to a server and the response is lost? How does client know it was processed or not? The answer is you always need some kind of id/token/big word because non-idempotwhatever is not actually possible.
The only thing POST is... is worthless... defective by design without specific and unnecessary application logic to deal with consequences of HTTP's total lack of a commitment procedure.
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
Like the rest of HTTP it is perfectly useless. No coherency nor atomicity nor any way to implement verbs beyond trivial "CRUD".
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response.
Why is returning a pointer to data allowed while returning actual data itself not? This just sounds like bullshit.
Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
Or you can just return data and stop being silly.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
It always is... I'll leave failure to communicate a coherent use case to speak for itself.
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
But what is the point?
Yep that sounds correct. That is the entire point of GET and POST being different.
GET retrieves data, never alters it. POST alters data, never retrieves it.
Both assertions are false.
This is kinda HTTP 101. You might disagree, but then you'd be doing it wrong.
LOL if you disagree with me your doing it wrong. No arguing that.
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
HTTP is a dull rusty blade attached to a termite infested rotted, split, splintered handle yet it is the only axe left in the world and the only way to cut down trees.
It is unwise to attempt to use it properly as "intended" you will just break it and or injure yourself.
Instructions included with moldy packaging the axe originally came in is only a useful as a reminder of old times before our Alien overlords swooped down from the sky and stole all of the worlds axes except one their computer failed to recognize as an axe.
The computer is to the information industry roughly what the central power station is to the electrical industry. -- Peter Drucker
