- 1 Glance Architecture
- 2 Glance Security Practices
- 3 Privacy
- 4 Hosted Infrastructure
- 5 Firewalls and Proxies
- 6 Auto Reconnects
- 7 Data Encoding and Streaming
- 8 Encryption
- 9 Call Detail Records
- 10 Cobrowse
- 10.1 Security Architecture
- 10.2 Content Security Policy
- 10.3 Security Considerations
- 10.4 Session Security
- 10.5 Cobrowse Settings
- 10.6 Presence with Multiple Groups
- 11 Screen Share
- 12 Security Q & A
- 12.0.1 When does Glance Screen Share create connections to the Glance service?
- 12.0.2 How much bandwidth does Glance solutions use?
- 12.0.3 How can I get Glance Screen Share’s new version with SSL encryption?
- 12.0.4 How can I configure my firewall to take full advantage of Glance performance?
- 12.0.5 Does Glance Screen Share allow inbound connections from the Internet?
- 12.0.6 Can someone see my screen when I’m not using Glance Screen Share?
- 12.0.7 Can I use Glance solutions over a dial-up or satellite connection?
- 12.0.8 Can I use Glance solutions behind a Network Address Translation (NAT) router or firewall?
- 12.0.9 Can I use Glance solutions behind a firewall or HTTP proxy server?
- 12.0.10 Can I disable remote control or other features in Glance Screen Share?
Get comprehensive security information about how Glance keeps sensitive data private and secure.
Glance delivers reliable and secure applications that NEVER capture, transfer, or store personally identifiable information (PII).
- Do not use proxy services of any kind, including servers or third-party URLs.
- Do not use cookie sharing or cookie session information.
- Do not require software downloads, plug-ins, or onsite installs, nor do they need Java, Flash, or WebRTC to run.
- Do not transfer PII to Glance or anywhere else.
- Always encrypt data (session content) when in motion.
- Never store any data (session content); data is never at rest.
- Leverage SAML/SSO and Active Directory.
- Comply with GDPR.
Glance Security Practices
The most effective way to keep your data private and secure is to focus on the fundamentals, Glance has adopted the following security practices.
Cross Site Scripting Security
The Glance web application is built to resist attack. It uses dedicated web servers and database servers, with all unnecessary features removed to reduce the attack surface. Glance has development policies and tools in place to create code that resists injection, cross-site scripting, and request-forgery attacks.
Glance uses cryptographically random (hard-to-guess) session keys with automatic expiration to resist credential-replay attacks. It stores only hashed passwords, hashed according to current security best practice. Each customer may select their own password-complexity standards. Glance’s architectural design prohibits the downloading or uploading of any data to the session servers.
Glance uses a host-based intrusion detection system to identify suspicious behavior. Server updates and patches are applied in accordance with the severity of the issues they address both weekly and monthly. Because attack vectors are always evolving, Glance tests its application for vulnerabilities at least twice a year with the latest version of tools such as BurpSuite and ZAPScan. All vulnerabilities are repaired as they are uncovered. Security policies are endorsed by the CTO.
Glance Networks stores the session details from any given session. Glance only stores session metadata and does not store any data from the session itself.
Glance stores the following session metadata:
- start time
- stop time
- number of guests that join the session
- the first guest’s approximate location based on the public IP address
- the Glance URL (Agent Glance Address)
- the Session Type (whether a Cobrowse or a Screenshare session)
Internal Glance Monitoring
If requested by a customer via written correspondence, an authorized Glance Super-user can join an active session for the purpose of testing or monitoring activities. Glance requires the unique session ID and the Glance user address to locate and join that session. We do not actively monitor any sessions and make it a practice to not join any session unless otherwise required by our customers.
Glance cobrowsing has the capability to escalate sessions from one-to-one to many-to-one. This enables an agent to invite another authorized agent to join the in-process Cobrowse session. Doing this means the agent may escalate the conversation from one agent to two agents and have a soft handoff with the end-customer.
Prepared for GDPR
The European Union has implemented the General Data Protection Regulations (GDPR), invoking tough new rules on how enterprises gather and use EU citizen information so consumers can have better control of their personal data. Glance has taken every effort to ensure that it complies with these stringent requirements, to ensure the protection of your data.
Personally Identifiable Information (PII)
Glance’s systems are built so that, in most cases, PII never touches Glance servers and is never stored.
Contents of Glance Sessions (Screen Sharing, Cobrowsing, and Video) are never recorded or stored on Glance’s servers. The session data itself is encrypted while in motion across networks.
We do not store user passwords. Instead, we store password hashes. Our hashing scheme uses industry best practices to make it very difficult to guess passwords from stored hashes. Still, Glance strongly encourages you to use industry-standard Single Sign-on (SSO) mechanisms, such as SAML 2.0, to eliminate the need for Glance to store passwords.
You can mask sensitive user information that may appear during a session, such as credit card number or taxpayer identification number. The contents of masked elements never touch the Glance service, ensuring complete privacy.
While some companies may ask for your name, telephone number, email address, or other sensitive personal information, Glance does not. In general, an IP address is the only information Glance needs to make the service operate. Glance automatically purges these IP addresses after three months using secure deletion methods. Names, telephone numbers, and email addresses gathered on behalf of Glance customers are automatically purged after six months.
Data Privacy Rule
Glance follows a simple data-privacy rule: the personal data of the users of the businesses they serve (Glance customers) belongs to them. Glance fully supports your rights to privacy, and is a strong advocate of an individual’s ability to control their information.
Glance keeps up with evolving privacy regulations. Glance is a certified Privacy Shield organization under US Department of Commerce rules, and a Level 1 Validated PCI DSS (Payment Card Industry Data Security Standard) Compliant Service Provider.
At any time you can ask Glance about your information that is held in our system, or you can ask to have it erased. Simply send an email to firstname.lastname@example.org.
Glance values work done by security researchers in improving the security of our products and service offerings. We are committed to working with this community to verify, reproduce, and respond to legitimate reported vulnerabilities. We encourage the community to participate in our responsible reporting process.
If you are a security researcher and would like to report a security vulnerability, please send an email to email@example.com. Please provide your name, contact information, and company name (if applicable) with each report. Priority will be granted to encrypted reports – please include your PGP public key with such reports.
Responsible Disclosure Guidelines
We will investigate legitimate reports and make every effort to quickly correct any vulnerability. To encourage responsible reporting, we commit that we will not take legal action against you or ask law enforcement to investigate you if you comply with the following Responsible Disclosure Guidelines:
- Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and a Proof of Concept (POC)
- Make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our services
- Do not modify or access data that does not belong to you
- Give us a reasonable time to correct the issue before making any information public
Glance will attempt to respond to your report within 48 hours.
Glance’s session load is spread across two data centers, located near Boston, MA and Oakland, CA, and several remote nodes, including London, Paris, Singapore, Taipei and Sao Paulo. Each session is assigned to a server geographically close to the session’s host, to minimize path latency. Sessions at each location are balanced across its pool of available servers.
Glance’s distributed architecture ensures there is no single point of failure. Should one server or even an entire data center drop offline, the remaining infrastructure assumes the load. Sessions that were running on a failed server will drop, but hosts typically can restart them within a minute.
Glance’s two main data centers are managed by Internap.com. Internap connects the Glance service directly to multiple major ISPs and avoids network bottlenecks by dynamically assigning each connection to the lowest latency route. Physical access to the Glance servers is restricted to authorized personnel (photo and biometric IDs required) and is monitored 24/7 by archived video and on site security personnel.
All production servers are hardened. Non-essential services are disabled and security patches applied as appropriate. Remote management is by secure SSH only, from pre-authorized IP addresses.
Firewalls and Proxies
Glance Screen Share automatically senses and works with most proxy server and firewall configurations, without needing adjustments by technical staff and by identifying the best protocol for each participant’s network environment. Nearly anyone who can surf the web should be able to connect.
Each participant reaches the Glance Screen Share service with an outward-bound connection, using TCP/IP to destination port 5500 (or 5501 with TLS). If that attempt is denied or times out, Glance Screen Share tunnels HTTP to port 80 (or HTTPS to 443). Since TCP is more efficient than HTTP, a company that blocks ports 5500 and 5501 might consider adding a rule to their firewall policy that allows outbound connections to those ports at glance.net. Glance Screen Share does not use peer-to-peer technology.
Some Glance participants may have slow or unreliable Internet connections, due to a weak wireless signal, spotty mobile service, an unresponsive proxy server, or an interfering network security device.
If the connection drops or times out, Glance automatically attempts to reconnect. Should the problem persist, Glance tunnels over HTTP/HTTPS.
Data Encoding and Streaming
Glance Screen Share’s client software captures and transmits screen content using pixel-based methods. Screen changes are digitally compressed using a proprietary patent-pending codec that minimizes bandwidth and latency, while preserving sharpness. The compressed data is encapsulated in a proprietary messaging format and forwarded to each session participant.
Glance ensures each participant enjoys the best possible viewing experience, regardless of session size and network condition. Glance continuously optimizes each participant’s data stream to the instantaneous speed of his or her network connection. Guests with fast connections receive as many screen updates as their networks allow. Those on slower links may need more time to receive updates, but they never fall behind.
To minimize path latency, Glance provisions each session on a server that is geographically close to the host. All session data flows through that server. If the session is encrypted, Glance uses TLS/SSL to secure all connections between participants and server.
All Glance Screen Content is Live
All content is live. Presenters do not upload documents or presentations beforehand. No document or file transfer is allowed. No executable code from participant computers is sent. No session content is recorded.
During remote control in a screen sharing session, the remote (controlling) computer sends its pointer’s relative position, mouse actions and keystrokes to the current presenter’s computer, which interprets that data locally. Clipboard commands only use each local computer’s clipboard content. Clipboard content cannot be shared.
When a session ends, any transient data cached in the Glance service’s virtual memory is deallocated. Only call detail records (CDRs) and log files (for debugging) persist. Neither contain session screen data.
All audio is communicated live by phone. Participants may use either their own service provider or the free Glance phone conferencing service, which is fulfilled by a Glance partner, iotum, over the Public Switched Telephone Network.
Glance adds the ability to encrypt all session traffic between each participant and the Glance service using IETF industry-standard Transport Layer Security and Secure Sockets Layer (TLS/SSLv3) technology.
Each participant’s computer or mobile device uses TLS to negotiate the connection’s CypherSuite and key length. Glance also sends each participant a digital certificate, signed by DigiCert or Thawte. The participant’s browser can pass it to a certificate authority to validate Glance’s identity before proceeding. Each connection is then encrypted using the strongest method the corresponding participant supports. SSLv2 is not allowed.
Any participant that cannot establish a secure connection to an encrypted session is denied entry. Encryption can be enabled on a session-by-session basis by the host. Alternatively, the administrator can mandate that all sessions hosted by the group’s users be encrypted.
Call Detail Records
Glance archives various metrics about each session:
- Each participant’s IP address and inferred geographic location.
- Each participant’s entry and departure times, and total duration.
- Guest’s contact info (name, email address, phone), when supplied.
The session host or his group’s administrator can view or download these records in CSV format by logging into the My Account area. These metrics cannot be edited or altered. All My Account browser sessions are secured by HTTPS.
Glance Cobrowse sessions allow one or more customer service agent(s) to view the web browsing activity of visitors to a website. Agents see exactly what a visitor sees in their browser, with the exception of the contents of designated masked fields.
When a Cobrowse session starts, a customer will click a button or link that references the “cobrowsescript” ID, which sends a “startSession” call through to the GlanceCDN. After authorization, the GlanceCDN sends the Cobrowse.js down to the website that initiated the session.
Cobrowse.js passes the customer group ID, and receives a unique session ID, a CServer assignment, and customer settings including masked fields.
The session ID is comprised of three components:
- Customer group ID
- Session key
- A randomly generated number to disambiguate that session from other sessions
Cobrowse.js stores the session ID and randomly generated number, along with the set of masked fields in a browser session cookie, and proceeds to start uploading session data to the designated CServer. The CServer, in turn, posts a message to the Glance web server to record the fact that the session has started in the database.
Both group ID and session key are required to join a session.
Once logged in, the group ID can be determined based on the agent’s Glance group membership.
Session keys can be specified on the agent side. For example, you can specify session keys in the following ways:
- a randomly assigned string, or might be
- some piece of information associated with the visitor, such as a user id or a tracking cookie ID.
- The agent might enter the session key manually, or it might be extracted automatically for the agent from data in a CRM record.
Once a session key has been specified, the agent opens a browser window to the URL:
If not logged in, the agent is prompted to log in and is then redirected back to this agent view. AgentView.aspx looks up the session in the database by agent group ID and session key and redirects the agent to the appropriate CServer. The CServer delivers the HTML representation of the Document Object Model to the agent’s browser, which then distills the HTML as if it was a website.
The CServer sends only HTML markup for the browsing session to the agent browser.
Resources referenced by the session HTML, such as images or style sheets, are downloaded by the agent directly from the customer website or its content delivery network. This lets the agent enjoy the best possible cobrowsing performance.
Content Security Policy
The Cobrowse service collects and transmits potentially sensitive visitor browsing information, and has therefore been designed with security as the highest priority. The following security considerations are addressed by the Cobrowse architecture.
Secure Agent View
When an agent attempts to join a session, a Glance web server looks up the session based on the agent’s Glance group ID and the supplied session key. If a matching session is found, the web server returns the session ID signed using a secret “server key.” The server key is a 256-bit number that is known only to the CServer and web server; a new server key is generated every 60 seconds. When an agent is redirected to the CServer to view the session, the CServer verifies the signature and only allows the agent to join if the signature is valid.
Once the agent has joined the session, a secure (flagged for HTTPS only) session cookie is used to maintain the agent session. The agent session cookie contains the session ID signed using a secret key known only to the CServer. The CServer secret key is generated at runtime and does not persist anywhere.
If the account is configured with the agent’s protocol following the visitor’s, then two agent session cookies are created, one HTTPS only and the other for HTTP. The HTTPS-only cookie is required to view any secure pages. An attacker who might have obtained the HTTP cookie will not be able to use it to view secure pages.
Websocket connections from the agent also pass the agent session cookie value when the connection is first established. The CServer only accepts websocket connections to a given session if the request includes a valid agent session cookie value.
No browsing session data is ever served by the CServer without a valid agent session cookie attached to the request. This guarantees that only agents who have a registered Glance account with a particular company are able to view sessions started by visitors to that company’s website.
Secure Data Transmission
Using HTTPS (specifically: TLS 1.1 or better) or secure websockets for all communication ensures that all data is transmitted securely to servers whose identity has been verified. This includes:
- Communicating between cobrowse.js and the Glance web server.
- Websocket/ajax communicating between cobrowse.js and the CServer.
- Communicating between the CServer and the Glance web server.
- Websocket communicating between AgentView.js and the CServer.
- Downloading visitor session resources from the customer website to the agent browser.
Any HTML input field can be masked from the Agent and Glance service.
Masked fields can be identified two ways:
- Glance always masks any input field having a glance_masked attribute.
Example: <input type=”text” class=”glance_masked” value=”hello”/>
<input type=”text” glance_masked=”true” value=”hello”/>
2. A customer can configure their service to mask fields on-the-fly, without modifying
their website. The fields are identified using standard CSS selectors.
Example: <input type=”text” id=”greeting” value=”hello”/>
can be masked with the ID CSS selector
#greeting // [id=’greeting’]
These masked field definitions cannot be compromised, as they are stored in Glance’s secure database and retrieved by the visitor’s browser over a secure connection to a Glance web server.
The contents of masked fields never leave the visitor’s browser, so there is no possibility of this data being intercepted in transit or accessed from the CServer – even by an agent possessing a legitimate session cookie. Effectively, Glance technology never touches the contents of a masked field.
Each Cobrowse server is a standalone hardened Unix server with all superfluous services disabled. The server runs its own native firewall configured to allow incoming traffic only on secure port 443. No session data persists in any file or database on the CServer. Additionally, there are no per-agent restrictions within a group. However, roles can imply per-agent restrictions in a group.
Short Session Key
The session key allows an agent to identify a particular visitor’s session. The key is usually short being only four to six digits, so it’s easy for the visitor to read and say over the phone.
The session key is not a part of the security model, since the visitor’s browser stores the key in an insecure cookie. It can be vulnerable when uploaded unencrypted to a web server when the visitor navigates to an insecure page on the customer website.
Agent HTTP for Websites Distributed over a Content Delivery Network
If the agent session strictly uses HTTPS to access visitor session data, the agent browser will request all resources, such as images and stylesheets using HTTPS. Some website implementations, particularly those using a content delivery network, cannot deliver all resources over HTTPS.
To work around this, Cobrowse can be configured to allow the agent protocol to follow the visitor protocol, so that when the visitor navigates to an HTTP page, so does the agent, and vice versa. Two separate session cookies are maintained on the agent side, a secure cookie for viewing HTTPS pages, and a non-secure cookie for viewing HTTP pages. While the non-secure cookie provides a minimum level of security, the agent’s view of a non-secured page is not protected from traffic sniffing.
Once a session is started with a particular group ID, any agent with a Cobrowse subscription within that group will be able to view the session. Therefore it is important to ensure that sessions can only run in groups that are explicitly allowed by the website authors.
Any time a session is started or continued (via the API, a window message, Presence, or continued after navigating or after crossing a domain boundary or when a page gets focus) there is a check to ensure that the group ID either matches data-groupid or is in the data-additionalgroupid list.
All Cobrowse settings are specific to the group in which the session runs, including:
- Masked elements
- Trusted domains for cross domain Cobrowse
- Trusted domains for invoking Cobrowse from a “chat” window
Presence with Multiple Groups
Presence always uses the group specified in data-groupID. So an agent wanting to join a session via Presence needs to be a member of both the first group in the list and the group in which the session is started.
Glance Screen Share allows agents to view a visitor’s entire screen, not just specific company webpages. Agents see exactly what a visitor sees on their screen.
Screen Share collects and transmits potentially sensitive visitor information, and has been designed with security as the highest priority. The following describes security considerations that have been addressed by the Screen Share architecture.
Roles and Privileges
During a Screen Share session, security is maintained by constraining a participant’s privileges by role: Host, Guest or Presenter. Additionally, each Glance user belongs to a group, which has at least one Administrator.
Only Glance users with a valid subscription can start (or host) a session.
The host’s privileges include:
- Deciding who joins the session, by verbally inviting them during a phone call or sending a link to the session by email, chat, Twitter or Facebook.
- Making the 4-digit session key random (for private on-the-fly sessions), assigned (for scheduled sessions), fixed (for convenience) or not required (for instantly joining non-private sessions).
- Choosing what contact info (name, email, phone) might be requested when a guest joins a session, and whether the data is required or optional.
- Controlling which monitor is shown (so private content can be kept out of view on another screen).
- Hiding the screen (to view something privately).
- Sharing control of the host’s mouse and keyboard with all participants (but always retaining priority).
- Starting a session to view or optionally control the first guest’s computer (for remote tech support).
- Allowing guests to show their screens.
- Ending the session for everyone.
Whenever the host starts a session, at least one guest must join within 10 minutes. Otherwise the session expires, limiting the chance the host leaves the session running.
The host can end a session at any time. It also ends when the last remaining guest leaves, like a phone call.
All other session participants are guests. They join the session using their favorite browser, from any PC, Mac or mobile device. (Guests on mobile devices connect instantly, without having to download an app.)
With permission, a guest can:
- View the presenter’s screen.
- Remotely share control of the presenter’s mouse and keyboard.
Guests may leave a session at any time.
A presenter is the person (Host or Guest) currently showing their screen. Any session participant (on a PC or Mac) who installed the Glance software before joining a session can (with the host’s permission) become a presenter. The software is free and can be download here. Presenting participants do not need a Glance subscription.
With the host’s permission, a presenter’s privileges include:
- Showing (or hiding) their screen at any time.
- Controlling which monitor to show (so private content can be kept out of view on other screens).
- Sharing the mouse and keyboard with all participants (while always retaining priority).
Presenters may leave a session at any time.
Every Glance user belongs to a group. A group’s administrator determines which privileges are granted to all group members.
These privileges include:
- Letting session guests show their screens.
- Letting presenters share their mouse and keyboard with guests (for remote pointing and technical support).
- Letting users start “View guest’s screen” sessions (for remote tech support and training).
- Mandating what contact info (if any) guests must provide before joining a session.
- Allowing keyless sessions (so guests can browse directly into a session).
- Forcing all sessions to be encrypted (Glance 2.7 and above).
For example, a company might assign inside sales people to a group that can start keyless sessions, while placing tech support agents in a separate group that requires keys and makes each guest provide an email address.
Administrators can also add/change/drop users and update account billing information.
Glance session participants authenticate with the Glance service in different ways, depending upon their role.
Anyone hosting a session needs to install Glance’s client software beforehand on their PC or Mac. (Glance sessions cannot be hosted today from mobile devices.) The download is about 1.5 MB. The PC version includes a standard uninstaller. When running, the software places a G icon in the computer’s system tray (PCs) or menu bar (Macs). It connects to the Glance service only during a session.
Each Glance user has a personal Glance Address (URL) name.glance.net and password. The user must supply both (via SLL) before they can host a session. Users can be constrained to choose passwords that match criteria describable by a regular expression.
The host’s computer locally stores an encrypted version of the password. Subsequent sessions can then start with just a click. The host’s computer silently authenticates its login credentials with the Glance service (via SSL), which confirms the credentials, assigns the session to a Glance server, and allows guests to join.
If a person wants to use a different Glance address to host a session, the person must provide the associated password.
A user who has forgotten a password can reset it by clicking a link in an email sent by Glance to the account’s associated email address. An administrator can also set and change passwords for the group’s users.
The host can adjust how much “friction” guests experience when joining a session.
Often the host just verbally invites people to browse their Glance address and enter the session’s four-digit key.
Alternatively, the host can send invitees a session link in an email, text message or calendar invite, or post it to followers and friends on Twitter or Facebook. The four-digit key can be random (default behavior), assigned by the host (so it can be announced ahead of time), fixed (for convenience) or not required (for even faster joining).
The host can also specify what contact info (name, email, phone) each guest is asked to provide and whether it is required or optional. The data becomes a part of the call detail record of attendees, which the host cannot alter.
The host (or their Administrator) can view or download guest contact info by logging into Glance’s My Account area.
Additionally, each Glance for Salesforce implementation automatically uploads attendee contact info into the session’s corresponding Salesforce Activity record, and optionally creates Lead objects for unrecognized participants.
Many companies use Glance Screen Share for remote technical support. An agent can start a session to view a person’s screen or view and control the person’s screen. In either case, Glance uses an ActiveX control, browser plug-in or Java to install a thin client (download is under 1.5 MB) on the Guest’s PC or Mac. Guests typically do not need administrative privilege to install the client.
While connecting, Glance Screen Share asks the guest to allow the session’s host to view (or control) his computer screen. (Refusing the request terminates the session and uninstalls the client.) Once connected, Glance then posts a prominent Leave button so the guest can confidently end the session at any time.
A person must be present at the remote computer to grant access and join each support session. Glance Screen Share cannot auto-reconnect after a guest reboot, nor can it be used for unattended remote access.
During Remote Control
During remote control, the guest retains priority over their mouse and keyboard. The guest can also click the G icon that appears to control other aspects of the session.
The agent can coach the guest by taking turns showing their own screen. If needed, the agent can escalate the case, inviting other technicians to join the session and share remote control.
Ending the Remote Control Session
Glance Screen Share auto-uninstalls after each remote support session to a PC, unless the guest chooses otherwise. Keeping the software lets a returning guest connect instantly, by skipping the brief download step.
Regardless, Glance Screen Share never leaves icons on the guest’s desktop, system tray, dock or menu bar.
Security Q & A
Here are some answers to common security questions.
Glance is only connected during a session.
How much bandwidth does Glance solutions use?
Glance solutions use bandwidth only during a session. Traffic tends to burst up to hundreds of kilobits-per-second for several seconds whenever the screen being shown changes. As soon as the updates are sent, traffic returns back to near zero. Most Glance sessions average about 50 to 80 kbit/s, comparable to active web surfing. All traffic flows through the Glance servers.
To get the latest version with SSL encryption, follow these steps:
- Download the latest version:
For Windows PCs click here.
For Macs click here.
- Once installed, click on the G icon.
- Select Settings.
- Under the Options tab, scroll down to During my sessions.
- Check the box Encrypt my sessions.
How can I configure my firewall to take full advantage of Glance performance?
Have your IT specialist add a rule that allows outbound TCP/IP connections to destination ports 5500 and 5501 and HTTP connections to destination ports 80 and 443 on Glance servers in the domain glance.net.
Alternatively, apply the rule to these address blocks (last updated 8 Feb 2018):
|IP Range||CIDR||Subnet Mask|
|35.176.92 – 188.8.131.52||184.108.40.206/29||255.255.255.248|
|220.127.116.11 – 18.104.22.168||22.214.171.124/29||255.255.255.248|
|126.96.36.199 – 188.8.131.52||184.108.40.206/27||255.255.255.224|
|220.127.116.11 – 18.104.22.168||22.214.171.124/28||255.255.255.240|
|126.96.36.199 – 188.8.131.52||184.108.40.206/28||255.255.255.240|
|220.127.116.11 – 18.104.22.168||22.214.171.124/27||255.255.255.224|
|126.96.36.199 – 188.8.131.52||184.108.40.206/27||255.255.255.224|
|220.127.116.11 – 18.104.22.168||22.214.171.124/29||255.255.255.248|
|126.96.36.199 – 188.8.131.52||184.108.40.206/27||255.255.255.224|
|220.127.116.11 – 18.104.22.168||22.214.171.124/28||255.255.255.240|
|126.96.36.199 – 188.8.131.52||184.108.40.206/29||255.255.255.248|
|220.127.116.11 – 18.104.22.168||22.214.171.124/29||255.255.255.248|
|126.96.36.199 – 188.8.131.52||184.108.40.206/29||255.255.255.248|
|220.127.116.11 – 18.104.22.168||22.214.171.124/29||255.255.255.248|
No. Glance software only makes outbound connections that you initiate by starting a session.
No. For someone to see your screen using Glance, the following must happen:
- You must manually start a Glance session by clicking the G icon and selecting the start session prompt.
- Once you start the session, a guest has to visit your Glance web page and know the session key.
Can I use Glance solutions over a dial-up or satellite connection?
Sure. But because dial-up and satellite data speeds are much slower than broadband, it will affect how fast your guest(s) receive updates. Glance will send your screen changes as fast as your network connection allows and your guests will receive the changes as fast as their network allows.
Can I use Glance solutions behind a Network Address Translation (NAT) router or firewall?
Yes. Glance works reliably through most NAT routers/firewalls.
Can I use Glance solutions behind a firewall or HTTP proxy server?
In most cases, yes. When you start a session, Glance attempts to connect to our servers using TCP/IP to destination port 5500. If it cannot connect to this port, Glance attempts to “tunnel” through the firewall via HTTP to destination port 80.
Glance automatically chooses the best of several web browser technologies to help guests connect to sessions. Guests either connect to destination port 5500 or tunnel HTTP to destination port 80.
Glance is constantly improving its ability to connect immediately and reliably. If you encounter a problem connecting, please contact us.
In the My Account area, a Glance administrator can control which features users can access.
- Allow remote control
- Host sessions without a session key
- Specify what guest information is required, optional, or not shown
- Allow guests to show their screens back to the host
- Start sessions to view a guest’s screen
To log in to the My Account area:
- Click the My Account link.
- Log in using the Glance Administrator’s Glance Address and Password. (Forgot your password? Click here to find out how to reset it.)
- Click the Settings tab.
- In the Privileges and Settings section, uncheck (or check) the privilege you want to disable (or enable).
- Click Save Changes.
Tip: These settings will apply to all users in your group.