Obfuscation

[adligo]

Have you explored Obfuscation of the JSON, in particular synchronized Obfuscation of JavaScript source code and Java source code. The Use-Case for Obfuscation is two fold;

1) Reducing the wire cost ( [a, b, c] is more lightweight than [foo, bar, address]), for apps that are controlled by a single entity.

2) Sneakiness, although JavaScript source is generally obtainable it's a small layer of protection in a insecure world.

Note GWT support would all Obfuscation in GWT apps, but not in other Javascript frameworks.

[safris]

Hi @adligo, the ideas behind JSON Obfuscation are definitely useful. However, JSON Obfuscation is outside the scope of the JSONx projects. The JSONx projects provide a schema language, and reference implementations for parsers, marshalers, validators, and binding APIs for Java, JavaScript, and more to come.

The reason JSON Obfuscation is outside the scope of JSONx projects is because such a component would couple Obfuscated JSON documents to JSONx (just like JSON documents obfuscated by GWT are coupled to GWT). The goal of JSONx is to provide a schema solution that is non-coupling to JSON documents themselves. This allows JSONx to be applicable to any and all JSON document, but no JSON documents would require JSONx for anything themselves. An Obfuscation module would violate this architecture.

[adligo]

Hi Seva,

I realized that before I sent it, however I would like to add it as a Use-Case, and the kitchen sink :)_

The JSONx project does provide JSON serialization in an independent way, and I really like the schema idea. I would like to add all of the features I can think of to this project so that I have a single project that does everything JSON / Schema / Serialization & Marshaling on (JSE, GWT, (GWT) Node and Client JavaScript) / Obfuscation

I could probably fork the project to get all of this work, or write wrappers. But I think it is more friendly / neighborly to contribute to your project. What are your thoughts on design should I attempt all of this?

I should mention that my interest is in part for use in ASBP;

https://tools.ietf.org/html/draft-adligo-hybi-asbp-02

Also note I am adding plug-able security into ASBP (i.e. https://paseto.io/ tokens)

On Fri, Jul 26, 2019 at 3:43 PM Seva Safris notifications@github.com wrote:

Hi @adligo https://github.com/adligo, the ideas behind JSON Obfuscation are definitely useful. However, JSON Obfuscation is outside the scope of the JSONx projects. The JSONx projects provide a schema language https://github.com/jsonx-org/schema/, and reference implementations for parsers, marshalers, validators, and binding APIs for Java https://github.com/jsonx-org/java/, JavaScript https://github.com/jsonx-org/javascript/, and more to come.

The reason JSON Obfuscation is outside the scope of JSONx projects is because such a component would couple Obfuscated JSON documents to JSONx (just like JSON documents obfuscated by GWT are coupled to GWT). The goal of JSONx is to provide a schema solution that is non-coupling to JSON documents themselves. This allows JSONx to be applicable to any and all JSON document, but no JSON documents would require JSONx for anything themselves. An Obfuscation module would violate this architecture.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCPAWVIEOHGRB6ZD4FLQBNOVZA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25VJHA#issuecomment-515593372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCKEEVYX7WILX6LPNHLQBNOVZANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[adligo]

Hi Again Seva,

I just noticed your reference to JAX-RS and read the pdf; https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1564178068_ee8830ae4348633414817d15577d5897

javax.xml. is NOT* supported in GWT; http://www.gwtproject.org/doc/latest/RefJreEmulation.html

In addition GWT has it's own JSON API (which I am NOT interested in using) http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSON.html

Perhaps my changes would be to much of a change for this version JSONx, since it would require; Dropping of JAX-RS dependencies (i.e. javax.xml) for runtime Serialization (De-Serialization) with optional Marshalling.

If your interested in collaborating on the things I am suggesting let me know, it looks to be ground up development of a new project. I would like to incorporate the JSONx ideas into it though.

In a nutshell my position I really like the idea of JSONx adding schemas and Marshaling. But, that JSON and XML are TEXT and should be Marshalable and Serializable from anywhere JVM or JavaScript using a single set of Source Files. In addition in my work on xml_io seven years ago (a project that goes the other way Java to XML). Source code generation (or byte code generation) seemed to be the way to go as it optimized out reflection at run time. I prefer Source Code generation because of it's compatibility with GWT, which allows it to also be compatible with vanilla JavaScript (Node.js).

http://cvs.adligo.org/viewvc/xml_io/

On Fri, Jul 26, 2019 at 4:23 PM Scott Morgan scott@adligo.com wrote:

Hi Seva,

I realized that before I sent it, however I would like to add it as a Use-Case, and the kitchen sink :)_

The JSONx project does provide JSON serialization in an independent way, and I really like the schema idea. I would like to add all of the features I can think of to this project so that I have a single project that does everything JSON / Schema / Serialization & Marshaling on (JSE, GWT, (GWT) Node and Client JavaScript) / Obfuscation

I could probably fork the project to get all of this work, or write wrappers. But I think it is more friendly / neighborly to contribute to your project. What are your thoughts on design should I attempt all of this?

I should mention that my interest is in part for use in ASBP;

https://tools.ietf.org/html/draft-adligo-hybi-asbp-02

Also note I am adding plug-able security into ASBP (i.e. https://paseto.io/ tokens)

On Fri, Jul 26, 2019 at 3:43 PM Seva Safris notifications@github.com wrote:

Hi @adligo https://github.com/adligo, the ideas behind JSON Obfuscation are definitely useful. However, JSON Obfuscation is outside the scope of the JSONx projects. The JSONx projects provide a schema language https://github.com/jsonx-org/schema/, and reference implementations for parsers, marshalers, validators, and binding APIs for Java https://github.com/jsonx-org/java/, JavaScript https://github.com/jsonx-org/javascript/, and more to come.

The reason JSON Obfuscation is outside the scope of JSONx projects is because such a component would couple Obfuscated JSON documents to JSONx (just like JSON documents obfuscated by GWT are coupled to GWT). The goal of JSONx is to provide a schema solution that is non-coupling to JSON documents themselves. This allows JSONx to be applicable to any and all JSON document, but no JSON documents would require JSONx for anything themselves. An Obfuscation module would violate this architecture.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCPAWVIEOHGRB6ZD4FLQBNOVZA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25VJHA#issuecomment-515593372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCKEEVYX7WILX6LPNHLQBNOVZANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[safris]

Hi @adligo,

I'll try to address your questions in order.

The jaxrs module is supplementary. If you desire JAX-RS integration, then you use this module. If not, then the rest of the libraries are devoid of any dependence on JAX-RS.

The JsonXml module of the JSONx is completely independent from the rest of the JSONx modules. As in, no other modules depend on the JsonXml module, and the JsonXml module does not depend on any other modules. I will eventually remove it from this project altogether, and will place it into its own repository. The JSONx project only concerns JSON.

The scope of the JSONx project can be described very simply as:

1. JSONx Schema
2. JSONx Framework for Java, which provides reference implementations for:
   1. JSONx<-->Java binding API.
   2. Binding class generator
   3. jsonx-maven-plugin for class generation and schema validation and conversion.
   4. JAX-RS integration.
3. JSONx Framework for JavaScript, which provides reference implementations for:
   1. JSON validator against a JSONx Schema.

As you can see, the scope of the JSONx project is very confined, as the goal of this project is to create an enterprise-grade JSON Schema solution.

The JSONx project was carefully architected to not be coupled to any non-standard specifications. The standards to which JSONx is coupled are:

1. JSON.
2. JavaScript.
3. Java.
4. Maven.
5. JAX-RS.

As you can see, something like GWT doesn't really fit in here. Which is why I would only support the implementation of supplementary libraries on top of the JSONx core project, but not inside the project itself. For this project to remain successful in the near and far future, it cannot be coupled to any non-standard specifications.

[adligo]

I see your point of view. My point of view is that GWT is what keeps Java cool, and promotes Java as a standard. I think a lot of folks prefer Kotlin or Scala for creating JVM bytecode. I still prefer Java because of GWTs ability to translate it to JavaScript.

[adligo]

Hi Seva,

The following are my thoughts on a standards approach (sorry for verbosity);

There are two major types of standards;

The "It is Just What Everyone Does" Standard and the "Standards Organization" Standard

In my opinion Maven fall into the It is Just What Everyone Does Standard simply because there are no standards body that reviewed and approved either of these tools as a standard. It is a nice open source project currently hosted and maintained by the Apache Foundation. The Apache Foundation is not a standards body.

From apache.org;

APACHE IS …

OPEN: The Apache Software Foundation provides support for 300+ Apache Projects and their Communities, furthering its mission of providing Open Source software for the public good.

INNOVATION: Apache Projects are defined by collaborative, consensus-based processes, an open, pragmatic software license and a desire to create high quality software that leads the way in its field.

COMMUNITY: We are a community of developers and users of enterprise-grade, Open Source Apache projects used in every Internet-connected country on the planet.

JSON 11+ years of work;

https://tools.ietf.org/html/rfc4627

https://tools.ietf.org/html/rfc8259

IETF creates standard per their website ietf.org;

Working Groups are the primary mechanism for development of IETF specifications and guidelines. Working Groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.).

Java & JAX-RS https://jcp.org/en/jsr/detail?id=311

JCP creates standards per their website jcp.org

Welcome to jcp.org, home of the Java Community ProcessSM (JCPSM) Program. The JCP is the mechanism for developing standard technical specifications for Java technology. Anyone can register for the site and participate in reviewing and providing feedback for the Java Specification Requests (JSRs), and anyone can sign up to become a JCP Member and then participate on the Expert Group of a JSR or even submit their own JSR Proposals.

XML https://www.w3.org/TR/xml/

The w3c creates standards per their website w3c.org;

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web.

On Fri, Jul 26, 2019 at 6:18 PM Seva Safris notifications@github.com wrote:

Hi @adligo https://github.com/adligo,

I'll try to address your questions in order.

The jaxrs https://github.com/jsonx-org/java/tree/master/jaxrs module is supplementary. If you desire JAX-RS integration, then you use this module. If not, then the rest of the libraries are devoid of any dependence on JAX-RS.

The JsonXml https://github.com/jsonx-org/java/tree/master/jsonxml module of the JSONx is completely independent from the rest of the JSONx modules. As in, no other modules depend on the JsonXml module, and the JsonXml module does not depend on any other modules. I will eventually remove it from this project altogether, and will place it into its own repository. The JSONx project only concerns JSON.

The scope of the JSONx project can be described very simply as:

1. JSONx Schema https://github.com/jsonx-org/schema/
2. JSONx Framework for Java https://github.com/jsonx-org/java/, which provides reference implementations for:
   1. JSONx<-->Java binding API https://github.com/jsonx-org/java/tree/master/binding.
   2. Binding class generator https://github.com/jsonx-org/java/tree/master/generator
   3. jsonx-maven-plugin https://github.com/jsonx-org/java/tree/master/jsonx-maven-plugin for class generation and schema validation and conversion.
   4. JAX-RS https://github.com/jsonx-org/java/tree/master/jaxrs integration.

As you can see, the scope of the JSONx project is very confined, as the goal of this project is to create an enterprise-grade JSON Schema solution.

The JSONx project was carefully architected to not be coupled to any non-standard specifications. The standards to which JSONx is coupled are:

1. JSON.
2. Java.
3. Maven.
4. JAX-RS.

As you can see, something like GWT doesn't really fit in here. Which is why I would only support the implementation of supplementary libraries on top of the JSONx core project, but not inside the project itself. For this project to remain successful in the near and far future, it cannot be coupled to any non-standard specifications.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCNH3NW3M7HSLLQJQPTQBOA6DA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD255MYY#issuecomment-515626595, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCL5KGKVW6T4D6ZSL4LQBOA6DANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[adligo]

Hi Again Seva,

In my opinion there is no conflict between the client contracts pattern and the obfuscation pattern. However, the main issue when using both is that both parties must use the same obsfucator (and obfuscation map / settings), otherwise nothing will work, of course :)

To me JSONx is a tool that marshals and unmarshals JSON, class generation is how it's done. I am focused on the marshaling and unmarshaling concept.

One of the advantages to creating Text (XML and JSON) adapters with a tool like GWT is that it allows sharing of the Obsfucator (and it's map / settings) as part of the adapter in Java and JavaScript.

I have attached a Java doc text file that outline a rough plan that I am working through. I believe it will work with schemas in the Keeper (aka Unmarshaller) and Marshaler. Java (GWT) source code that checked schema rules would need to be generated, and then incorporated as a pluggable solution.

I am also excited that this could lead to a unified approach to obfuscation between languages with *JSONx*, Java and JavaScript leading the way. There are problems with obfuscating JavaScript currently, the JSON fields generally can't be obfuscated in a typical JavaScript to Java app because there is currently no way to share the obfuscation code and settings with Java. I believe if we work together this would allow for a common method of obfuscation that could be used in any Java, JavaScript or Java-JavaScript application architecture (Angular, React, Node, GWT, JEE, Javascript, MicroProfile, Spring, Vue, etc). This would in turn allow other languages to follow suit as required.

On Fri, Jul 26, 2019 at 3:43 PM Seva Safris notifications@github.com wrote:

Hi @adligo https://github.com/adligo, the ideas behind JSON Obfuscation are definitely useful. However, JSON Obfuscation is outside the scope of the JSONx projects. The JSONx projects provide a schema language https://github.com/jsonx-org/schema/, and reference implementations for parsers, marshalers, validators, and binding APIs for Java https://github.com/jsonx-org/java/, JavaScript https://github.com/jsonx-org/javascript/, and more to come.

The reason JSON Obfuscation is outside the scope of JSONx projects is because such a component would couple Obfuscated JSON documents to JSONx (just like JSON documents obfuscated by GWT are coupled to GWT). The goal of JSONx is to provide a schema solution that is non-coupling to JSON documents themselves. This allows JSONx to be applicable to any and all JSON document, but no JSON documents would require JSONx for anything themselves. An Obfuscation module would violate this architecture.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCPAWVIEOHGRB6ZD4FLQBNOVZA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25VJHA#issuecomment-515593372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCKEEVYX7WILX6LPNHLQBNOVZANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

/*

• The basic idea is in two parts (In Memory Adaption, Text Production);
  
• In Memory Adaption
  
• Text (i.e. JSON, XML, etc) -> Parser -> Lexicon -> Clarifier -> Keeper -> MutantFactory -> In Memory Object
  
• 
  
• Where the separation of concerns is
  
• Parser a required API component that reads the text and starts the chain of in memory adaption
  
• 
  
• All of the following components MUST implement the uniform Inbound interface (i.e. I_XMLTextParser, I_JSONTextParser) ;
  
• Lexicon a required component that validates the base layer of the text (i.e. schemaless XML, or schemaless JSON)
  
• Clarifier a optional component that unmangles (de-obsfucates) the token values
  
• Keeper a optional component that checks the incoming tokens against a Schema (i.e. XML or JSON schema)
  
• MutantFactory a required component that creates and populates Mutable Object instances
  
• NOTE the MutantFactory MAY be generated through automated source file generation or class generation
  
• from a schema or other source. The MutantFactories MAY also be coded by a person.
  
• 
  
• Text Production
  
• In Memory Object -> InstanceAdaptor -> Builder -> Marshal -> Obsfucator -> Producer -> Text
  
• InstanceAdaptor a required component that reads from the instance object and writes to the Builder
  
• NOTE the InstanceAdaptor MAY be generated through automated source file generation or class generation
  
• from a schema or other source. The InstanceAdaptors MAY also be coded by a person.
  
• 
  
• Builder a required API component that starts the process of text production
  
• All of the following components MUST implement the uniform Outbound interface (i.e. I_XMLTextProducer, I_JSONTextProducer) ;
  
• Marshal a optional component that verifies the creation of text vs a schema (XML, JSON, etc)
  
• Obsfucator a optional component that mangles (obsfucates the tokens)
  
• Producer a required component that finishes the process of text production
  

• */

[safris]

Hi Adligo,

Thank you for your synopsis of the standards that are involved in JSONx. Ultimately, the goal of the JSONx project is to provide a schema solution that works with any and all JSON. And, just as important, is the requirement that any and all JSON documents that use JSONx technologies don't require JSONx (i.e. the fact that JSONx is involved on one side of the protocol doesn't mean that the other side of the protocol would require JSONx). This is a core requirement, and so far, it is upheld. The JSONx Schema outlines a small set of requirements here (I should update this list to articulate what I just mentioned here). With regard to GWT integration, my concern is that it would make JSONx to be required on both ends of the protocol.

Let me ask you:

1. How do you see GWT integration affecting the JSONx Schema?
2. The JSONx Framework for Java project integrates the rules implemented in a JSONx Schema into generated binding classes for parsing and marshaling JSON to-and-from Java objects. This works with any and all JSON documents. What additional functionalities do you see GWT integration adding here?

[adligo]

Hi Seva,

To respond to your summary paragraph. I agree that all additional features (marshaling, obfuscation and JavaScript run time support) should be optional in all target environments. The additional features should be easy to swap in or out as necessary.

1) How do you see GWT integration affecting the JSONx Schema?

With a quick glance and some deep thinking, I don't see it affecting this at all. Although the devil is in the details, and there is probably something I haven't thought through. But I do NOT see any issues with any of the schemas (JSONx Schema or OPEN JAX Schema);

2) The JSONx Framework for Java project integrates the rules implemented in a JSONx Schema into generated binding classes for parsing and marshaling JSON to-and-from Java objects. This works with any and all JSON documents. What additional functionalities do you see GWT integration adding here?

The following two features would be supported through GWT integration;

2a) Obfuscation support on JVM and JavaScript run times.

2b) Javascript (Un-)Marshaling support

In addition, I am thinking through how to merge our work, here is a rough roadmap;

R1) Keep working on / maintaining JSONx as is!

R2) I will also work independently (currently on a list of projects under adligo.org [i_ta, ta, i_xmla, xmla, i_jsona, jsona, *_tests], note the a stands for adaptor (i.e. ta = text adaptor).

R3-4) Add a project (potentially named JSONx_AI?) set of adaptor interfaces that can compile to GWT(shared) that essentially provides the ability to wrap the current JAX-RS API. Also, add a implementation of the (JSONx_AI) project in a new project (potentially named JSONx_AI_JCP) that binds the GWT compatible adaptor interfaces to the current JAX-RS API.

R5) Add a source code generator in JSONx (potentially named JSONx_SG) that binds the JSON text by schema file to the JSONx_AI project interfaces.

R6) Re-Implement JAX-RS functionality in GWT(shared) compatible source in a new project (potentially named JSONx_AI_JJS), ouch this may be painful. This may involve source code generation per schema (i.e. if JAX-RS is using reflection under the hood).

R7) Update the jsona.adligo.org project to use the JSONx_AI_JJS and JSONx_AI projects to implement the Marshal and Keeper along with generated source code per schema.

R8) Create a API for plugable Obfuscators and Clarifers, they may end up in a JSONx_AI implementation as well as jsona.adligo.org (and others xmla.adligo.org). There may be N projects here one for JSON one for XML etc; Features should include field, data and combined obfuscation ie;

Field Obfuscation (+1 letter f becomes g)

{

"f":"b" -> "g":"b"

}

Field Clarification (-1 letter g becomes f)

{

"g":"b" -> "f":"b"

}

Data Obfuscation (+1 letter b becomes c)

{

"f":"b" -> "f":"c"

}

Data Clarification (-1 letter c becomes b)

{

"f":"c" -> "f":"b"

}

R9) Optional? Add an implementation of JSONx_AI that can delegate to another JSONx_AI and allows hooks for plugable Obfuscators and Clarifiers (DeObfucators). Note this allow JAX-RS code to be compatible with the shared parsers I am writing in jsona.adligo.org. This gives the user a choice long term on the JSE, use the shared parsers (jsona.adligo.org) or the JAX-RS parsers since there will be two implementations. Everything should be easy to swap in or out, allowing architects and developers to play around with what they want.

R10) Add obsfucators and Clarifiers to projects that plug into the jsona.adligo.org API. Also, here are some notes on Obfuscation. The extensions to JSONx would provide Obfuscation of JSON fields and data. This would in turn allow JavaScript Obsfucators to do a better job, because the JSON field names would already be Obfuscated as part of the design. Since JavaScript Obsfucators can not change the JSON field names for remote services, they can NOT robustly Obfuscate the models. With design time Obfuscated JSON field names and a JavaScript Clairifier, the 3rd party JavaScript Obsfucators can remove the problem domain field names from the JavaScript providing a more complete and robust Obfuscation. Complete Robust Obfuscation will incur a minimal performance overhead of a few JavaScript function calls, and will also offer a performance optimization in the form of reduce size of the JSON over the socket.

On Mon, Jul 29, 2019 at 6:48 AM Seva Safris notifications@github.com wrote:

Hi Adligo,

Thank you for your synopsis of the standards that are involved in JSONx. Ultimately, the goal of the JSONx project is to provide a schema solution that works with any and all JSON. And, just as important, is the requirement that any and all JSON documents that use JSONx technologies don't require JSONx (i.e. the fact that JSONx is involved on one side of the protocol doesn't mean that the other side of the protocol would require JSONx). This is a core requirement, and so far, it is upheld. The JSONx Schema outlines a small set of requirements here https://github.com/jsonx-org/java/#32-requirements (I should update this list to articulate what I just mentioned here). With regard to GWT integration, my concern is that it would make JSONx to be required on both ends of the protocol.

Let me ask you:

1. How do you see GWT integration affecting the JSONx Schema https://github.com/jsonx-org/schema/?
2. The JSONx Framework for Java https://github.com/jsonx-org/java/ project integrates the rules implemented in a JSONx Schema into generated binding classes for parsing and marshaling JSON to-and-from Java objects. This works with any and all JSON documents. What additional functionalities do you see GWT integration adding here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCMG6KCT2CNLQIAK733QB3KHDA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3AOQQQ#issuecomment-515958850, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCN5DGRVMDQ7B2QG3MTQB3KHDANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[safris]

Hi Adligo,

Thanks for the detailed response. I was able to follow what you said to a fair degree, but I'm not 100% on the packaging pattern you're envisioning.

A few immediate thoughts:

1. I believe there will be no need for the JSONx Schema to change. Because, currently, the JSONx Schema supports all JSON documents already.
2. Since JSONx Schema already supports all JSON documents, then obfuscation, or any other GWT integration is possible to be implemented on a layer on top.
3. The JSONx Framework for Java implements a binding API and class generator that supports the full scope of the JSONx Schema. This means that obfuscation, or any other GWT integration is possible to be implemented on a layer on top.
4. Obfuscation concerns JSON documents, and does not concern JSONx Schema. As I see it, the Obfuscation Module will need 2 functions: obfuscate(json):json and unobfuscate(json):json. Calling unobfuscate(obfuscate(json)) will lead to the same json.
5. The jaxrs module implements the JAX-RS spec to allow JSONx Framework for Java to act as a Provider that provides MessageBodyReader and MessageBodyWriter capabilities. In order to plug in some kind of higher-layer wrapping, on either the reading or writing end of the protocol, the JAX-RS spec allows you do to this with Entity Interceptors. Obfuscation and unobfuscation can be implemented with an Entity Interceptor layer directly in JAX-RS. Such an approach would work for any and all JSON documents, and would not be coupled to JSONx. This approach would therefore be most portable, and most usable by more people, as it would not require JSONx to be present.

[adligo]

Hi Seva,

Sorry for the delay in my response. I agree with most of what you said, however I do see the following conflicts;

1) In your point number 5 the MessageBodyReader and MessageBodyWriter are NOT available on the GWT JRE Emulation.

http://www.gwtproject.org/doc/latest/RefJreEmulation.html

I would have two options either implement everything twice (once for GWT and once for JSE) or simply NOT use the MessageBodyReader and MessageBodyWriter interfaces. Since the whole point of using something like GWT in my opinion is to reduce pointless redundant implementations, I would choose to NOT use the MessageBodyReader and MessageBodyWriter interfaces.

This means that in order to use JSONx and the Obfuscator the flow would be as follows;

object -> JSONx marshal -> JAXRS Writer -> JSON -> GWT Parse JSON -> Obfuscate -> Obfuscated JSON

or

Obfuscated JSON -> GWT Parse JSON -> Clarify -> JSON -> JAXRS Parser -> JSONx un-marshaler - > object

The disadvantage is that the JSON would be parsed or written twice on each read or write. Long term I would want to only parse or write the JSON once. I see that you agree with that point since you suggested the MessageBodyReader and MessageBodyWriter interfaces. The main problem is that they will NOT compile to JavaScript.

For this and other reasons I would be implementing a JSON and XML parser / writer from scratch, adding schema based obfuscation and then adding in schema based marshaling. It's a long term plan :)

On Tue, Jul 30, 2019 at 7:55 AM Seva Safris notifications@github.com wrote:

Hi Adligo,

Thanks for the detailed response. I was able to follow what you said to a fair degree, but I'm not 100% on the packaging pattern you're envisioning.

A few immediate thoughts:

1. I believe there will be no need for the JSONx Schema to change. Because, currently, the JSONx Schema supports all JSON documents already.
2. Since JSONx Schema already supports all JSON documents, then obfuscation, or any other GWT integration is possible to be implemented on a layer on top.
3. The JSONx Framework for Java implements a binding API and class generator that supports the full scope of the JSONx Schema. This means that obfuscation, or any other GWT integration is possible to be implemented on a layer on top.
4. Obfuscation concerns JSON documents, and does not concern JSONx Schema. As I see it, the Obfuscation Module will need 2 functions: obfuscate(json):json and unobfuscate(json):json. Calling unobfuscate(obfuscate(json)) will lead to the same json.
5. The jaxrs https://github.com/jsonx-org/java/tree/master/jaxrs module implements the JAX-RS spec to allow JSONx Framework for Java to act as a Provider that provides MessageBodyReader and MessageBodyWriter capabilities. In order to plug in some kind of higher-layer wrapping, on either the reading or writing end of the protocol, the JAX-RS spec allows you do to this with Entity Interceptors https://www.logicbig.com/tutorials/java-ee-tutorial/jax-rs/interceptors.html. Obfuscation and unobfuscation can be implemented with an Entity Interceptor layer directly in JAX-RS. Such an approach would work for any and all JSON documents, and would not be coupled to JSONx. This approach would therefore be most portable, and most usable by more people, as it would not require JSONx to be present.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCMUTFMVDWDIOXC67ALQCA23RA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3D3ZHY#issuecomment-516406431, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCMIGGSSL2JSNKLWMSTQCA23RANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[safris]

Hi Adligo,

I'm not really clear on your plan. From the GWT link you provided, it looks like none of the JAX-RS libraries are available. So I'm not sure how JAX-RS fits in to this picture then.

You mention "schema based obfuscation". Can you define what that is exactly? And what is "schema based marshaling"?

[adligo]

JAX-RS doesn't fit into my plan, it's just how you are doing schema based marshaling currently in this JSONx project.

Schema base Obfuscation is basing the Obfuscation of field names from the schema. For example from your toptal article;

https://www.toptal.com/web/json-vs-xml-part-3

We know there that there are Messages with Types and Codes and which may have Routing information. Using this information from the schema we can create a Obfuscation field map;

message ->a

type -> b

code ->c

routing->d

This information can then be inserted into generated Java GWT source code, and from there compiled into Java Byte Code or JavaScript source code.

On Tue, Aug 6, 2019 at 5:05 PM Seva Safris notifications@github.com wrote:

Hi Adligo,

I'm not really clear on your plan. From the GWT link you provided, it looks like none of the JAX-RS libraries are available. So I'm not sure how JAX-RS fits in to this picture then.

You mention "schema based obfuscation". Can you define what that is exactly? And what is "schema based marshaling"?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCI7ZQRJDLY7X253KM3QDHYUFA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3WTH7I#issuecomment-518861821, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCNZI473B4IP447D3ODQDHYUFANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[safris]

Hi Adligo,

As I mentioned before, the JAX-RS module is just for integration of JSONx into JAX-RS. It is a supplementary module. The reason I'm repeating this is because of how you say "how you are doing schema based marshaling currently in this JSONx project." This statement of yours is a bit off. The JAX-RS module is for JAX-RS applications. If you are not working with JAX-RS, then don't use the JAX-RS module (duh). The JSONx project provides a schema and class binding solution. This can be used for whatever you want, be it JAX-RS, Spring, or whatever you want. Again, the JAX-RS module is provided because it is a complete integration of JSONx into JAX-RS, which this project provides, to make everyone's life easy when trying to use JSONx with a JAX-RS runtime.

When you say "schema based marshaling", I believe what you're saying is: the marshaling of Java classes that are bound to a JSONx Schema.

When you say "schema based obfuscation", I believe what you're saying is: leveraging the JSONx Schema to define an obfuscation model (obfuscation map / rules) that can thereafter be used to marshal Java classes that are bound to a JSONx Schema with obfuscated property names.

From what I can see so far, the mention of GWT does not even need to be made. The obfuscation design that I believe you are describing can be made as an independent module.

If you would like, provide a more detailed design plan, and we can iterate an implementation strategy.

Please correct me if I am still off regarding my comprehension here.

Thanks, seva

[adligo]

Hi Seva,

Thanks for your clarification. GWT compatibility is the primary concern of mine since I would like to support JavaScript systems like the , Node.js server, and clients like GWT, Angular, React, Vue etc in addition to JSE with a single implementation. I am really harping on this point in order to facilitate the possibility of future integration. All that I am really asking here is for you to please consider staying in the confines of GWT JRE emulation as you add code or maintain code in the JSONx projects, which MAY allow me to use the JSONx projects in the long run or at least minimize the effort should I find forking JSONx the path of least resistance.

In a nutshell the main issue that the JSONx and many other projects are encountering is simply; insufficient GWT awareness Although GWT is not a standard at the JCP and may never become one, I still feel that the JCP should be much more aware and appreciative of the extraordinary efforts of the GWT community to stick with Java. I would like to make comments to this effect at the JCP but I don't have an extra $5k per year in my budget to become a member. In other words I would also like the JAX-RS to support GWT directly, after all JSON and XML are just TEXT.

I will let you know as I have something more concrete to work with (like some more projects on github). Perhaps my projects could be promoted as a new JCP standard to replace JAX-RS some time in the future?

On Thu, Aug 8, 2019 at 7:13 AM Seva Safris notifications@github.com wrote:

Hi Adligo,

As I mentioned before, the JAX-RS module is just for integration of JSONx into JAX-RS. It is a supplementary module. The reason I'm repeating this is because of how you say "how you are doing schema based marshaling currently in this JSONx project." This statement of yours is a bit off. The JAX-RS module is for JAX-RS applications. If you are not working with JAX-RS, then don't use the JAX-RS module (duh). The JSONx project provides a schema and class binding solution. This can be used for whatever you want, be it JAX-RS, Spring, or whatever you want. Again, the JAX-RS module is provided because it is a complete integration of JSONx into JAX-RS, which this project provides, to make everyone's life easy when trying to use JSONx with a JAX-RS runtime.

When you say "schema based marshaling", I believe what you're saying is: the marshaling of Java classes that are bound to a JSONx Schema.

When you say "schema based obfuscation", I believe what you're saying is: leveraging the JSONx Schema to define an obfuscation model (obfuscation map / rules) that can thereafter be used to marshal Java classes that are bound to a JSONx Schema with obfuscated property names.

From what I can see so far, the mention of GWT does not even need to be made. The obfuscation design that I believe you are describing can be made as an independent module.

If you would like, provide a more detailed design plan, and we can iterate an implementation strategy.

Please correct me if I am still off regarding my comprehension here.

Thanks, seva

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCM3XSSSBZDA62GUWZDQDQEWTA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33NH5I#issuecomment-519492597, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCLQJKT72FCTG7ZIV4LQDQEWTANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

[safris]

Hi Adligo,

Have you tried to use classes with JSONx bindings (generated from a schema, or hand created) with a GWT application? Because, I believe the binding API does not depend on classes that are unsupported by GWT. I haven't done this analysis in depth, and all it would take is to make a GWT app that uses JSONx.

I'm not quite sure what you mean by "would also like the JAX-RS to support GWT directly". I'm still confused as to what you mean regarding the relation of JAX-RS and GWT. The jaxrs module is for JAX-RS runtimes, and has nothing to do with GWT at all (and will never have anything to do with it). The jaxrs module is a mere 1.7% of the entire JSONx Framework for Java project (comparing line count).

In order to achieve support for JSONx in GWT, I think the first step would be to construct a GWT test app that uses Java classes with JSONx binding API. Maybe you could use the Invoice sample as a starting point, to get these Java classes. Then, create a simple GWT app integrating these classes, and see what happens. I'd be interested to see what you discover.

Thanks, seva

[adligo]

Hi Seva,

Ok the invoice example sounds like a good place to start. My comments about JAX-RS are just rantings about how things are designed in silos and could work better if designed with more collaboration.

On Fri, Aug 9, 2019 at 7:24 AM Seva Safris notifications@github.com wrote:

Hi Adligo,

Have you tried to use classes with JSONx bindings (generated from a schema, or hand created) with a GWT application? Because, I believe the binding API does not depend on classes that are unsupported by GWT. I haven't done this analysis in depth, and all it would take is to make a GWT app that uses JSONx.

I'm not quite sure what you mean by "would also like the JAX-RS to support GWT directly". I'm still confused as to what you mean regarding the relation of JAX-RS and GWT. The jaxrs https://github.com/jsonx-org/java/tree/master/jaxrs module is for JAX-RS runtimes, and has nothing to do with GWT at all (and will never have anything to do with it). The jaxrs https://github.com/jsonx-org/java/tree/master/jaxrs module is a mere 1.7% of the entire JSONx Framework for Java project (comparing line count).

In order to achieve support for JSONx in GWT, I think the first step would be to construct a GWT test app that uses Java classes with JSONx binding API. Maybe you could use the Invoice https://github.com/jsonx-org/java/tree/master/sample/invoice sample as a starting point, to get these Java classes. Then, create a simple GWT app integrating these classes, and see what happens. I'd be interested to see what you discover.

Thanks, seva

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/java/issues/5?email_source=notifications&email_token=ABSJQCMSHAIPA7TCFMB5XMDQDVOXTA5CNFSM4IG6NTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD36QMJY#issuecomment-519898663, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCPJ6D6UAGKQ5CGLB5DQDVOXTANCNFSM4IG6NTXA .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI