"The Skype Security Policy is: ... 4. Messages transmitted through a Skype session are encrypted from Skype-end to Skype-end. No intermediary node, if any exist, has access to the meaning of these messages. [1]"

[1]: http://download.skype.com/share/security/2005-031%20security...

Aforementioned referenced on + additonal security overview/facade: http://www.skype.com/en/security/#encryption

Their hybrid peer-to-peer/client–server implementation allows for eavesdropping. This is now confirmed to be in practice.

http://www.skype.com/en/legal/privacy/#retentionOfPersonalDa...

(this apparently does not apply to voice calls, but either does the complaint that they are picking up URLs and visiting them).

One is a feature designed to allow them to check URLs, fetch thumbnails, etc. The other is a very pivotal core decision in how Skype works.

Skype has always been primarily node-to-node. Doing p2p connections like that required signaling/directory services. In the past, users' computers were used for that functionality. After their purchase, Microsoft transitioned those signaling/directory services to the cloud.

At worst, this gives Microsoft the ability to see who is calling who, I'll grant that. Worst case scenario, you can't negotiate via STUN and UDP hole punching or UPnP port forwarding, then you will get stuck with TURN and that will route through Microsoft's servers.

So, unless someone has proof of a connection that should have established peer-to-peer and instead the call itself was routed through MS's servers TURN style.... then can we ALL please stop repeating this obnoxious rumor about MS eavesdropping on all Skype calls. Or worse yet tying it to some URL lookup service?

It may currently be for innocent purposes (check URLs, thumbnails etc as you said). However the fact is that they can make these requests at all show that the encryption is not end-to-end, otherwise they wouldn't know the URL to make a request to at all! The request isn't being made from the client, the IP shows it comes from Microsoft's servers.

So, you're talking about voice, but this is proof that the textual chat connection that should be secure end-to-end is decrypted and routed through Microsoft's servers.

I'll also continue to say how extremely disappointed I am that none of the major IM players (not Google, not Apple, not Microsoft, not Yahoo, not Facebook) wants to implement OTR encryption in their chat apps. Google even removed their fake "OTR" from the new Hangouts app, which I believe only hid your logs from yourself, not from Google themselves.

[1] - http://www.nytimes.com/2013/05/17/business/concerns-arise-on...

I was thinking about MTUA, mail, crypto/privacy and bitsync yesterday and was wondering if there could be a new mail system that would be encrypted and decentralized by default (à la bitsync/bittorrent).

Bitmessage seems to closely match what I had in mind.

Call metadata like to/from, time, and call length are stored - as is all text.

Gentlemen don't read each others mail.

While it's technically possible it's not the norm and it's hard to come up with examples of services that actually do make this promise - tarsnap is one that comes to mind.

While both Skype and Gmail store your messages (if you Skype across multiple devices, you'll see logs of conversations that happened on different devices), I don't think Gmail probes every URL you send in your messages. Also, SMTP is not always done under SSL, so, privacy cannot be assured.

But that's easily testable. I'll get back to you in a couple hours.

One automatically scans your email to show related ads, another does a HTTP HEAD request to URLs for only the server headers, which they say is for malware scanning purposes. Both are automated jobs.

See my other post to see how Google employees have access to all your email, documents, chat transcripts, Google Voice calls, Youtube videos etc. and how a few abused it to stalk teens.

https://news.ycombinator.com/item?id=5728707

As usual, Google gets a free pass and Microsoft gets demonized(they should stop claiming it's end to end encrypted, though). Looking at your HN profile, it's not hard to understand why. Thanks for being honest about disliking Microsoft but please try not to let that color your objective opinions and playing favorites regardless of facts.

If they just use it the same way that google uses gmail I fail to see the problem.

(Honestly, if you'd just asked, I would have been assumed this would have been the case anyway)

Add this to the 1,000,000 other reasons why you should never use GET requests for authentication/verification.

GET issues are primarily related to the fact that an attacker can automate their access. So they could trick a user into going to a specially crafted site, and then request content on that user's behalf via GET forgery, and return it to the web-server you control.

It is very convenient, but fairly insecure.

Sharepoint, DropBox, Owncloud, LogMeIn, Flickr, Google Docs, et al.

Private/one-time-use URLs have been a "thing" since practically forever and they're all over the place.

Would anyone here use a WebRTC-based service that also encrypted the file in transit, thus making it pretty hard for anyone other than the recipients to see it?

Then you have to give the URL to the recipient (over a secure channel), but the app will optionally allow you to not automatically send the file, but tell you how many people are connected (e.g. if there are two when you're expecting one) and begin transfer manually.

Also, I'm planning to make it all a single HTML file so you can download/verify it and store it somewhere to use whenever you like.

Of course, Skype's bot won't implement WebRTC.

They'll implement the proprietary blend that they told no one they were working on until everyone else was making serious progress with the implementation that everyone else collaborated on...

http://html5labs.interoperabilitybridges.com/prototypes/cu-r... [hm, they've actually put some money where their proposal is, I'll have to check into this more]

Obviously it's not going to be secure against coordinated attacks by governments (which I will also make clear), but my intention is to have it be secure enough for 99% of people while being easy to use. It'll at least be more secure than Dropbox/Box/Skype/whatever, which aren't secure in the slightest.

Mega, for example, might be secure, but I haven't personally seen their implementation, don't trust them not to implement any backdoors, and don't trust them not to change it. I'm aiming to make mine as small as possible, so you can verify it at pretty much a glance.