Re: [tor-bugs] #4280 [Tor Browser]: build changes for TBB

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#4280: build changes for TBB
-------------------------+--------------------------------------------------
 Reporter:  ioerror      |          Owner:  mikeperry
     Type:  defect       |         Status:  new      
 Priority:  normal       |      Milestone:           
Component:  Tor Browser  |        Version:           
 Keywords:               |         Parent:           
   Points:               |   Actualpoints:           
-------------------------+--------------------------------------------------

Comment(by ioerror):

 Replying to [comment:3 mikeperry]:
 > Replying to [comment:2 ioerror]:
 > > Replying to [comment:1 mikeperry]:
 > > > Disabling everything in two places just makes our job harder if we
 want to use that functionality later, or if users insist on testing new
 and exciting configurations for us.
 > >
 > > I disagree that it makes our job harder. We have experimental builds
 for experiments and we have stable builds for stability, security and
 anonymity.
 >
 > It does in fact make it harder. You just haven't been active enough in
 TBB development to see it.
 >

 Ok, I won't argue that it's harder as that's clearly subjective. I've been
 involved with TBB for many years and I agree that lately, I've been
 watching development more than anything else. However, I strongly feel
 like shipping gobs of stuff that we don't support or use is a bad idea. It
 seems like you need an explicit design goal (and perhaps I missed it ) of
 "stay as close to Firefox as possible" for all things above anything else.

 > Just dealing with all the places we have disabled flash was a huge pain.
 It took us 3 or 4 builds to get flash loading again on all platforms. And
 I still can't figure out all the ways we prevent cookies from being
 written to disk so that users who want to store protected cookies can do
 so.
 >

 That's an argument for no Flash but I hear your point.

 > Every change we make to disable something requires everyone knowing
 about it and all other changes when they want to undo them to add
 features.
 >

 Yeah, forking a browser is a nightmare, I get it. That's why we need to
 document, work for minimal changes, decide what we support and so on.

 > We also don't currently have experimental TBB builds... Making them
 always behave differently (as opposed to just working on them until we can
 call them stable) is more work and maintenance. It will also introduce fun
 surprises due to differences between "stable" and "experimental" behavior
 when we try to convert out alpha "experimental" series into the new
 "stable".
 >

 I guess I mean alpha when I said experimental.

 > > According to the docs, I see no reason to enable those flags. YMMV. I
 think it's worth considering.
 >
 > My vote is for only:
 > +ac_add_options --enable-install-strip
 > +ac_add_options --disable-parental-controls
 >

 That's plus one - we already had strip, I believe.

 > This one needs code review to ensure it doesn't break stuff/disable all
 caching:
 > +ac_add_options --disable-necko-disk-cache

 Agreed.

 >
 > These two will probably make my life harder for #4234:
 > +ac_add_options --disable-installer
 > +ac_add_options --disable-updater
 >

 Ok, seems like not using those is fine.

 > The others are just bad ideas that will break stuff for no gain, IMO.
 >
 > In fact, I'm not even sure any of these are really worth it, unless they
 actually save us significant disk space in the .dmg or tgz.

 That's a reason to test - I think Erinn is be suited to tell us this? I
 mean, if it shaves off say, 5MB - is it worth it? I think so.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4280#comment:4>
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