flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Package, Class and Method renaming
Date Mon, 07 Aug 2017 15:05:37 GMT

> On Aug 7, 2017, at 5:52 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
> GCC has some static flow analysis, so yes, they can detect unused
> functions, but I don't think it can detect bracket access to functions any
> better than bracket access to properties, both of which are allowed in AS
> and JS.

Yes. I realize this. I’m having trouble envisioning a way of generalizing automatic avoidance
of @exporting.

> FalconJX doesn't call GCC on the command line.  It uses a Java API.  I
> think I've seen APIs that are probably what the property map does.  The
> question remain about how to determine what to put in the list.

I was thinking of a hand-crafted list. goog can dump a list of all properties and the list
can be edited.

> MXML does use dynamic/bracket access, but it should be putting the whole
> property name in the file.  I have not investigated as to how GCC handles
> that and whether those strings are mapped to a variable and the MXML data
> array is updated with the variable, or if there is a way to tell GCC that
> once a string is seen anywhere, then don't rename anything using that
> string.  But if you want higher levels of obfuscation then we would want
> to rename those properties as well, and potentially even tell data binding
> to use the new property name.

Yes. Possibly.

> I think it is all possible, it is just a matter of time and priorities.
> Are you thinking you can't deploy without better obfuscation?

I don’t think I can deploy to the public without obfuscation. Our first stage is to make
it available to partners. That I think I can do without obfuscation.

My fallback is probably a script which will do find/replaces on the minified code. It’ll
probably be tedious to construct the script, but doable. In the meantime, I’ve been examining
my minified code for places where the source can be better constructed to output better minified
code. That’s where the thought of using the set__ and get__ functions came from.


> -Alex
> On 8/7/17, 2:56 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>> Yishay came across this post:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackover
>> flow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optimi
>> zations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1b
>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9FhZ
>> drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove
>> rflow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optim
>> izations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1
>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9Fh
>> ZdrheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0>
>> I wonder if there’s some way to use the property_map options to control
>> renaming. My guess is that it would only work if @export is not used.
>> Related to this general topic:
>> I realized that goog is much better at minifying functions than
>> properties. That makes sense because you can reliably point to functions
>> using references. Referencing variables is not reliable because the
>> references can end up pointing to different values.
>> Theoretically, getters and setters could be better for that. The problem
>> is that goog treats the getters like variables. If the compiler would
>> rewrite getter and setter access to the underlying getter and setter
>> functions, goog could probably do a better job optimizing those. (i.e.
>> instead of foo.baz = “baz”, Falcon could write foo.set__baz(“baz”) and
>> var baz  = foo.baz could become var baz = foo.get__baz())
>> Harbs
>>> On Aug 7, 2017, at 9:56 AM, Harbs <harbs.lists@gmail.com> wrote:
>>> Another case which seems to need exports is any property used in MXML.
>>> It seems like the low hanging fruit would be to allow some kind of
>>> markup to specify classes which don’t need exports.
>>> Rewriting constants to literals is another one which should be pretty
>>> easy to solve.
>>>> On Aug 7, 2017, at 9:24 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>> wrote:
>>>> Dynamic access (aka square bracket access) is used in data binding, but
>>>> people use it for other things as well.  The really hard case involves
>>>> "string math" where you access something like foo[someValue + "label"].
>>>> It is hard to know that "enUSLabel" and "frFRLabel" should not be
>>>> renamed.
>>>> And yes, modules will need to find APIs in other modules or the host
>>>> and
>>>> renaming is a problem there too.
>>>> But I'll bet that only a small fraction of APIs should not be renamed
>>>> in
>>>> any typical app, especially if no modules are in play.  The question is
>>>> "which ones"?  But if we can make it possible, it should be a good
>>>> obfuscator as well.
>>>> My 2 cents,
>>>> -Alex
>>>> On 8/6/17, 10:57 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>> I’m fuzzy on all the reasons for using @import so much.
>>>>> We’ve had discussions on the topic, but hey were spread out.
>>>>> The reasons that stick in my mind was for bracketed access (needed for
>>>>> binding?) and reflection. Another reason I think that was mentioned
>>>>> was
>>>>> for modules (which we don't’ yet really have a way to use).
>>>>> Is that it?
>>>>>> On Aug 7, 2017, at 8:34 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>>>> wrote:
>>>>>> It might be more interesting and fruitful to investigate removing
>>>>>> @export
>>>>>> annotations.  How could we determine which variables are being
>>>>>> accessed
>>>>>> via foo[someProperty] and only keep @export on those properties?
>>>>>> You might be able to use a text replacement tool to remove @export
>>>>>> and
>>>>>> mess around with the rest of the source to prevent renaming of the
>>>>>> few
>>>>>> variables that will be looked up by foo[someProperty].  Either
>>>>>> keeping
>>>>>> the
>>>>>> @export or use ["string"] access which I think prevents renaming
>>>>>> GCC.
>>>>>> There are options in the compiler to skip generating the js-debug
>>>>>> just
>>>>>> call GCC.
>>>>>> My 2 cents,
>>>>>> -Alex
>>>>>> On 8/6/17, 3:13 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>>> I’m getting close to the release of my app and I’m starting
to think
>>>>>>> about some things related.
>>>>>>> I would like to have the option for minified code to have package,
>>>>>>> class
>>>>>>> and members renamed at compile time. I have two reasons for this:
>>>>>>> 1. Obfuscation. As it stands, it’s pretty easy to take minified
>>>>>>> from
>>>>>>> FlexJS and reconstruct the original code with the original structure
>>>>>>> and
>>>>>>> naming. Everything is @exported and easily readable. I’d like
>>>>>>> have a
>>>>>>> method to rename everything to something completely unintelligible.
>>>>>>> 2. Code size. I was not sure how much package paths would effect
>>>>>>> code
>>>>>>> size, so I just did an experiment. I renamed every package path
>>>>>>> my
>>>>>>> app
>>>>>>> to a much shorter version (i.e. org.apache.flex.core becomes
>>>>>>> etc.) I
>>>>>>> did not spend the time renaming class names or class member names.
>>>>>>> Just
>>>>>>> shortening the package paths resulted in a reduction of 509KB
>>>>>>> 505KB
>>>>>>> after gzipping. (Prior to gzipping the reduction was 53 KB.)
>>>>>>> names
>>>>>>> and member names are a significant percentage of the remaining
>>>>>>> code, so
>>>>>>> it stands to reason that renaming those will result in a further
>>>>>>> reduction of code size.
>>>>>>> To be clear: obfuscation is a much bigger drive for me than code
>>>>>>> size.
>>>>>>> Code size is just an added plus.
>>>>>>> I was thinking of ideas on how to accomplish this goal.
>>>>>>> One idea was to  enable some kind of metadata (or comments) in
>>>>>>> code
>>>>>>> that the compiler could interpret to rewrite the names
>>>>>>> Another idea was some kind of mapping file that serves the same
>>>>>>> purpose.
>>>>>>> This is something that should be enabled via a compiler option.
>>>>>>> The challenge would be with library code in a swc. Since it’s
>>>>>>> already
>>>>>>> compiled to JS, it would be much harder to rename things unless
>>>>>>> would
>>>>>>> work using find/replace. It seems to me that it would be more
>>>>>>> reliable
>>>>>>> if
>>>>>>> done while walking the tree and packages, classes and members
>>>>>>> each
>>>>>>> be handled explicitly.
>>>>>>> Thoughts?
>>>>>>> Harbs

View raw message