[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5273 [Firefox Patch Issues]: Update TBB design doc for 2.3.x-alpha
#5273: Update TBB design doc for 2.3.x-alpha
----------------------------------+-----------------------------------------
Reporter: mikeperry | Owner: mikeperry
Type: defect | Status: new
Priority: major | Milestone: TorBrowserBundle 2.3.x-stable
Component: Firefox Patch Issues | Version:
Keywords: MikePerry201207 | Parent:
Points: | Actualpoints:
----------------------------------+-----------------------------------------
Comment(by mikeperry):
Replying to [comment:18 gk]:
> > I also expect that certain sites will have homogenous requirements wrt
ad blockers and plugins/media because people will naturally decide that
those sites suck in similar ways... But perhaps that is a poor assumption?
If so, please explain how/why?
>
> Don't know yet as I am not sure whether I understand you correctly. What
do you mean with "homogenous requirements wrt ad blockers and
plugins/media" and how does this fit to the issue whether site-based
options for adblockers etc. or no options at all should be implemented in
the default TBB?
Well, I think certain sites are going to cause similar choices by the
userbase. Consider YouTube. Clicking through the barriers for every video
there is annoying (and sometimes breaks random videos), but disabling the
clickthroughs globally is a fingerprinting vector and also a large
security risk. Similar situations exist for adblockers... Some sites have
obnoxious advertising and rather than let this drive users to install
Adblock Plus for *all* sites, we can provide them with a permission for
the specific site that annoys them...
However, both of those points assumes that the majority of the userbase
will successfully navigate the Privacy UI...
Wrt to the Beggar's Header, I am very tempted to remove it from the Tor
Browser UI entirely.. As a compromise, I was toying with the idea of
removing it from the usual location but providing the per-site context
menu... But yeah, perhaps we don't give a damn about providing even that,
and should just go out of our way to kill the stupid thing.
> > As a general matter, I prefer allowing user choice if possible, but it
also seems clear that user choice for global behaviors is really, really
bad... Allowing easy access to per-site choices would be way better by
comparison...
>
> Choice is good but do users really want to have per site choices
regarding ad-trackers and DNT? What makes you believe so? And why does
that not already exist as an add-on and all anti-tracker add-ons are
working globally (at least all I can currently come up with)? If there is
even a tiny demand for a specific wish there usually seems to exist an
add-on for it on AMO.
Yeah, that's exactly the scenario I want to avoid. We should add
warnings/text in the addon store UI that tells the user that addons can
harm privacy and anonymity... Since Adblock Plus is the most popular addon
in the world, supporting some form of user choice per-site might be a
decent compromise? It might prevent the userbase from fragmenting itself
globally.. It's a tricky tradeoff, though.
At any rate, the key thing I want to communicate with the context menu is
that all of the global privacy options that alter browser behavior need to
be in a per-site menu (if they exist at all), rather than global choices.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5273#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs