henk's thoughts =============== 1. Power to the user! Protect privacy! Things the browser should only do with explicit consent from the user, if applicable the user should be able to choose which protocol/host/port triplets to white/blacklist: - load/run executable code, like js, flash, java applets, ... (think NoScript) - requests to other domains, ports or using a different protocol than what the user requested (think RequestPolicy) - accept cookies - storing/saving/caching things, e.g. open tabs ("session"), cookies, page contents, browsing/download history, form data, ... - send referrer - disclose any (presence, type, version, settings, capabilities, etc.) information about OS, browser, installed fonts, plugins, addons, etc. 2. Be efficient! I tend to leave a lot of tabs open and nobody can deny that some websites simply suck, so the browser should, unless told otherwise by the user: - load tabs only when needed - run code in tabs only when needed, i.e. when the tab is currently being used/viewed (background tabs doing some JS magic even when they are not being used can create a lot of unnecessary load on the machine) - finish requests to the domain the user requested (e.g. www.example.org) before doing any requests to other subdomains (e.g. images.example.org) and finish those before doing requests to thirdparty domains (e.g. example.com) 3. Be stable! - one site should not make the complete browser crash, only that site's tab Upstream Bugs ============= - Web inspector is blank unless .hide()/.show() is called. Asked on SO: http://stackoverflow.com/q/23499159/2085149 TODO: Report to PyQt/Qt - Report some other crashes /u/angelic_sedition's thoughts ============================== Well support for greasemonkey scripts and bookmarklets/js (which was mentioned in the arch forum post) would be a big addition. What I've usually missed when using other vim-like browsers is things that allow for different settings and key bindings for different contexts. With that implemented I think I could switch to a lightweight browser (and believe me, I'd like to) for the most part and only use firefox when I needed downthemall or something. For example, I have different bindings based on tab position that are reloaded with a pentadactyl autocmd so that will take me to tab 1-10 if I'm in that range or 2-20 if I'm in that range. I have an autocmd that will run on completed downloads that passes the file path to a script that will open ranger in a floating window with that file cut (this is basically like using ranger to save files instead of the crappy gui popup). I also have a few bindings based on tabgroups. Tabgroups are a firefox feature, but I find them very useful for sorting things by topic so that only the tabs I'm interested at the moment are visible. Pentadactyl has a feature it calls groups. You can create a group that will activate for sites/urls that match a pattern with some regex support. This allows me, for example, to set up different (more convenient) bindings for zooming only on images. I'll never need use the equivalent of vim n (next text search match), so I can bind that to zoom. This allows setting up custom quickmarks/gotos using the same keys for different websites. For example, on reddit I have different g(some key) bindings to go to different subreddits. This can also be used to pass certain keys directly to the site (e.g. for use with RES). For sites that don't have modifiable bindings, I can use this with pentadactyl's feedkeys or xdotool to create my own custom bindings. I even have a binding that will call out to bash script with different arguments depending on the site to download an image or an image gallery depending on the site (in some cases passing the url to some cli program). I've also noticed the lack of completion. For example, on "o" pentadactyl will show sites (e.g. from history) that can be completed. I think I've been spoiled by pentadactyl having completion for just about everything. suckless surf ML post ===================== From: Ben Woolley Date: Wed, 7 Jan 2015 18:29:25 -0800 Hi all, This patch is a bit of a beast for surf. It is intended to be applied after the disk cache patch. It breaks some internal interfaces, so it could conflict with other patches. I have been wanting a browser to implement a complete same-origin policy, and have been investigating how to do this in various browsers for many months. When I saw how surf opened new windows in a separate process, and was so simple, I knew I could do it quickly. Over the last two weeks, I have been developing this implementation on surf. The basic idea is to prevent browser-based tracking as you browse from site to site, or origin to origin. By "origin" domain, I mean the "first-party" domain, the domain normally in the location bar (of the typical browser interface). Each origin domain effectively gets its own browser profile, and a browser process only ever deals with one origin domain at a time. This isolates origins vertically, preventing cookies, disk cache, memory cache, and window.name vulnerabilities. Basically, all known vulnerabilities that google and Mozilla cite as counter-examples when they explain why they haven't disabled third-party cookies yet. When you are on msnbc.com, the tracking pixels will be stored in a cookie file for msnbc.com. When you go to cnn.com, the tracking pixels will be stored in a cookie file for cnn.com. You will not be tracked between them. However, third-party cookies, and the caching of third party resources will still work, but they will be isolated between origin domains. Instead of blocking cookies and cache entries, they are "double-keyed", or *also* keyed by origin. There is a unidirectional communication channel, however, from one origin to the next, through navigation from one origin to the next. That is, the query string is passed from one origin to the next, and may embed identifiers. One example is an affiliate link that identifies where the lead came from. I have implemented what I call "horizontal isolation", in the form of an "Origin Crossing Gate". Whenever you follow a link to a new domain, or even are just redirected to a new domain, a new window/tab is opened, and passed the referring origin via -R. The page passed to -O, for example -O originprompt.html, is an HTML page that is loaded in the new origin's context. That page tells you the origin you were on, the new origin, and the full link, and you can decide to go just to the new origin, or go to the full URL, after reviewing it for tracking data. Also, you may click links that store your trust of that relationship with various expiration times, the same way you would trust geolocation requests for a particular origin for a period of time. The database used is actually the new origin's cookie file. Since the origin prompt is loaded in the new origin's context, I can set a cookie on behalf of the new origin. The expiration time of the trust is the expiration time of the cookie. The cookie implementation in webkit automatically expires the trust as part of how cookies work. Each time you cross an origin, the origin crossing page checks the cookie to see if trust is still established. If so, it will use window.location.replace() to continue on automatically. The initial page renders blank until the trust is invalidated, in which case the content of the gate is made visible. However, the new origin is technically able to mess with those cookies, so a website could set trust for an origin crossing. I have addressed that by hashing the key with a salt, and setting the real expiration time as the value, along with an HMAC to verify the contents of the value. If the cookie is messed with in any way, the trust will be disabled, and the prompt will appear again. So it has a fail-safe function. I know it seems a bit convoluted, but it just started out as a nice little rabbit hole, and I just wanted to get something workable. At first I thought using the cookie expiration time was convenient, but then when I realized that I needed to protect the cookie, things got a bit hairy. But it works. Each profile is, by default, stored in ~/.surf/origins/$origin/ The interesting side effect is that if there is a problem where a website relies on the cross-site cookie vulnerability to make a connection, you can simply make a symbolic link from one origin folder to another, and they will share the same profile. And if you want to delete cookies and/or cache for a particular origin, you just rm -rf the origin's profile folder, and don't have to interfere with your other sites that are working just fine. One thing I don't handle are cross-origins POSTs. They just end up as GET requests right now. I intend to do something about that, but I haven't figured that out yet. I have only been using this functionality for a few days myself, so I have absolutely no feedback yet. I wanted to provide the first implementation of the management of identity as a system resource the same way that things like geolocation, camera, and microphone resources are managed in browsers and mobile apps. Currently, Mozilla and Tor have are working on third-party tracking issues in Firefox. https://blog.mozilla.org/privacy/2014/11/10/introducing-polaris-privacy-initiative-to-accelerate-user-focused-privacy-online/ Up to this point, Tor has provided a patch that double-keys cookies with the origin domain, but no other progress is visible. I have seen no discussion of how horizontal isolation is supposed to happen, and I wanted to show people that it can be done, and this is one way it can be done, and to compel the other browser makers to catch up, and hopefully the community can work toward a standard *without* the tracking loopholes, by showing people what a *complete* solution looks like. Thank you, Ben Woolley Patch: http://lists.suckless.org/dev/att-25070/0005-same-origin-policy.patch