From 630e9ebd66dddbc6509147fe73f05a9376c77b8a Mon Sep 17 00:00:00 2001 From: Florian Bruhin Date: Sun, 23 Jul 2017 23:15:41 +0200 Subject: [PATCH] Remove old notes file --- doc/notes | 196 ------------------------------------------------------ 1 file changed, 196 deletions(-) delete mode 100644 doc/notes diff --git a/doc/notes b/doc/notes deleted file mode 100644 index 2261e3228..000000000 --- a/doc/notes +++ /dev/null @@ -1,196 +0,0 @@ -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