"The insertion is done when we have received a response from Google servers"
But GMelius is a client-side application, right? According to your whitepaper, the insertion is done when the _client_ receives the response, I don't see anything about validation from the GMelius servers to GMail.
"SHA-512"
It's not the SHA part which is the problem, it's the RSA part. 512-bit RSA is well-known to be broken and there have already been multiple exploits. 2048 bits is the bare minimum anyone should use nowadays.
All the logic happens at the back-end level via our API communicating with Gmail's one. Nothing is done on the client-side (i.e., extension) besides the integration of our buttons/features within Gmail's UI.
The RSA key is just used to show that what has been inserted was through our service. Note that the final hash resulting from the mixer is done without any RSA.
Hi vivan. Thanks for your comment. Besides the signature of an email using the robustness and persistence of the blockchain, what is different with "Email Stamping" and especially interesting for professionals who send sensitive emails (e.g., lawyers, insurers, brokers...) is that they have a way to show they sent an email with a specific content at a specific time.
A decisive challenge raised by today’s email dominance in the workplace is that the latter means of communication does not offer a built-in function to prove the integrity and authenticity neither of its content nor of its origin. Knowing that emails are increasingly presented as legal evidence in courts worldwide, it becomes urgent to think of approaches that could palliate the inherent flaws of email.
EDIT: And yes, Gmelius offers a lightweight CRM targeting SMEs that covers all the stages of the modern communication flow: from the first interaction to the potential signature of a contract/quote. Besides, Gmelius offers a shared inbox making possible to follow-up on leads, stay in sync with your team.
How does that prove the email was sent, though? Couldn't one timestamp the email into the blockchain, without actually sending the email to the other party?
Edit: btw, I released something that utilizes bitcoin's blockchain for timestamping back in 2013: https://news.ycombinator.com/item?id=5790382 (the website is no longer available because better solutions came since, but its up on github[0] and the wayback machine[1])
This has some interesting use-cases, but people tend to overestimate what blockchain timestmaping actually gets you. You can prove that some piece of data existed at some point in time, but that's it. It doesn't prove this data is authentic, that this data was communicated to anyone, that no one else timestamped this data earlier, etc.
So you're acting as a trusted party to get delivery confirmations from Google? What if Google doesn't confirm delivery, but you decide to write to the blockchain anyway?
Also, won't Google servers return a cryptographically verifiable delivery confirmation? If so, couldn't this be used as the delivery proof directly instead?
Yes, we integrate with Gmail and communicate via the official Gmail API.
We only receive response statuses and act accordingly. Moreover, we think it's important for this functionality to make sense to insert the hash corresponding to the integrity of the email, and so make possible for our customers to "prove" they have indeed sent an email with a specific body/subject/...
Well, doesn't that mean that the security model is based on you acting as trusted third party and relying on you to only write truthful data to the blockchain?
In other words, the delivery proof is not based on trusting the blockchain mechanics, its based on trusting Gmelius Ltd.
EDIT: reply to your last comment. The whole idea is to propose a "hybrid" architecture that bridges the gap between a centralized technology such as the Email with the benefits of a decentralized one, the blockchain.
This hybrid process implies you will need to trust parties at some points, e.g., Google and Gmelius. However, the point here is to offer a means to store in a robust way the trace that a specific email communication existed at a point in time, including its context/content.
Hi! Regarding your tracking remark, companies such as YesWare, MailTrack, MixMax (and so on) use pixel trackers. While such trackers are indeed made available through a Google proxy, the caching is overridable if you pass a no-cache header (http://blog.movableink.com/real-time-content-and-re-open-tra...).
The Inbox SDK makes easier the interaction with Gmail's UI and does not transmit or index data.
Thanks for your comment. When a user enables the feature that homogenizes the look of incoming emails w.r.t. its Gmail theme, Gmelius will not modify the style of well-formatted HTML emails (e.g., invoices, newsletters, etc.).
In addition to our "email scheduling" feature, email follow-ups and reminders will be soon available as well. With the latter features and other ones Gmelius currently offers (e.g., To-do App, email trackers detection and blocking, email templates), I'm sure your will find a place for Gmelius in your browser...
"They both supply email tracking, and protect your privacy by blocking email tracking."
> This is mainly offered to prevent false positives for our own trackers. But point taken :)
"It doesn't prove that the email has been sent, it just proves that it has been submitted to Gmelius for signing."
> The insertion is done when we have received a response from Google servers.
"SHA-512"
> Long debate but this was the most natural solution for a Merkle architecture.