macOS Big Sur telling Apple what app you've opened isn't a security or privacy issue

Posted:
in macOS edited November 2020
Even before Apple confirmed that Gatekeeper "calling home" wasn't associated with user information on Sunday night, privacy concerns of bad actors theoretically monitoring app launches with that data are not an issue as one researcher has suggested. Here's why.

macOS Big Sur is under fire for a security feature that has existed for years before its release.
macOS Big Sur is under fire for a security feature that has existed for years before its release.


On Thursday, macOS users reported issues trying to upgrade the operating system to macOS Big Sur, while others ended up having trouble running applications even without upgrading. The problem was determined to be server-related, with an issue on Apple's side preventing Apple's certificate checking function from working properly.

That same service has been picked up by security researcher Jeffrey Paul, founder of an application security and operational security consulting firm. In a lengthy piece written on Thursday, Paul attempted to raise awareness of a perceived privacy issue within macOS, namely that it seemingly reports back to Apple what apps are being opened up by a user.

According to Paul, Apple's communications between the Mac and specific servers can be coupled with data stemming from an IP address in such a way that it can create a mass of metadata about a user's actions. This would include where they are and when, as well as details of their computer and what software they're running.

By collecting this data over time, this can supposedly create an archive that could easily be mined by bad actors, giving what could be considerable abilities to perform surveillance on a mass scale, possibly levels to the infamous and now shut down PRISM surveillance program.

The problem is, it's nowhere even close to that dramatic, and nowhere near that bad. And, if they were so inclined, the ISPs have the ability to harvest way more data on users with just general Internet usage than Gatekeeper ever surrenders.

How Gatekeeper works

Apple includes various security features in its operating systems, and macOS is no exception. To prevent the potential use of malware in apps, Apple requires developers to undergo various processes to make the apps function on macOS.

Along with creating security certificates, which can help confirm an app from a developer is authorized and genuine, Apple also mandates that apps undergo a notarization process. Registered developers send apps to Apple, which are scanned for security issues and malicious code, before being given the OK by the company.

Apple introduced the notarization process to developers in 2018
Apple introduced the notarization process to developers in 2018


This means that apps are typically protected by being signed by a Developer ID that Apple is aware of, as well as being checked by Apple itself, before being able to be run in macOS itself. Signed security certificates identify the app's creator as authorized, while notarization minimizes the chance of an app executable being modified to carry malware.

Security certificates applying to an app or a developer can be revoked at any time, allowing for the quick deactivation of apps that are known to have malware or have gone rogue in some way. While this has led to issues in some cases, such as certificates expiring and causing apps to fail until developers renew them with a new version of the app, the system has largely been a success.

A communications breakdown

The problem area here is in how Gatekeeper, the security feature that manages this form of security, actually performs the task in the first place. As part of the process, it communicates with Apple's Online Certificate Status Protocol (OCSP) responder, which confirms certificates for Gatekeeper.

This communication involves macOS sending over a hash, a unique identifier of the program that needs to be checked.

A hash is a known string of characters that can be created using an algorithm on a block of data, such as a document or an executable file. It can be an effective way of confirming if a file has been meddled with since the hash generated from the adjusted file will almost certainly differ from the expected hash result, indicating something went wrong.

Hashes are created from the application file in macOS and sent to the OCSP for checking against the hash for the application it knows about. The OCSP then sends a response back, typically whether the file is genuine or if it has been corrupted in some way, based just on this hash value.

The failure to execute software in macOS or to perform the upgrade was caused due to the OCSP being overwhelmed by requests, causing it to run extremely slowly and not provide adequate responses in return.

Making a hash of things

Page reasons that these known hashes effectively report back to Apple what you are running and when. Furthermore, when mapped to an IP address for basic geolocation and being connected in some form to a user ID, such as Apple ID, this can enable Apple to "know when you open Premiere over at a friend's house on their Wi-Fi, and they know when you open Tor Browser in a hotel on a trip to another city."

Apple's theoretical knowledge is one thing, but Page points out that these OCSP request hashes are transmitted openly and without encryption. Readable in the open by anyone analyzing packets of data, this information could be used in the same way by an ISP or "anyone who has tapped their cables," or has access to a third-party content delivery network used by Apple, to perform PRISM-style monitoring of users.

"This data amounts to a tremendous trove of data about your life and habits, and allows someone possessing all of it to identify your movement and activity patterns," writes Page. "For some people, this can even pose a physical danger to them."

It is plausible for someone to determine what application you ran at a specific time by analyzing the hash and having enough hashes at your disposal to figure out which hash means. There are many tools available to security experts to analyze hashes, so it wouldn't be unreasonable for someone with sufficient resources, data storage, and computing power to do the same.

However there's not really much utility in knowing just what app is being launched, realistically speaking. And, the ISPs could have that data if they wanted to without the limited info that Apple's Gatekeeper may provide.

For the majority of these hashes, it will consist of largely unusable data, even if it is identifiable, due to the genericness or the high use cases of some apps. There's not much information you could gather on a user by knowing they launched Safari or Chrome, as the hash states the app but not what they are looking at.

It's doubtful that any nation state would care if they see someone opened up macOS' Preview app 15 times in a row. There's certainly edge cases, such as for applications with highly specific uses that may be of interest to third parties, but they are few and far between, and it would probably be easier to gather data through other means rather than acknowledging an app has opened.

You don't have to look at the hashes to work out what the target user is running. Since applications tend to run on specific ports or port ranges, anyone who is in the same position of monitoring packets of data can similarly determine what application has just been run by checking what ports the data relates to.

For example, port 80 is famously known to be used for HTTP, or your standard web traffic, while 1119 can be used by Blizzard's Battle.net for gaming. Arguably you could change the port that an application communicates through, but on a mass surveillance basis, its operators are going to be looking out for port 23399 as a sign for Skype calls, or 8337 for VMware.

When traffic to and from 1119 stops, for instance, then the ISP could figure out that you're done playing Warcraft. Gatekeeper doesn't do this.

Sure, there's theoretically potential for a PRISM-style spying program here with the entirety of ISP data plus port monitoring. But, it's of extremely low utility to those who would want to set up such a thing.

"User 384K66478 has opened Runescape at 18:22" which is the absolute most that Gatekeeper could expose, is of no help to anybody.

It's not entirely new, nor is it secret

It is worth pointing out that this potential use case for data isn't something that is a recent issue for Apple users. Apple has employed Gatekeeper to check certificates with server-based confirmation since it was first implemented in 2012, so it has been active for quite some time already.

If it were a privacy problem as framed by Paul -- and it isn't -- it would have been one for quite a few years.

The system of using online servers to confirm the validity of an app isn't even limited to macOS, as Apple uses a similar validation process for the iOS ecosystem. There's even enterprise security certificates that allow apps to bypass Apple's App Store rules in small quantities, but even they are revokable in a similar fashion, as demonstrated by Facebook in early 2019.

Microsoft has its own Device Guard, security features in Windows 10 to fight malware that take advantage of code signing and sending hashes back to Microsoft to enable or deny apps from running. Part of this entails communicating with servers to confirm whether apps are signed correctly.

Paul also frames the feature as being a largely secretive thing that users aren't aware about, something that could surreptitiously be used to monitor usage habits. However, given that there's so many companies collecting data on users, such as online advertising firms and social networks, it would probably be unsurprising to most users that dispatches to Apple regularly take place, especially for security reasons.

Ungraceful failure and "unblockable" messaging

One element that Paul latches onto is how Apple is introducing a change as part of macOS Big Sur that alters how the system functions. In previous versions of macOS, it was possible to block the requests to the OCSP from the daemon "trustd" by a firewall or by using a VPN, enabling the system to "fail quiet."

The hash-checking system normally sends the hash to OCSP and expects two responses: an acknowledgment of receipt of the hash followed by a second that either approves or denies the hash as genuine. If the first acknowledgment is received, trustd will sit and wait for the second response to come through.

The issue that played out on Thursday was this precise scenario, as the acknowledgments were sent, but the second part was not. This led to applications failing to launch as approval was supposedly on the way, but didn't arrive.

Hey Apple users:

If you're now experiencing hangs launching apps on the Mac, I figured out the problem using Little Snitch.

It's trustd connecting to https://t.co/FzIGwbGRan

Denying that connection fixes it, because OCSP is a soft failure.

(Disconnect internet also fixes.) pic.twitter.com/w9YciFltrb

-- Jeff Johnson (@lapcatsoftware)


This plays into Paul's declaration as blocking access to the OCSP means the initial request cannot reach the server, meaning there's no initial acknowledgment nor approval. Since the issues lie in receiving the acknowledgment in the first place, blocking access prevents the acknowledgment from being sent from the server, negating the issue.

The "fail quiet" element is beneficial to the user as the entire system will allow the app to run anyway, as it's not been informed by the seemingly-offline OCSP, and so continues as normal.

A reference is made to Jamf principle security researcher Patrick Wardle, who determined Apple added trustd to the "ContentFilterExclusionList," a list of services and other elements that cannot be blocked by on-system firewalls or VPNs. Since it's unblockable, an attempt to contact OCSP will always be made, which means the Mac will always phone home.

Of course, this isn't something that is entirely unblockable. Offline Macs cannot use the security facility, and for those that are online, there's the possibility of using filtering rules on a home router or on a corporate network to block that specific traffic, and there are feasibly ways to do similar blocking on the move using a travel router.

Hashing it out

If this all surfaced at around the time PRISM was still a thing to be concerned about, it would be worth caring more about. More data for the metadata-consuming surveillance machine to ponder over, and more information for governments to use about its citizens.

But, obviously, it's not. Time has passed, PRISM is no more and has been gone for over a year, and the general public are extremely aware that data is being created every day based on people's activities and actions. Users have lost their innocence and are no longer ignorant to the situation they find themselves in.

Dressing this up as a potential leak of personal data may have made sense a few years ago, but not now.

Given the information is basically the small possibility someone online determines through considerable work that someone has opened Safari for the 47th time in a day, and it seems like small potatoes. Add in that far more data can be acquired with less effort by ISPs by monitoring ports, and those potatoes are getting tinier.

That you can acquire far better and actionable data through other methods makes this pretty mundane on the grand scale of things. There's not even the prospect of Apple pulling a Google and using this data, as Apple has been a voracious defender of user privacy for many years, and it is unlikely to make such a move.

There's no privacy battle to be made, started, or escalated, here.

Transparency is better

During those two hours on Thursday when Gatekeeper was preventing some users from opening some apps, Apple was silent. It's still silent about the cause, what happened, and why.

Gatekeeper "calling home" is discussed indirectly in Apple's terms of service, but, as with most of its high-visibility failures, it could have been more transparent about it on Thursday. It could have told users what it is doing with the Gatekeeper hashes, instead of making us guess at the time if they are retaining the hashes, or using them and discarding them.

This is something that Apple can easily do, given how open it is about other security features it offers in its products. It is entirely possible for this to be handled in a similar publicly-transparent manner by Apple, such as the introduction of anonymous data sharing in its COVID-19 screening app.

It may be difficult to do so given the vocal opinions insinuating this could be part of a PRISM-like system, but it would be possible. Apple just has to lay it out to the public and offer assurances that there isn't anything untoward taking place -- and a few hours after initial publication of this piece, it did exactly that.

Apple's discussion of the matter

Late on Sunday, Apple published a document about the system. Specifically, it says that the hashes of the apps is associated by developer, and is never linked to an iCloud account or other identifying information.

"Gatekeeper performs online checks to verify if an app contains known malware and whether the developer's signing certificate is revoked," the support document reads. "We have never combined data from these checks with information about Apple users or their devices. We do not use data from these checks to learn what individual users are launching or running on their devices.

While it appears that it may have been logging IP addresses, the company also says that it will stop doing so, and purge them from logs going forward.

"These security checks have never included the user's Apple ID or the identity of their device," says Apple. "To further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs."

To prevent it from happening again, Apple has a plan for the next year. Apple is planning three actions to give more control to the user, and secure the process even further.

Apple certificate verification process improvements scheduled for the next year

  • A new encrypted protocol for Developer ID certificate revocation checks

  • Strong protections against server failure

  • A new preference for users to opt out of these security protections
Update November 15, 10:54 PM ET with Apple's plans and details about what the company does with the Gatekeeper information
«1

Comments

  • Reply 1 of 40
    crowleycrowley Posts: 8,749member
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    cornchipphilboogiewilliamlondonprismaticsavon b7argonautrazorpitrain229secondkox2blurpbleepbloop
  • Reply 2 of 40
    macOS Big Sur telling Apple what app you've opened is both a security and privacy issue if the users consent was not requested or given, period. No amount of sugarcoating will put apple in a credible public defensible situation on this.
    edited November 2020 crowleystevenozcornchipmobirdphilboogieCheeseFreezewilliamlondonargonautrazorpitrain22
  • Reply 3 of 40
    I won’t be upgrading to this mess anytime soon.  
    stevenozcornchipwilliamlondonprismaticsargonautrain22anantksundaram
  • Reply 4 of 40
    Thank you for this timely piece - I was wondering about this yesterday.

    According to the following analysis, the hash that is sent is not unique to the app but only to the developer certificate: https://blog.jacopo.io/en/post/apple-ocsp/
    “- No, macOS does not send Apple a hash of your apps each time you run them.
    - You should be aware that macOS might transmit some opaque information about the developer certificate of the apps you run. This information is sent out in clear text on your network.”
    magman1979cornchipphilboogiewatto_cobra
  • Reply 5 of 40
    crowley said:
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    As usual you provide your obtuse anti-Apple BS right on queue, and are usually first to comment, I think you must be getting paid to provide first-in-line negative responses to pour your special brand of gasoline on a non-existent Apple fire, good god...
    Jarexx said:
    macOS Big Sur telling Apple what app you've opened is both a security and privacy issue if the users consent was not requested or given, period. No amount of sugarcoating will put apple in a credible public defensible situation on this.
    No amount of sugar coating is required here, as nothing macOS is transmitting is of any relevance, or could be constituted as PII (personally identifiable information). The author of this AI piece is correct, ISP's collect VASTLY larger amounts of PII about us than Apple, as do scummy ad agencies like Google.
    I won’t be upgrading to this mess anytime soon.  
    There is no mess to avoid, you're just listening to fear mongering from ONE overtly paranoid security "expert" who just wants to start another anti-Apple shit storm and forgot to mention what I just did above.
    chasmwilliamlondonwatto_cobraDetnator
  • Reply 6 of 40
    dewmedewme Posts: 3,824member
    So, how is any of this any different than all of the other operating systems that use public key infrastructure (PKI) based on the international standard X.509 certificate model to allow the execution/loading of signed executables and other signed binary (compiled) content? Microsoft has used the same type of PKI, including the same X.509 based certificate model for .Net based applications since the very first version of .Net, which was released publicly in 2002. Google uses a similar X.509 based PKI model. What this means, on all platforms, is that when you ask the OS or runtime (like .Net) to load a binary (usually in conjunction with launching an app), it will check that each binary's certificate is valid with a trusted authority, which in the case of macOS/iOS/iPadOS is Apple. On Windows the trusted authority is Microsoft and on Chrome it's Google.

    One critical function of the certificate check is to verify that the certificate has not been revoked or expired. If a rogue binary is discovered, its certificate can be revoked so the operating system/runtime to refuse to load the rogue binary - potentially saving your bacon. This generally means that the operating system/runtime needs internet access to do the revocation check, but each implementation typically provides ways to run without internet access, for example, providing a local cache (with an expiry) of successful checks, local caching of revocation lists with periodic refresh, allowing user overrides, etc. 

    This is nothing new in Big Sur, other than the fact that, as mentioned in the article, the initial release of Big Sur overwhelmed Apple's OCSP servers. You could imagine that all those new binaries being loaded for the first time, i.e., no benefits of caching, and the additional notarization process (tamper detection) being more widely adopted would present the OCSP servers with a huge crapload of certificate checks all at once and Apple was apparently only prepared to handle three-quarters of a crapload or suffered some sort of failure. But the underlying model is the same and it's not premised around data mining or user tracking.

    I've run into app loading issues, mainly very slow loading, with Windows .Net apps when the OS thought the computer was online because it was connected to the LAN, but the LAN was not connected to the WAN/Internet. In cases where the OS thinks that it should be able to talk to the certificate authority but it cannot reach the certificate authority it will typically time-out after several seconds (20-30 seconds per check) before it reverts to using the cached revocation information. When you install new binaries for the first time, this check is usually performed for every installed binary, so you can see how the delays could really add up.

    The bottom line of this topic, once you strip away the conspiracy theories, is that you are establishing a Trust relationship with Apple when you use their products. Apple is telling you that it will do everything within their power and to the best of their ability to protect you from the negative consequences of running untrusted software on their operating system. If you don't trust Apple you are not obliged to use their products, you can opt-out of the protections they provide, or you can place your trust in someone else, like Microsoft or Google.
    edited November 2020 cornchiproundaboutnowapplguybikerdude
  • Reply 7 of 40
    sflocalsflocal Posts: 5,736member
    I won’t be upgrading to this mess anytime soon.  
    What mess?  I’ve upgraded one of my Macs and it’s been working perfectly, even with some non-standard apps that I didn’t think would work.

    What’s your concern?
    williamlondonikirwatto_cobra
  • Reply 8 of 40
    Some have missed the point. Apple is knowingly sending unencrypted certificate requests to third party servers! This includes your IP and location. In Big Sur, this cannot be turned off. Huge privacy risk. 
    edited November 2020 cornchipwilliamlondonargonautrazorpitrain22
  • Reply 9 of 40
    This absolutely is a huge huge privacy and security exploit vector point. The amount of pain in the ass that this TPM  OS and software causes is nowhere near worth it. It’s hugely ruining the user friendliness the mac used to have. It’s quickly becoming pure pain and drudgery and a very big waste of time dealing with this unneeded over-secure bullshit, that turns out doesn’t even work!! Quite the opposite actually. Great engineering is less. This is way over-done, buggy, and clearly beyond what Apple can handle. Apple doesn’t have the chops to pull of what they are trying. Sad.  
    williamlondonprismatics
  • Reply 10 of 40
    This article feels like it is justifying gross negligence on Apple’s side.

    It is not relevant if Apple cannot or won’t do anything with the data. It shouldn’t home back without knowledge of the end user like that, and it shouldn’t do it unprotected.
    Some have missed the point. Apple is knowingly sending unencrypted certificate requests to third party servers! This includes your IP and location. In Big Sur, this cannot be turned off. Huge privacy risk. 
    The entire article is sugarcoating poor behavior on Apple’s end; happy_cycling summarized it in a paragraph. This is what happens - very simple - and it is completely out of line. I do not understand why the article requires so many words to justify this. It makes the article sound more like propagandist work than anything else.

    Edit: I was reading a version of the news item without the part of Apple’s plans for next year. It’s great they are improving this, and by this also a (legally safe) admission of a screw-up on their end. 

    It would have been better if the article didn’t have the title: “macOS Big Sur telling Apple what app you've opened isn't a security or privacy issue” but something more neutral so that we - readers - can make up our minds on whether it’s an issue or not.
    edited November 2020 williamlondonprismaticsargonautrazorpitrain22anantksundaram
  • Reply 11 of 40
    sflocal said:
    I won’t be upgrading to this mess anytime soon.  
    What mess?  I’ve upgraded one of my Macs and it’s been working perfectly, even with some non-standard apps that I didn’t think would work.

    What’s your concern?
    Thanks. My concern is privacy. I don’t want Apple to be aware of where I am, what I use and when. It’s why I chose Apple over Google.  
    williamlondonargonaut
  • Reply 12 of 40
    crowleycrowley Posts: 8,749member
    crowley said:
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    As usual you provide your obtuse anti-Apple BS right on queue, and are usually first to comment, I think you must be getting paid to provide first-in-line negative responses to pour your special brand of gasoline on a non-existent Apple fire, good god...
    Huh? I'm hardly ever the first to comment, only sometimes anti-Apple, and I don't even know why you think my comment is obtuse, it's pretty plain.

    Great counter argument though dude.
    williamlondonrazorpitanantksundaram
  • Reply 13 of 40
    crowley said:
    crowley said:
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    As usual you provide your obtuse anti-Apple BS right on queue, and are usually first to comment, I think you must be getting paid to provide first-in-line negative responses to pour your special brand of gasoline on a non-existent Apple fire, good god...
     I'm [...] only sometimes anti-Apple
    Bwahahahahaha, that's a good one.
    argonautcornchipwatto_cobra
  • Reply 14 of 40
    crowleycrowley Posts: 8,749member
    crowley said:
    crowley said:
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    As usual you provide your obtuse anti-Apple BS right on queue, and are usually first to comment, I think you must be getting paid to provide first-in-line negative responses to pour your special brand of gasoline on a non-existent Apple fire, good god...
     I'm [...] only sometimes anti-Apple
    Bwahahahahaha, that's a good one.
    My last 10 posts (not including those in this thread):

    So yeah, it's a good one.
    avon b7gatorguyanantksundaram
  • Reply 15 of 40
    ikirikir Posts: 111member
    I won’t be upgrading to this mess anytime soon.  
    Not related to Big Sur only anyway
    razorpitwatto_cobra
  • Reply 16 of 40
    gatorguygatorguy Posts: 23,174member
    Apple did acknowledge some issues this weekend, essentially validating what the security researcher Jeffry Paul reported. So over the next year Apple will be making security enhancement changes such as stop logging IP addresses when checking for app notarizations. Sometime over the next twelve months they will also be making changes in delivery methodologies to help mitigate server failures.

    ...And of more importance to some users Apple will release a Mac update that allows the computer owner to opt-out of using the macOS security protections the researcher found to be potentially problematic. 
  • Reply 17 of 40
    dewmedewme Posts: 3,824member
    Some have missed the point. Apple is knowingly sending unencrypted certificate requests to third party servers! This includes your IP and location. In Big Sur, this cannot be turned off. Huge privacy risk. 
    OCSP requests contain an IP address and a serial number associated with the certificate being checked. Every time you open a web page your IP address is exposed. Is it possible that someone could infer where your requests are coming from based on your IP address? Sure, just like anyone has been able to do since the creation of the internet more than 30 years ago.The certificate serial number has no personally identifiable information related to YOU. It only identifies the bundle of code that is associated with the certificate, for example, a conspiracy storyboarding application.

    If you believe that any of this is a huge privacy risk, put your computer behind a VPN or disconnect it from the internet. Problem solved.
    edited November 2020
  • Reply 18 of 40
    razorpitrazorpit Posts: 1,796member
    I understand the need for Apple to have this information. It is extremely helpful in protecting users. However not encrypting it is an issue, and something that a company should have addressed back when they first started collecting it. To be where we are with the transmission of unencrypted personal information years later is unacceptable.

    By collecting this data over time, this can supposedly create an archive that could easily be mined by bad actors, giving what could be considerable abilities to perform surveillance on a mass scale, possibly levels to the infamous and now shut down PRISM surveillance program

    Just because PRISM is "shut down" doesn't mean there isn't something else out there that replaced it. Just because we don't know about it doesn't mean it doesn't exist.
  • Reply 19 of 40
    crowley said:
    crowley said:
    crowley said:
    Article points out numerous security and privacy issues but seeks to diminish them using highly dubious reasoning. Headline is inappropriate.

    Yes it very much is an issue and Apple should know better.
    As usual you provide your obtuse anti-Apple BS right on queue, and are usually first to comment, I think you must be getting paid to provide first-in-line negative responses to pour your special brand of gasoline on a non-existent Apple fire, good god...
     I'm [...] only sometimes anti-Apple
    Bwahahahahaha, that's a good one.
    My last 10 posts (not including those in this thread):

    So yeah, it's a good one.
    Lulling us all into a false sense of security and then...  You pounce!!!
  • Reply 20 of 40

    Every time you open a web page your IP address is exposed. Is it possible that someone could infer where your requests are coming from based on your IP address? Sure, just like anyone has been able to do since the creation of the internet more than 30 years ago.The certificate serial number has no personally identifiable information related to YOU. It only identifies the bundle of code that is associated with the certificate, for example, a conspiracy storyboarding application. 

    If you believe that any of this is a huge privacy risk, put your computer behind a VPN or disconnect it from the internet. Problem solved.
    IP address obfuscation is a valid option - https://winstonprivacy.com (for example)

    This methodology works quite well for normal browsing and provides a great deal of anonymity.

    Has it really been only 30 years since Al Gore created the internet?  How time flies!  I could swear it was 40 years ago when I worked at ANL.
Sign In or Register to comment.