Re: [liberationtech] Browser extensions or native application for crypto? Was: Whiteout OpenPGP.js encrypted mail client (Chrome HML5 App)
Comments inline. Edwin On Thu, Jan 23, 2014 at 3:05 AM, Fabio Pietrosanti (naif) < li...@infosecurity.ch> wrote: > Let's try to get bit deeper in the comparison of the effective > vulnerability exposure window of a chrome browser extensions vs. native > application. > > My feeling is that chrome browser extensions are more secure than native > applications. > > > > > Il 1/22/14, 9:53 AM, Tony Arcieri ha scritto: > > > > It's true that native applications have wide-ranging capabilities that > > browser extensions don't. > Which kind of capabilities does natives applications, that browser > extensions doesn't provide within the context of encryption software? > For example, privileges separation using application sandbox, jail, LXC or various techniques are useful for writing secure software. I don't aware of any comparable technologies on Chrome App platform. > > > Where browser extensions can fall down is unexpected interactions with > > web pages and JavaScript running on them. This is a problem that > > native apps don't have because the browser is attempting to act as a > > sandbox, so escalating privilege from a JavaScript to access to native > > code execution is much more difficult than escalating privileges to > > interact with browser extensions unexpectedly. In this regard, native > > apps are superior, because the browser is trying to prevent that > > interaction from happening. Native apps are "airgapped" from web pages > > in a way browser extensions are not. > > In order to "attack" a client side application (being a browser > extension or a native one) you need to exploit a vulnerability in the > application itself. > > Browser extension could be hacked if they are unsafe, trough the use of > XSS-like attack techniques, by triggering an external payload into it > (for example from a website visited by the user). > Native applications could be hacked if they are unsafe, trough the use > of buffer/heap overflow like techniques, by triggering an external > exploit payload (for example by sending an email to a > thunderbird/enigmail target user). > Yes, both are vulnerable to various kinds of attacks. However, the browser itself is complex software, the interaction between different moving parts in a browser, e.g. extensions, plugins make it worse. Yes, OS is complex too, but browsers just add another complex layer on top of the OS. Complexity is the worst enemy of security. Native apps are superior in this aspect. > > Browser extensions, if exploited, provide less damage to the underlying > operating system and data due to the Browser Sandbox. > Native application, if exploited, provide access to all of the > underlying operating system an data. > Native apps can also be sandboxed. > > Browser extensions install and update securely trough the Chrome App > Store (Ok, it's a wallet guarden, but application are safely distributed) > Native applications (for windows for example) cannot be install > securely, unless following complex binary hashing verification and > comparison procedures that most users does not follow. > What do you think about the native apps App Store model of Apple, Google and Microsoft? The applications are signed and the system only allows applications signed by a trusted authority by default. > > Browser extensions can be run within a dedicated Chrome profile, that's > effectively a native sandboxing of the environment where the browser > extension run with it's additional layer of sandbox. > Native applications are more difficult to be sandboxed with such a > double layer, unless third party application sandboxing are used. > User system of modern OS is designed for this purpose. And you get a clearer separation between different users. > > So, my personal feeling is that chrome browser extensions can provide a > better secure environment for crypto applictions than the native ones. > > > -- > Fabio Pietrosanti (naif) > HERMES - Center for Transparency and Digital Human Rights > http://logioshermes.org - http://globaleaks.org - http://tor2web.org > > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?
Why is it better to limit our innovation to the existing standards when creating the nonexistent secure messaging system? Sometimes we could improve security of a system by adding layers to it, like HTTPS and ZRTP; sometimes hacking on a legacy protocol isn't good enough and we create new things. After all, even we just add a new layer to existing standards, we are creating new standards. While resemblance to existing protocol may boost software adoption, I don't see it is wrong to design a new protocol (having it based on existing one or not) and then make it a de facto/official standard. Edwin On Sat, Nov 9, 2013 at 12:56 AM, M. Fioretti wrote: > On Sat, Nov 09, 2013 09:37:27 AM +0100, Fabio Pietrosanti (naif) wrote: > > > All initiatiatives are trying to setup some new technological > > infrastructure, some new communication or encryption protocol. > > > > We MUST USE THE INTERNET STANDARDS, with modifications here and there, > > improving them, in order to reach our goal in securing asyncronous > > communications methods commonly referred as "Email". > > > > While i appreciate all of those cryptographer trying to do something > > new, i must say that THIS IS THE WRONG WAY! > > > > +100 :-) THANKS Fabio! > > Agree word by word with the whole message! > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Trsst: An Open and Secure Alternative to Twitter
I came across this project in kickstarter. Subscribers of this list may find it interesting. (Btw I am not associated with them) -- Welcome to Trsst: An Open and Secure Alternative to Twitter Post your thoughts, share links, and follow other interesting people or web sites, using the web or your mobile or any software of your choice. All of your private posts to individuals or friends and family are securely encrypted so that even your hosting provider - or government - can't unlock them. All of your public posts are digitally signed so you can prove that no one - and no government - modified or censored your writings. You control your identity and your posts and can move them to another site or hosting provider at any time. Think of Trsst as an RSS reader (and writer) that works like Twitter but built for the open web. The public stuff stays public and search-indexable, and the private stuff is encrypted and secured. Only you will hold your keys, so your hosting provider can't sell you out. http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o/description-- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Looking for collaborators for free-range voting project at Knight News Challenge:
I would argue that voting backed by re-countable physical paper is more reliable than pure electronic voting in an official election. However, I think that an electronic voting is still very useful under some specific situations. In Hong Kong, the Chief Execute are not elected by citizen through universal suffrage. The CE is instead chosen by a Election Committee consist of about a thousand of persons mainly appointed. The demands for an universal suffrage is clear, but the progress is hindered by the CCP of mainland China and the vested interests. On the 2012 CE election day, some people from the University of Hong Kong set up a mock poll, dubbed "civic referendum", to allow the citizen to express their views on the CE election. The mock is funded by public donations. The mock poll provided 15 physical polling stations, and online voting via its website and smartphone. However, shortly after the mock poll began, the online voting server were overwhelmed by huge amount of requests from attackers and legitimate voters. It completely brought down the online voting. Many people went to the physical stations, which may be far away from their home, to cast their vote. Despite the difficulties, a total of 222,990 votes are still casted in the physical stations and online voting combined. (http://en.wikipedia.org/wiki/Hong_Kong_Chief_Executive_election,_2012#Mock_polls) The goal of this "civic referendum" is never to officially elect the governor. By providing an unofficial election result which has higher creditability and legitimacy than the official result from the Election Committee, we hope to discredit the elected CE and the Election Committee, demonstrating the demand for a truth universal suffrage, and to push the democratic development forward. Because the mock poll is funded by the community, we have no way to set up enough physical voting stations and voter registry comparable to the election organized by the government. Indeed, it is difficult to prevent double voting in such "poor man's election". Some supporters of the CCP criticized the mock poll for lack of creditability with these reasons. Due to the lack of resource, internet voting might be one of the only means to allow most Hong Kong citizen to participate in a mock poll. What we need is a deployable solution to allow people to vote anonymously, either online or offline, at the same time provides enough creditability and verifiability. A perfect solution is not necessary because the goal isn't to replace the official paper votes. Edwin On Tue, Feb 26, 2013 at 6:49 AM, Joseph Lorenzo Hall wrote: > > (most of the statements I make below can be cited... holler if you want > some reading.) > > On Tue Feb 26 08:15:54 2013, Ruben Bloemgarten wrote: > > Irrespective of zombies et al. Voting requires the following basic > > elements : > > 1. verifiability when casting the vote, i.e. the voter can see that the > > vote that is cast will be the vote that is counted. This is not possible > > without a paper trail which is also a valid vote. > > This is a very complex topic, one that I've worked on for many years and > was the central them of my PhD thesis. I think it's important to > recognize that there are cryptographic voting systems that do verifiable > paperless voting. With out-of-band secret sharing, it gets most of the > way to what one would want to see... of course, the client-side malware > problem and the general problem of unsupervised voting (people voting > outside of an official location with polices that make sure only one > person enters the booth, etc.). > > As a member of the board of directors of the Verified Voting Foundation, > I should say that currently a paper trail backed by robust > "risk-limiting audits" are the state-of-the-art for governmental elections. > > > 2. Counting control. Each step of the electoral process has to be > > transparent for it to be valid. This means that *anyone* is allowed to > > observe the counting of the votes, *and* is able to understand that > > counting process. A printout of a result is not sufficient. Don´t forget > > that casting the vote is the least important of the process, counting > > the votes is. > > This is somewhat of a strawman... there is no way that one individual > can observe all the steps in an election as complicated as the ones we > regularly run in the U.S. (the U.S. is very strange compared to most > other countries in terms of the massive requirements we place on the > voting process... I would argue for very good public policy reasons). > This is why the academic literature on these kinds of topics > increasingly uses cryptographic auditing mechanisms to ensure that once > a valid ballot enters the system, it can be tracked. (And, believe it or > not, RFID-based inventory controls can do a lot.) > > > 3. Anonimity. There can not be any moment that a vote can be backtracked > > to the person voting. Again, this can not be based on "trusting a > > system". In many
