Recherche avancée

Sur d’autres sites (10690)

• Data Privacy Day 2021 : Five ways to embrace privacy into your business

  27 janvier 2021, par Matomo Core Team — Community, Privacy

  Welcome to Data Privacy Day 2021 !

  This year we are excited to announce that we are participating as a #PrivacyAware Champion for DPD21 through the National Cyber Security Alliance. This means that on this significant day we are in partnership with hundreds of other organisations and businesses to share a unified message that empowers individuals to “Own Your Privacy” and for organisations to “Respect Privacy.”

  "Last year dawned a new era in the way many businesses operate from a traditional office work setting to a remote working from home environment for employees. This now means it’s more important than ever for your employees to understand how to take ownership of their privacy when working online."

  As a Data Privacy Day #PrivacyAware Champion we would like to provide some practical tips and share examples of how the Matomo team helps employees be privacy aware.

  

  Five ways to embrace privacy into your business

  1. Create a privacy aware culture within your business

  • Get leadership involved.
  • Appoint privacy ambassadors within your team. 
  • Create a privacy awareness campaign where you educate employees on your company privacy policy. 
  • Share messages about privacy around the office/or in meetings online, on internal message boards, in company newsletters, or emails. 
  • Teach new employees their role in your privacy culture and reinforce throughout their career.

  2. Organise privacy awareness training for your employees

  • Invite outside speakers to talk to employees about why privacy matters. 
  • Engage staff by asking them to consider how privacy and data security applies to the work they do on a daily basis.
  • Encourage employees to complete online courses to gain a better understanding of how to avoid privacy risks.

  3. Help employees manage their individual privacy

  • Better security and privacy behaviours at home will translate to better security and privacy practices at work. 
  • Teach employees how to update their privacy and security settings on personal accounts.
  • Use NCSA’s privacy settings page to help them get started

  4. Add privacy to the employee’s toolbox

  • Give your employees actual tools they can use to improve their privacy, such as company-branded camera covers or privacy screens for their devices, or virtual private networks (VPNs) to secure their connections.

  5. Join Matomo and we’ll be your web analytics experts

  • At Matomo, ensuring our users and customers that their privacy is protected is not only a core component of the work we do, it’s why we do what we do ! Find out how.

  Want to find out more about data privacy download your free DPD 2021 Champion Toolkit and read our post on “Why is privacy important”.

  Team Matomo

  2021 Data Privacy Day Toolkit

  Your guide to Data Privacy Day, January 28, 2021

  Free Download

• Hung out to dry

  31 mai 2013, par Mans — Law and liberty

  Outrage was the general reaction when Google recently announced their dropping of XMPP server-to-server federation from Hangouts, as the search giant’s revamped instant messaging platform is henceforth to be known. This outrage is, however, largely unjustified ; Google’s decision is merely a rational response to issues of a more fundamental nature. To see why, we need to step back and look at the broader instant messaging landscape.

  A brief history of IM

  The term instant messaging (IM) gained popularity in the mid-1990s along with the rise of chat clients such as ICQ, AOL Instant Messenger, and later MSN Messenger. These all had one thing in common : they were closed systems. Although global in the sense of allowing access from anywhere on the Internet, communication was possible only within each network, and only using the officially sanctioned client software. Contrast this with email, where users are free to choose any service provider as well as client software, inter-server communication over open protocols delivering messages to their proper destinations.

  The email picture has, however, not always been so rosy. During the 1970s and 80s a multitude of incompatible email systems (e.g. UUCP and X.400) were in more or less widespread use on various networks. As these networks gave way to the ARPANET/Internet, so did their mail systems to the SMTP email we all use today. A similar consolidation has yet to occur in the area of instant messaging.

  Over the years, a few efforts towards a cross-domain instant messaging have been undertaken. One early example is the Zephyr system created as part of Project Athena at MIT in the late 1980s. While it never saw significant uptake, it is still in use at a few universities. A more successful story is that of XMPP. Conceived under the name Jabber in the late 1990s, XMPP is an open standard specified in a set of IETF RFCs. In addition to being open, a distinguishing feature of XMPP compared to other contemporary IM systems is its decentralised nature, server-to-server connections allowing communication between users with accounts on different systems. Just like email.

  The social network

  A more recent emergence on the Internet is the social network. Although not the first of its kind, Facebook was the first to achieve its level of penetration, both geographically and across social groups. A range of messaging options, including email-style as well as instant messaging (chat), are available, all within the same web interface. What it does not allow is communication outside the Facebook network. Other social networks operate in the same spirit.

  The popularity of social networks, to the extent that they for many constitute the primary means of communication, has in a sense brought back fragmented networks of the 1980s. Even though they share infrastructure, up to and including the browser application, the social networks create walled-off regions of the Internet between which little or no exchange is possible.

  The house that Google built

  In 2005, Google launched Talk, an XMPP-based instant messaging service allowing users to connect using either Google’s official client application or any third-party XMPP client. Soon after, server-to-server federation was activated, enabling anyone with a Google account to exchange instant messages with users of any other federated XMPP service. An in-browser chat interface was also added to Gmail.

  It was arguably only with the 2011 introduction of Google+ that Google, despite its previous endeavours with Orkut and Buzz, had a viable contender in the social networking space. Since its inception, Google+ has gone through a number of changes where features have been added or reworked. Instant messaging within Google+ was until recently available only in mobile clients. On the desktop, the sole messaging option was Hangouts which, although featuring text chat, cannot be considered instant messaging in the usual sense.

  With a sprawling collection of messaging systems (Talk, Google+ Messenger, Hangouts), some action to consolidate them was a logical step. What we got was a unification under the Hangouts name. A redesigned Google+ now sports in-browser instant messaging similar the the Talk interface already present in Gmail. At the same time, the standalone desktop Talk client is discontinued, as is the Messenger feature in mobile Google+. All together, the changes make for a much less confusing user experience.

  The sky is falling down

  Along with the changes to the messaging platform, one announcement stoked anger on the Internet : Google’s intent to discontinue XMPP federation (as of this writing, it is still operational). Google, the (self-described) champions of openness on the Internet were seen to be closing their doors to the outside world. The effects of the change are, however, not quite so earth-shattering. Of the other major messaging networks to offer XMPP at all (Facebook, Skype, and the defunct Microsoft Messenger), none support federation ; a Google user has never been able to chat with a Facebook user.

  XMPP federation appears to be in use mainly by non-profit organisations or individuals running their own servers. The number of users on these systems is hard to assess, though it seems fair to assume it is dwarfed by the hundreds of millions using Google or Facebook. As such, the overall impact of cutting off communication with the federated servers is relatively minor, albeit annoying for those affected.

  A fragmented world

  Rather than chastising Google for making a low-impact, presumably founded, business decision, we should be asking ourselves why instant messaging is still so fragmented in the first place, whereas email is not. The answer can be found by examining the nature of entities providing these services.

  Ever since the commercialisation of the Internet started in the 1990s, email has been largely seen as being part of the Internet. Access to email was a major selling point for Internet service providers ; indeed, many still use the email facilities of their ISP. Instant messaging, by contrast, has never come as part of the basic offering, rather being a third-party service running on top of the Internet.

  Users wishing to engage in instant messaging have always had to seek out and sign up with a provider of such a service. As the IM networks were isolated, most would choose whichever service their friends were already using, and a small number of networks, each with a sustainable number of users, came to dominate. In the early days, dedicated IM services such as ICQ were popular. Today, social networks have taken their place with Facebook currently in the dominant position. With the new Hangouts, Google offers its users the service they want in the way they have come to expect.

  Follow the money

  We now have all the pieces necessary to see why inter-domain instant messaging has never taken off, and the answer is simple : the major players have no commercial incentive to open access to their IM networks. In fact, they have good reason to keep the networks closed. Ensuring that a person leaving the network loses contact with his or her friends, increases user retention by raising the cost of switching to another service. Monetising users is also better facilitated if they are forced to remain on, say, Facebook’s web pages while using its services rather than accessing them indirectly, perhaps even through a competing (Google, say) frontend. The users do not generally care much, since all their friends are already on the same network as themselves.

  While Google Talk was a standalone service, only loosely coupled to other Google products, these aspects were of lesser importance. After all, Google still had access to all the messages passing through the system and could analyse them for advert targeting purposes. Now that messaging is an integrated part of Google+, and thus serves as a direct competitor to the likes of Facebook, the situation has changed. All the reasons for Facebook not to open its network now apply equally to Google as well.

• OpenCV and Network Cameras -or- How to spy on my neighbors ?

  12 mai 2014, par Alexander

  ---

  A bit of context ; this program was built originally to work with USB cameras - but because of the setup between where the cameras needs to be and where the computer is it makes more sense to switch to cameras run over a network. Now I’m trying to convert the program to accomplish this, but my efforts thus far have met with poor results. I’ve also asked this same question over on the OpenCV forums. Help me spy on my neighbors ! (Totally with their permission, of course !) :D

  ---

  I’m using :

  • OpenCV v2.4.6.0
  • C++
  • D-Link Cloud Camera 7100 (Installer is DCS-7010L, according to the instructions.)

  ---

  I am trying to access the DLink camera’s video feed through OpenCV.

  I can access the camera through it’s IP address with a browser without any issues. Unfourtunately ; my program is less cooperative. When attempting to access the camera the program gives the OpenCV-generated error :

  warning : Error opening file (../../modules/highgui/src/cap_ffmpeg_impl.hpp:529)

  This error occurs with just about everything I try that doesn’t somehow generate more problems.

  For reference - the code in OpenCV’s cap_ffmpeg_impl.hpp around line 529 is as follows :

  522    bool CvCapture_FFMPEG::open( const char* _filename )
  
  523    {
  
  524        unsigned i;
  
  525        bool valid = false;
  
  526
  
  527        close();
  
  528
  
  529    #if LIBAVFORMAT_BUILD >= CALC_FFMPEG_VERSION(52, 111, 0)
  
  530        int err = avformat_open_input(&ic, _filename, NULL, NULL);
  
  531    #else
  
  532        int err = av_open_input_file(&ic, _filename, NULL, 0, NULL);
  
  533    #endif
  
  ...
  
  616    }

  ...for which I have no idea what I’m looking at. It seems to be looking for the ffmpeg version - but I’ve already installed the latest ffmpeg on that computer, so that shouldn’t be the issue.

  This is the edited down version I tried to use as per Sebastian Schmitz’s recommendation :

   1    #include <fstream>                            // File input/output
  
   2    #include <iostream>                           // cout / cin / etc
  
   3    #include                       // Windows API stuff
  
   4    #include                             // More input/output stuff
  
   5    #include <string>                         // "Strings" of characters strung together to form words and stuff
  
   6    #include <cstring>                            // "Strings" of characters strung together to form words and stuff
  
   7    #include <streambuf>                      // For buffering load files
  
   8    #include <array>                          // Functions for working with arrays
  
   9    #include <opencv2></opencv2>imgproc/imgproc.hpp>        // Image Processor
  
  10    #include <opencv2></opencv2>core/core.hpp>          // Basic OpenCV structures (cv::Mat, Scalar)
  
  11    #include <opencv2></opencv2>highgui/highgui.hpp>        // OpenCV window I/O
  
  12    #include "opencv2/calib3d/calib3d.hpp"
  
  13    #include "opencv2/features2d/features2d.hpp"
  
  14    #include "opencv2/opencv.hpp"
  
  15    #include "resource.h"                     // Included for linking the .rc file
  
  16    #include                             // For sleep()
  
  17    #include <chrono>                         // To get start-time of program.
  
  18    #include <algorithm>                      // For looking at whole sets.
  
  19
  
  20    #ifdef __BORLANDC__
  
  21      #pragma argsused
  
  22    #endif
  
  23
  
  24    using namespace std;                      // Standard operations. Needed for most basic functions.
  
  25    using namespace std::chrono;              // Chrono operations. Needed getting starting time of program.
  
  26    using namespace cv;                           // OpenCV operations. Needed for most OpenCV functions.
  
  27
  
  28    string videoFeedAddress = "";
  
  29    VideoCapture videoFeedIP = NULL;
  
  30    Mat clickPointStorage; //Artifact from original program.
  
  31
  
  32    void displayCameraViewTest()
  
  33    {
  
  34      VideoCapture cv_cap_IP;
  
  35      Mat color_img_IP;
  
  36      int capture;
  
  37      IplImage* color_img;
  
  38      cv_cap_IP.open(videoFeedAddress);
  
  39      Sleep(100);
  
  40      if(!cv_cap_IP.isOpened())
  
  41      {
  
  42          cout &lt;&lt; "Video Error: Video input will not work.\n";
  
  43          cvDestroyWindow("Camera View");
  
  44          return;
  
  45      }
  
  46      clickPointStorage.create(color_img_IP.rows, color_img_IP.cols, CV_8UC3);
  
  47      clickPointStorage.setTo(Scalar(0, 0, 0));
  
  48      cvNamedWindow("Camera View", 0); // create window
  
  49      IplImage* IplClickPointStorage = new IplImage(clickPointStorage);
  
  50      IplImage* Ipl_IP_Img;
  
  51      
  
  52      for(;;)
  
  53      {
  
  54          cv_cap_IP.read(color_img_IP);
  
  55          IplClickPointStorage = new IplImage(clickPointStorage);
  
  56          Ipl_IP_Img = new IplImage(color_img_IP);
  
  57          cvAdd(Ipl_IP_Img, IplClickPointStorage, color_img);
  
  58          cvShowImage("Camera View", color_img); // show frame
  
  59          capture = cvWaitKey(10); // wait 10 ms or for key stroke
  
  60          if(capture == 27 || capture == 13 || capture == 32){break;} // if ESC, Return, or space; close window.
  
  61      }
  
  62      cv_cap_IP.release();
  
  63      delete Ipl_IP_Img;
  
  64      delete IplClickPointStorage;
  
  65      cvDestroyWindow("Camera View");
  
  66      return;
  
  67    }
  
  68    
  
  69    int main()
  
  70    {
  
  71      while(1)
  
  72      {
  
  73          cout &lt;&lt; "Please Enter Video-Feed Address: ";
  
  74          cin >> videoFeedAddress;
  
  75          if(videoFeedAddress == "exit"){return 0;}
  
  76          cout &lt;&lt; "\nvideoFeedAddress: " &lt;&lt; videoFeedAddress &lt;&lt; endl;
  
  77          displayCameraViewTest();
  
  78          if(cvWaitKey(10) == 27){return 0;}
  
  79      }
  
  80      return 0;
  
  81    }
  
  </algorithm></chrono></array></streambuf></cstring></string></iostream></fstream>

  Using added ’cout’s I was able to narrow it down to line 38 : "cv_cap_IP.open(videoFeedAddress) ;"

  No value I enter for the videoFeedAddress variable seems to get a different result. I found THIS site that lists a number of possible addresses to connect to it. Since there exists no 7100 anywhere in the list & considering that the install is labeled "DCS-7010L" I used the addresses found next to the DCS-7010L listings. When trying to access the camera most of them can be reached through the browser, confirming that they reach the camera - but they don’t seem to affect the outcome when I use them in the videoFeedAddress variable.

  I’ve tried many of them both with and without username:password, the port number (554), and variations on ?.mjpg (the format) at the end.

  I searched around and came across a number of different "possible" answers - but none of them seem to work for me. Some of them did give me the idea for including the above username:password, etc stuff, but it doesn’t seem to be making a difference. Of course, the number of possible combinations is certainly rather large- so I certainly have not tried all of them (more direction here would be appreciated). Here are some of the links I found :

  1. This is one of the first configurations my code was in. No dice.
  2. This one is talking about files - not cameras. It also mentions codecs - but I wouldn’t be able to watch it in a web browser if that were the problem, right ? (Correct me if I’m wrong here...)
  3. This one has the wrong error code/points to the wrong line of code !
  4. This one mentions compiling OpenCV with ffmpeg support - but I believe 2.4.6.0 already comes with that all set and ready ! Otherwise it’s not that different from what I’ve already tried.
  5. Now THIS one appears to be very similar to what I have, but the only proposed solution doesn’t really help as I had already located a list of connections. I do not believe this is a duplicate, because as per THIS meta discussion I had a lot more information and so didn’t feel comfortable taking over someone else’s question - especially if I end up needing to add even more information later.

  Thank you for reading this far. I realize that I am asking a somewhat specific question - although I would appreciate any advice you can think of regarding OpenCV & network cameras or even related topics.

  ---

  TLDR : Network Camera and OpenCV are not cooperating. I’m unsure if
  it’s the address I’m using to direct the program to the camera or the
  command I’m using - but no adjustment I make seems to improve the
  result beyond what I’ve already done ! Now my neighbors will go unwatched !