If we have in browser help then this might not need to be too extensive

We should ensure that HUD components (like the History / Timeline) can be run in 'non HUD' tabs.
The user should be able to open a new tab and display things like the history and sites tree.
In time the user should be able to create whole new ZAP UI in the browser which should work with (but independent from) the HUD.
I can imagine having the HUD in one browser window and the history in another one (on a large monitor;)

Once zaproxy/zaproxy#3878 has been merged.
This will add a dependency to the dev version of ZAP, meaning we'll have to release 2.7.0 before most people can use the HUD.
Or we could keep a 'legacy' option if we detect they are using ZAP 2.6.0.
@dscrobonia - which version of ZAP are you using? Would it be a big pain if you had to use the dev version?

The Page alerts popup shows all of the alerts for the site rather than just those for the relevant page.

Find out if sites can detect HUD usage from injected HUD UI and scripts.

If a site can detect that the ZAP HUD is in use, they could change how they behave, try to make requests to the ZAP API, or overlay HUD UI elements for impersonation attacks.

One solution for Firefox (Fx) is to use a web extension with the anonymous content API: http://docs.firefox-dev.tools/tools/highlighters.html#the-anonymouscontent-api

My plan is to do this on the wiki.
The whole repo (including the wiki) will be made public when we release the HUD, but I think we should be as up front about the threats (and mitigations) as possible, so I think publishing these is a good plan.
Any objections?

We want the HUD to be fully configurable, but we should also provide sensible defaults that give users a good initial layout + overview of what can be done.
My initial suggestion:

Left panel - more specific things, or things that people will want to do more often or earlier on (in order):

• Break
• Attack mode
• High page alerts
• Medium page alerts
• Low page alerts

Right panel - less specific, frequent or longer running things:

• Scope (or should this be on the left??)
• Spider
• Active scan
• High site alerts
• Medium site alerts
• Low site alerts

Thoughts?

The version used is no longer supported - the latest one is 3!
https://jquery.com/upgrade-guide/3.0/

The error is:

Error: Service worker registration failed: SecurityError: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).
    at ?name=management.js:30
    at <anonymous>

psiinon#17 (comment)

where the shortened link resolves to: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

For example, Chrome is going to make Service Workers available only to secure origins, because it provides the origin with a new, higher degree of control over a user's interactions with the origin over an extended period of time, and because it gives the origin some control over the user's device as a background task.

eg using something like http://introjs.com/ https://github.com/amireh/guide.js/tree/master or http://github.hubspot.com/shepherd/docs/welcome/

This will reduce the load on ZAP and also reduce our attack serface area.
But it will mean a site has to be added to the scope before the HUD can be used.

I'm not sure if it was the switch to Firefox Quantum, if new service worker standards came out, or I messed something up - but the service worker isn't restarting as clean as it used to. After "unregistering" the service worker from the about:serviceworkers panel it gets into a weird state and I have to restart firefox to get a clean start.

I should probably review the setup for the service worker lifecycle to make sure its robust and up to date.

Knowing that there a (say) 10 alerts on a page/site means nothing.
I dont care about 10 low alerts, but one high one is important.
The controls for Page/Site controls should be split out as per the POC, and users should be able to choose any combination to appear on the HUD

We should agree standard naming conventions.
For example, the 'UI controls' - what should they be called?
I tend to call them 'controls', but they are 'tools' in the JS code.
They could be widgets, UI elements, buttons or ??
I'd prefer 'controls' or 'widgets' - 'tools' seem to heavy weight.
'buttons' might be tool limiting - we could have other sorts of controls in the future, like dials or progress bars.

Thoughts?
What else should we agree names for?
The 'frames' seem pretty uncontroversial ;)

Might be 'interesting' to set up as we'll need ZAP and a test app running, but once set up would be very useful

Add option to rescan site when turning attack mode on, as per the desktop.
Set the appropriate choice via the API so that the desktop doesnt prompt the user (if used).

Not high priority just yet, but good to get working sooner rather than later

Start with just New Session (plus save options) then Load Session and maybe Snapshot

As per the POC - should only show the first instance of any alert type

If you click to see an alerts details from an alertify popup while alert details are already show, the main display will crash. need to add state to the main display and close a dialog, before openning another

When break shows the intercepted message, if you click outside of the pop up in the grayed out area, it will close the pop up and leave ZAP waiting for a response. Now you can still click break button which calls the continue api endpoint, allowing ZAP to continue and everything works fine. But I'm not sure we should have break allow somebody to ignore an intercepted message. They should have to react to it.

Maybe style guides for HTML and CSS as well?
I dont mind which, are any particularly popular / considered best practice?

We should have a set of default controls to give newcomers something to start with, otherwise they have to add them before they can do anything.

Will assign to David once he's signed up ;)

Remember if the HUD is turned on, which will also allow a new ZAP instance to be started with the HUD turned on (eg for daemon mode;)

This will be blocked if the site has a reasonable CSP.
We can change the CSP inline, but thats more manipulation of the target than I really wanted.
Ideally we should never have inline javascript, anywhere.

The HUD extension should detect CSP and either diable it, or ideally just manipulate it so that the HUD will be always work.
This should be done automatically when the HUD is enabled.
Even if we can manipulate the CSP maybe we should have an option to just strip it out in case the manipulation doesnt work or breaks other things?

As per the POC

Ideally should run on all PRs

• http://www.javascriptlint.com/
• https://github.com/reid/node-jslint

Not investigated yet...

I was looking at adding a console listener for debugging #17.

Should this log to the zap log or a separate log (if so what path?) or another pane or something else?

Something like the following without executeJavaScript:

diff --git a/src/org/zaproxy/zap/extension/jxbrowser/BrowserPanel.java b/src/org/zaproxy/zap/extension/jxbrowser/BrowserPanel.java
index 4e6ff0884..38a7f8ba3 100644
--- a/src/org/zaproxy/zap/extension/jxbrowser/BrowserPanel.java
+++ b/src/org/zaproxy/zap/extension/jxbrowser/BrowserPanel.java
@@ -34,6 +34,8 @@ import org.zaproxy.zap.view.LayoutHelper;
 
 import com.teamdev.jxbrowser.chromium.Browser;
 import com.teamdev.jxbrowser.chromium.ContextMenuHandler;
+import com.teamdev.jxbrowser.chromium.events.ConsoleEvent;
+import com.teamdev.jxbrowser.chromium.events.ConsoleListener;
 import com.teamdev.jxbrowser.chromium.events.FailLoadingEvent;
 import com.teamdev.jxbrowser.chromium.events.FinishLoadingEvent;
 import com.teamdev.jxbrowser.chromium.events.FrameLoadEvent;
@@ -175,6 +177,15 @@ public class BrowserPanel extends JPanel {
             }
             */
             browser = new Browser();
+
+           // https://jxbrowser.support.teamdev.com/support/solutions/articles/9000013060-console-messages
+           browser.addConsoleListener(new ConsoleListener() {
+                   public void onMessage(ConsoleEvent event) {
+                       System.out.println("Level: " + event.getLevel());
+                       System.out.println("Message: " + event.getMessage());
+                   }
+           });
+           browser.executeJavaScript("console.error(\"Error message\");");
         }
         return browser;
     }

It appear to work, but the scan keeps going in ZAP.

Allow other add-ons to add HUD componenets without having to change the HUD code.

The Browser Launch feature (https://zaproxy.blogspot.fr/2017/08/zap-browser-launch.html) is a really useful and easy way to launch browsers that are configured to proxy through ZAP.
Unfortunately they start with new blank browser profiles, which means that any HUD configs will be lost :(
We should store the HUD configs in ZAP and default to these when launching a browser that doesnt have any HUD configs set up.

See if we can change ZAP to allow files that match certain (configurable) regexes to be serverd even when a break point has been hit.
This may help the case where the HUD break UI cant get rendered because the browser has already made too many connections that are wating on the break point.

There is some shared functionality between them that needs to get abstracted out.

I'm thinking of just making a separate js file called alerts.js that would house shared functions. And then have those available via a module called Alerts. So that from within the page and site alert tools they could call somethign like

Alerts.formatAlerts(alerts);

Please let me know if there are any better ideas.

@psiinon you shut down the timeline after it kept crashing on you correct. Where did we land on wanting to change to push events, polling, waiting for sockets?

OK, so websockets would be the ideal solution, but until we support that in ZAP we could use a persistant connection instead of polling.
So we'd have one (or more) API endpoints that just stream events to the browser and only close if the browser closes the connection.
These should be much more efficient (and react faster) than polling.
I've used them in apps before and they worked well.
Thoughts?

The HUD always orders the controls / tools in the same way.
Users should be able to specify which order they want them in.
Drag and drop would be ideal of course, but we can have something simpler to implement to start with

Add Drop button to the list of options, fix #40, show whether message is request or reponse in title bar with text and image.

I thought I had configured the growler alerts to display a max number of alerts at once, but if more were queued up behind that max number that they would be displayed afterwards. It currently only shows the max number of configured alerts and the others aren't displayed.

Expected Behaviour:

• the growler max alerts is set to 5
• 9 new alerts are discovered
• 5 are shown first
• then after they timeout the next 5 are shown

Actual Behaviour:

• the growler max alerts is set to 5
• 9 new alerts are discovered
• 5 are shown
• no others are shown

As per the PoC, so that the HUD controls can be changed to take up as little browser real estate as possible

The HUD manages its own state after sending API requests to ZAP. It should change its state after ZAP response and informs the HUD of what state is actually in. Maybe for performance reasons the HUD could change immediately, assuming the state, and then when the API response comes back change again if it was wrong, i.e., there was an error.

Architecture, interactions, all the things :)

Add an option to allow the user to reset the HUD files.
This would delete all of the files under the HUD Base Directory and then extract them all again from the .zap file

I assume our standard license blurb should be added to all java files?
https://github.com/psiinon/zap-hud/blob/master/src/org/zaproxy/zap/extension/hud/HudAPI.java

What about all the JS files?

The HUD is currently broken with 2.7.0 due to the default blocking of access to the API to all but local domains.
To fix this I'm planning on changing the HUD add-on to listen on another (random) port on which it will serve all of the HUD content - scripts, CSS, images etc etc.
The port will be random to make it harder for sites to detect that ZAP is in use (they'll still be able to detect the HUD pretty easily).
As the HUD will be on a local domain it will then be able to call the API with the default settings.
A side effect of this is that we'll be able to serve the images that Jquery expects more easily as we wont be restricted to the API structure.
I'll aim to work on this next Monday (18th).
Can anyone think of any potential problems with this approach, or suggest better alternatives?

It should be obeyed by the Spider and Active Scanner

The ZAP Desktop is internationalized, and we should aim for all other ZAP components to be as well, inc the HUD.
Some possible options:

• Simple ZAP side home grown templating
• https://github.com/l20n/l20n.js
• https://www.i18next.com/
• https://github.com/fnando/i18n-js

All found via quick search, I've not investigated any yet ;)

Otherwise it wont work unless the API security is turned off ;)