ccloquet / showme Goto Github PK

The idea is to use the html5 api to upload the picture. Like that the user can decide or he takes the picture and does not save it on his phone or he takes the picture from his phone.

Resources :

• https://developers.google.com/web/updates/2016/12/imagecapture

Next things:

• We can add the location of the user to the picture
• Send a video
• A live video ?

Ideas from laudeco

"Next things:
We can add the location of the user to the picture
Send a video
A live video ?"

With Chrome on Android, sometimes the page is closed and the cam continues to stream.

This is a bug, but who has to solve it?

The original idea was to split both with security in mind, but after discussion with @laudeco the risks of misconfiguration / bad maintenance are high when keeping the 2 configs separate => it would be a good thing to merge both.

I would however open the possibility to upload the files to a separate server in the future (see next issue)

• disconnection during a call, dispatching side
• disconnection during a call, citizen side
• broken internet connection
• browser restart at the dispatching
• citizen refuses to share the camera
• citizen exits the page, then comes back again
• no browser support
• ...

• sometimes get the error: "Offer received for existing Connection ID: ***"

Threat models

Mitigations

instead of a simple die('error') we should set the correct http status.

As suggested by @laudeco, the code is now ready to handle video upload, the only remaining issue being the validation of the uploaded file in upload.php (reason why it is not operational yet).

However, this poses a size challenge : with min 1Mb/sec, a typical file might be 50-100 Mb large (->issue for the citizen to send, and for the dispatching to download, if there are multiple files to read).

Perhaps use smth like Apache streaming module ? https://blog.tfrichet.fr/php-upload-de-video-en-web-conversion-et-lecture-en-streaming-avec-ffmpeg-sur-debian-7-wheezy/

Happens sometimes on an old S4mini

The initial idea was that the citizen and 911/112-code could run on 2 separate servers

local stream works
remote stream is muted

Hello,

I know you didn't want any dependencies but I think useful to symfony 4, we do not need everything, we can remove nearly everything to keep just the MVC.

Advantage:

• Easier to structure files
• Easier to maintain
• if we need dependencies, we already have composer
• Controller and views are uncoupled

Negative

• Need to declare a route, controller and view.
• Need to understand symfony 4.

This is not mandatory at all, just an open discussion.
Cheer
L.

Idea from a calltaker

one option is that the server is hosted inside a protected environment
-> https POST / webRTC connection & signalling -> should be allowed firewall
-> STUN & TURN servers (currently using Twilio) may be hosted inside the protected environment
-> what could be outside ?
-> the SMS should also be sent from inside the environment & deleted immediately after the sending

So that the citizen is aware that he/she is filming

Idée de Carels Ryben via la page Facebook de Poppy

Ex: recherche sur Snapchat, Youtube, ...

https://blog.my-poppy.eu#data_from_citizens

• 911eye: http://newjersey.news12.com/story/39403479/new-911-system-will-allow-police-better-view-of-the-emergency

• 999eye: https://999eye.wordpress.com

• Geoloc_18_112

• Gendloc

• Reach-112: http://www.omnitor.se/en/projects/reach-112/

⇨ what new things do we bring?
⇨ how do we position wrt these projects ?

• open source
• public laboratory ->by lowering the barriers to installation through open source, enable to faster evaluate the technology, gather experience on a global level and iterate
• participation through the open discussions, even citizens participation

I checked it, may this be relevant still, in the idea that it tells to the dispatch where the citizen page is located? (as they are potentially on 2 different servers ?)

This topic discusses privacy by design principles & GDPR compliance

Purpose
For the 112-dispatching, to have pictures of an incident quickly, so that they can make the appropriate decisions and send the adequate help (eg: characterize which kind of smoke, or which kind of security issue the citizen is facing). The images are not to be used later in investigations.

Privacy principles

• once on the server, the images are stored anonymously
• TODO: the SMS should be erased from the server as soon as possible (only the calltaking center should have the data) => consider moving from Clickatell to Twilio (which allows to erase the messages)
• the images should be erased after 6 hours. TODO: a cron, instead of a delete one at the consultation time
• point of discussion: in the current implementation, the access logs are stored during 1 year (maybe too much for this purpose)

Notes

• to ckeck : which kind of EXIF data are transmitted and which are sensitive?
• right to one's image : what if 3rd parties are recognizable on the picture? Could they/would they be used eg. to charge for a crime unrelated with the call? Mitigation: add a banner 'only take a general picture, do not focus on people, etc.' [from @laudeco]
• if using Twilio: could redact/delete the message afterwards (eg : a cron every 6 hours deleting the messages older than 6 hours)

Impacts

• Positive

  • dispatch a better response on scene :
    • Fire: suspicious smoke, ... / technical : wesp, ...
      • send the adequate response
      • give better advice to the caller
      • Fagnes Fire: how many trees are burning? where is it?
      • need at balisage?
    • Medical: how is the leg, how is the person, ...
  • Better help of the people on the scene:
    • Improved help with video-CPR [S. Stipulante et al, EJEM, 2014, https://orbi.uliege.be/handle/2268/194076]
  • lives & costs saved

• Negative

  • yet another tool
  • responsibility: what if the tool is available and the dispatcher does not use it -> more pressure => need protocols : when to use it and when not + principle "if you do not use it, it can't be worse than not using it..."
  • endangering the citizens by asking them to take pictures of risky/dangerous situations
  • dependency to the tool & more time to take a decision (with and without the tool)
  • psychological impact on the citizen if he/she is not able to enable the 4G/video

Scaling

Interoperability

Sustainability

Are there any legal issues to consider?

Apply a Monitoring & Evaluation framework to assess the project?

Should a procedure be written to frame when to use the tool and to ensure it is used legally?

See also: #21 (brother and sister projects) and #17 (privacy by design/GDPR)

Notes from secours.goodforum.net (T41213) 👍

• installé en usine dans tous les smartphones, dans le cas contraire, seuls ceux qui s'y intéressent installeront l'application, or ce n'est pas eux qui en ont le plus besoin ;
• enclenchement automatique lorsque l'utilisateur compose le 112, dans le cas contraire, les gens paniqués n'arriveront pas à faire les manoeuvres aussi simple qu'enclencher la 4G (souvent le cas avec Geoloc) ;
• dispatcheurs avec expérience de terrain et droit de refuser l'envoi d'une ambulance après analyse des images.

credits: some ideas about impacts broughts by S. Stipulante (Liège), Lt Lopes Dias (Lux)

(contributed by a practitioner)

• danger respective to the caller that he is wrongly ranked as a
  rubberneck by other people at the emergency location
• mobile data volume isn't free of charge
• feeling of oppression by a patient being filmed during an emergency
  might be a problem
• data protection issues

But of course I also see the advantages for the emergency services by
receiving live informations by video. And some of the problems can be
solved by regulations.