(no commit message)
[ikiwiki.git] / doc / bugs / do_not_let_big_brother_spy_on_our_users_on_login.mdwn
1 In the login page, the icons of:
2
3  * livejournal.com
4  * myopenid.com - which is [closing](http://tech.slashdot.org/story/13/09/04/228229/myopenid-to-shut-down-in-february)
5  * verisign.com
6  * yahoo.com
7  * aol.com
8  * claimid.com
9  * flickr.com - which should be the same as yahoo
10  * wordpress.com
11  * google.com
12
13 ... are all hotlinked. Which means that on every ikiwiki out there, whenever someone logs in, the web browser of that person actually report backs to all those entities, some of which are known to collaborate with the US government in illegal spying of american citizens and, well, the world at large (see [[!wikipedia PRISM]], but also the patriot act and various warrantless wiretapping provisions established since 2001).
14
15 In the old days, we used to call those [[!wikipedia web bugs]]. Nowadays, they seem so pervasive that we don't even notice. Nevertheless, I think it would be important to remove those snitches from the ikiwiki home page.
16
17 A simple fix would be to ship those icons with ikiwiki and serve them locally, but there may be legal issues with redistributing those icons in the source code... Would it be covered by fair use? The [upstream library](https://code.google.com/p/openid-selector/) doesn't actually exhibit that problem, and ships those icons directly as a [PNG sprite](https://code.google.com/p/openid-selector/source/browse/#svn%2Ftrunk%2Fimages). -- [[anarcat]]
18
19 > it's not exactly about OpenID, but the german heise newspaper group has
20 > switched away from directly including like/+1 buttons on their websites, and
21 > replaced them with locally hosted buttons which have to be clicked once to
22 > enable the buttons themselves and a second time to effect anything.
23 > [here's the article](http://www.h-online.com/features/Two-clicks-for-more-privacy-1783256.html).
24 > they've had [trouble with facebook (german)](http://www.heise.de/newsticker/meldung/Facebook-beschwert-sich-ueber-datenschutzfreundlichen-2-Klick-Button-2-Update-1335658.html)
25 > -- <abbr title="too long, didn't translate">tl;dt</abbr>: facebook complained
26 > about them using their "like"-button logo for something that's not a like
27 > button, they replaced the whole facebook logo there with a plain-text "F" (as
28 > you see on the bottom of the page). google's +1 seems not to have been an
29 > issue. i assume it will need case-by-case decisions to fully comply with all
30 > legal stuff involved. (from a practical point of view, things are not that
31 > strict, as `apt-file find facebook.png` and `apt-file find flickr.png`
32 > reveal.) --[[chrysn]]
33
34 >> The fundamental problem here is that we want to balance these
35 >> somewhat incompatible goals:
36 >>
37 >> * show users a provider icon that they'll recognise at a glance
38 >> * don't infringe copyright
39 >> * don't distribute non-DFSG-licensed things in the source package
40 >> * don't let miscellaneous OpenID providers track our users
41 >>
42 >> A "quick hack" version of removing these would be to have an option to
43 >> disable the friendly JavaScript OpenID selector and go back to a simple
44 >> input box. I might implement that option anyway - on websites mainly used
45 >> by technologists, the OpenID selector is a bit of a waste of time.
46 >>
47 >> One way to have recognisable icons would be to ship DFSG imitations of
48 >> the "real" logos in the underlay. Between gnome-online-accounts and
49 >> Empathy, we can probably find most of them (mostly or perhaps all done by
50 >> Jakub Steiner).
51 >>
52 >> If people want the "real" logos, we could have some code to make IkiWiki
53 >> download the favicons into transient underlay (which I think is
54 >> higher-priority?), or into a higher-priority underlay if necessary,
55 >> during the wiki build, so they'll be served from the wiki's own server.
56 >>
57 >> --[[smcv]]