VA is Virtual Address space. For a 32bit processor, you have 32bits of virtual address space - each process can occupy no more than 3G of RAM (on XP, with the/3G switch (which can hurt other parts of the system because it reduces the memory that the kernel can use)).
If you have more than one process, you have more than one virtual address space. So saying that each process can only address 3G of RAM doesn't matter - with 30 processes running, you could theoretically have 90G of VA allocated.
What's important is VM.
VM is vitual memory. VM is what backs the pages that are mapped into the VA.
The maximum amount of VM you can have allocated on a machine is measured by the commitment limit on the machine, which is typically measured as "physical RAM + page file space". If overall VM always stays below physical RAM, you don't need a paging file. But if it EVER goes above it, you're toast if you don't have a paging file. All those pages from the boot process that normally would have been discarded to the paging file (or were allocated by daemons that started during boot but haven't done anything since then) stick in the craw of the memory manager taking up space that COULD be used for your application, but can't because you've not told the OS where to put them.
That's why you have a paging file - it gives the OS a place to put the mouldy old pages that were allocated by apps that aren't actively doing things so your application can re-use the memory that those apps were using.
Btw, it's my understanding that ALL modern virtual memory based operating systems have essentially the same VM architecture - Linux, Windows, whatever. They both use paging files for essentially the same things - discarding writable pages that are not in current use by applications (read-only pages can typically be loaded from the binary image).
The "obscure version of NT that was never officially released" was actually the very first version of NT, NT 3.1, which had multiple desktops. The problem was that there was no UI that allowed for the user to access them.
But the support has been in NT since the beginning.
From what I've read at the UAC blog (http://blogs.msdn.com/uac) and the IE blog (http://blogs.msdn.com/ie), it's somewhat different.
IE and the desktop run in the same security context - in the worst case, IE can't do anything more than the user can. Since the user isn't running in a privileged account on Vista (unlike XP, users on Vista run with admin privileges turned off), IE still can't do anything that the user can't do. That eliminates shatter attacks.
But beyond that, IE runs in a special limited mode (User Interface Privilege Isolation, or UIPI) where even things that the normal user can do are restricted - code running in IE can't send window messages to higher integrity level windows (essentially every other window on the desktop). In addition, code running in IE effectively runs in a sandbox - can't write to the filesystem or the registry except for certain certain defined areas (this is the MIC feature mentioned in the IE blog post). See this Channel 9 video, or this IE blog post for more details on how IE's protected mode works.
Shatter attacks happen when code running in a restricted security context is allowed to send window messages to code running in highly privileged security context, the UIPI feature is explicitly designed to stop that. In addition to IE, when you run an application elevated (right click, select "Run as administrator"), the elevated application is run at a "high" UIPI mode. That means that normal apps running on the desktop cannot send window messages to those applications. Apps running on the desktop are also prohibited from opening processes at a higher UIPI mode for write access, which stops a different set of attacks. You can find info about UIPI here here.
So in Vista for an ActiveX control to issue a shatter attack that would exploit the system, you would need to have: 1) A hostile ActiveX running in the browser (so the attacker first has to convince the user to execute their code). 2) a vulnerability in UIPI that allows the ActiveX control to send a window message to a higher privileged application (like every other application running on the desktop). 3) An application running on the users desktop that is running with elevated privileges (to get an application running with elevated privileges requires a special action of the user), normally no application runs with elevated privileges. 4) A vulnerability in that application that would allow an attacker to cause the application to allow the attacker to execute arbitrary code in the application.
The bottom line is that there are at least 4 levels of defense-in-depth that would have to be breached for code running in IE to be execute a shatter attack.
There may be other ways of attacking the system that don't involve shatter attacks, but from what the Microsoft guys have said, I think that shatter attacks are gone.
So what. That's not an attack. You're saying that if you can run a program on the user's desktop, you can get another program, also running on the user's desktop in the same security context as your application to perform an operation.
Why ask the shell do perform an operation instead of simply performing it yourself? Anything explorer can do, your app can do.
So there's no security hole here.
The original shatter attack WAS a vulnerability in Windows - the WM_TIMER message allowed the sender of the message to specify an arbitrary location in the target app to execute (or something like that). That attack was closed a LONG time ago.
Nowadays, shatter attacks are caused when a privileged application (like a service) brings up UI on the application's desktop. Interestingly enough, this doesn't work for many scenarios (Fast User Switching, for example), but it didn't stop applications like from doing it.
On Vista, all system services run in a different session than the logged on user. As a result, all the UI of the service is completely inaccessible to the interactive user. Shatter attacks should be essentially impossible for Vista. However, fixing this security hole may break those apps that depend on the security hole.
How do I redirect Firefox's auto-update mechanism to my corporate update servers (without changing the binary, I'm not in the business of building versions of Firefox)?
I can't deploy the Firefox patches until I've made sure they don't break my corporate network.
Until Firefox adds the ability to be centrally managed in a similar way that IE can be centrally managed, it's not Windows problem, it's Firefox's problem.
The HTTP server component (http.sys) runs in the kernel, but IIS (everything that isn't involved with the HTTP protocol exchange)is in user mode, and has been for a long while.
The Free in FOSS is traditionally held to refer to two different kinds of free:
Free as in beer - you don't have to pay for it.
Free as in air - anyone can modify the source and distribute it.
My point here is that if everyone who deploys a solution based on FOSS has to pay some vendor to spread their liability, that effectively neuters the "free-as-in-beer" aspect of FOSS, leaving only the "free-as-in-air" part of FOSS.
Consider what happens to Linux as a client OS. If My-Top-three-computer-vendor (let's call it "IQ" for convenience) is going to be held liable to losses to businesses caused by a security hole in IQ Linux, then My-Top-three-computer-vendor is going to look for someone else to share the liability. They go to Jennifers-House-O-Linux and contract for support with an implicit sharing of liability. That's going to cost IQ, and they're going to pass that cost onto their customers. Now, all of a sudden, the "free" Linux OS isn't "free" anymore.
Now the free-as-in-air may be important, but if FOSS is only free-as-in-air, does it matter? Let's continue with the IQ Linux as a rebranded form of Jennifers-House-Of-Linux. I suspect that Jennifers-House-Of-Linux will only take patches from other vendors who are willing to share liability for those patches (to do otherwise would be stupid, because those patches might contain the security hold that costs Jennifers millions of dollars).
So the only people who can contribute to Jennifer's version of Linux (which is the only one that goes on IQ PC's) are those that are willing to share the liability for their security holes with Jennifer's. And I suspect that most contributors would balk at being held individually responsible for security holes in the product.
Actually, under current law, assuming they used a credit card, they're not liable for damages (up to $50.00). But under the new law, presumably they might be (of course this law doesn't exist, so I can make any assumptions about what it says:)...).
If Joe's purchased a support contract from Fred that shares Joe's liability with Fred, then is Fred's software REALLY free (as in beer)?
If, as a consequence of this FOSS stops being free-as-in-beer, doesn't that function as a FOSS killer?
It may still be free-as-in-air, but at the end of the day, does that really matter to anyone other than RMS? Since a vendor's going to be providing support, they're not about to let Sue Random contribute to the project, since they're potentially going to be held liable for any defects in Sue's changes. That will quash contribution from people other than the vendors providing support.
Joe's Online Bookshop decides to adopt Fred's GPL Shopping Cart package in his online store. Unfortunately, Fred's Free Shopping Cart package has a bug in it that will allow a hacker to extract the credit card info for all the customers of Joe's Online Bookshop.
A hacker realizes this and happily sells the credit card numbers for Joe's customers to the Russian Mafia.
Joe's customers realize that they're seeing fraudulent charges on their credit cards and they turn around and sue Joe for damages (which they can do with this new theoretical law).
Joe's bookshop has incurred REAL liability that they can't pass onto Fred, because they don't have a contractual relationship with Fred.
In the presence of a law that allowed for the collection of damages from vendors, there's no way that Joe's lawyers would allow Joe to use Fred's package, because it would leave Joe holding all the liability for damages with no way of passing them on to the actual culprit.
So Joe will instead switch to a non FOSS package so that they can at least share the liability.
From a hardware vendor's perspective, stable binary interfaces are nirvana.
It means that they can write their drivers to a stable interface and not have to worry about every single recompile of the kernel invalidating their work, which in turn means that they have lower support cost.
More hardware vendors would be willing to write drivers for Linux if they weren't worried about the consequences of open sourcing their drivers (drivers often contain info on how to drive their propriatary hardware that are trade secrets). A stable binary interface enables that.
So here's the question: Does having more hardware available for a platform mean more wider adoptation or less?
The corrolary question: Does wider adoptation mean more innovation or less?
If you believe that the answer to both of these questions is "yes", then can you really say that the lack of a stable driver binary interface drives innovation?
There are processor architectures that make stack overflows orders of magnitude harder. For instance, processors with a grow down stack architecture are way easier to exploit than processors with a grow up stack architecture (grow down means that a forward memory copy can overwrite the return address thus enabling the attacker to control the return address, that's a classic buffer overflow).
There are other processor features that make stack overflows harder, NX being a classic example (also mentioned above). The processors calling convention can also help - if your processor operates with three stacks, one for parameters, one for local data, the third for data flow, it renders the return stack immune from overflow of local data buffers, and mitigates the damage that can be caused by an overflow.
So yes, buffer overflows are a software problem. But the damage that they can cause is strictly a processor architecture issue.
According to the MSRC blog here, here. and here, they decided not to do an OOB release because the problem was only seen on a limited number of sites and those sites were being taken down as soon as they came up.
It's capitalized that way because the lDAP specification requires that the first character of each attribute in the directory be lower case. It's a standards thing.
You're saying that because the data is encrypted, it's DRM, because the encryption prevents people from accessing the data. Never mind the fact that that YOU posess the ONLY key to decrypt the data (from the article, it looks like that's what's sitting on the USB keyfob), it doesn't matter, because it's encrypted, people are prevented from accessing the data.
Encryption == DRM.
By that logic, SSL is also DRM, because it's designed to stop people from accessing data on the network, and the key is kept away from the owner of the machine.
Now if Microsoft builds a back door into BitLocker which allows someone to decrypt the data WITHOUT the keyfob, it's different. But that's the entire point of the original article.
Also, to be totally clear: the TPM COULD be used for DRM, from what I've been able to figure out, the TPM has a strong key embedded in the hardware. Thus a DRM scheme could encrypt the data being downloaded with the public key in the TPM which would prevent anyone who doesn't physically have the TPM from decrypting the data. And a DRM scheme COULD be built that would use a USB keyfob to hold the public/private key pair.
But there's NOTHING to indicate that BitLocker is anything but exactly what it claims to be: support for encrypting all the data on hard disk, not just the contents of files.
I've posted links to my information sources, I'm going to turn this around and ask you: Where are you getting your information from?
Why am I replying to an AC? I have no idea, but...
Do you even know what BitLocker is? It's full drive encryption - basically they encrypt all the data on the hard disk using a key in the TPM.
It's not about DRM, and can't be used for DRM.
DRM's about ensuring that you can't INTENTIONALLY give your data to someone else. BitLocker is about ensuring that you can't ACCIDENTALLY give your data to someone else.
On a BitLocker encrypted system, if you can boot the system, you can access your hard disk without any difficulties whatsoever.
BitLocker is all about making sure that if you accidentally leave your laptop in the back seat of a cab, the bad guys can't get at the data on the hard disk.
Which, in turn can save your company millions of dollars in fines if the data on your laptop happens to contain customer data.
Actually, look up the Dancing Pigs problem for more information.
Then consider that the Bagle.H email worm spread via a password protected.Zip file. That means that to spread, the user had to have unzipped the file after typing in the password, then ran the program contained in the file.
Marking code as executable's easy, just tell the user that they can't see the dancing pigs if they don't.
Slashdot Mirror
VM != VA. You're confusing the two.
/3G switch (which can hurt other parts of the system because it reduces the memory that the kernel can use)).
VA is Virtual Address space. For a 32bit processor, you have 32bits of virtual address space - each process can occupy no more than 3G of RAM (on XP, with the
If you have more than one process, you have more than one virtual address space. So saying that each process can only address 3G of RAM doesn't matter - with 30 processes running, you could theoretically have 90G of VA allocated.
What's important is VM.
VM is vitual memory. VM is what backs the pages that are mapped into the VA.
The maximum amount of VM you can have allocated on a machine is measured by the commitment limit on the machine, which is typically measured as "physical RAM + page file space". If overall VM always stays below physical RAM, you don't need a paging file. But if it EVER goes above it, you're toast if you don't have a paging file. All those pages from the boot process that normally would have been discarded to the paging file (or were allocated by daemons that started during boot but haven't done anything since then) stick in the craw of the memory manager taking up space that COULD be used for your application, but can't because you've not told the OS where to put them.
That's why you have a paging file - it gives the OS a place to put the mouldy old pages that were allocated by apps that aren't actively doing things so your application can re-use the memory that those apps were using.
Btw, it's my understanding that ALL modern virtual memory based operating systems have essentially the same VM architecture - Linux, Windows, whatever. They both use paging files for essentially the same things - discarding writable pages that are not in current use by applications (read-only pages can typically be loaded from the binary image).
The "obscure version of NT that was never officially released" was actually the very first version of NT, NT 3.1, which had multiple desktops. The problem was that there was no UI that allowed for the user to access them.
:)
But the support has been in NT since the beginning.
Not that it really matters
From what I've read at the UAC blog (http://blogs.msdn.com/uac) and the IE blog (http://blogs.msdn.com/ie), it's somewhat different.
IE and the desktop run in the same security context - in the worst case, IE can't do anything more than the user can. Since the user isn't running in a privileged account on Vista (unlike XP, users on Vista run with admin privileges turned off), IE still can't do anything that the user can't do. That eliminates shatter attacks.
But beyond that, IE runs in a special limited mode (User Interface Privilege Isolation, or UIPI) where even things that the normal user can do are restricted - code running in IE can't send window messages to higher integrity level windows (essentially every other window on the desktop). In addition, code running in IE effectively runs in a sandbox - can't write to the filesystem or the registry except for certain certain defined areas (this is the MIC feature mentioned in the IE blog post). See this Channel 9 video, or this IE blog post for more details on how IE's protected mode works.
Shatter attacks happen when code running in a restricted security context is allowed to send window messages to code running in highly privileged security context, the UIPI feature is explicitly designed to stop that. In addition to IE, when you run an application elevated (right click, select "Run as administrator"), the elevated application is run at a "high" UIPI mode. That means that normal apps running on the desktop cannot send window messages to those applications. Apps running on the desktop are also prohibited from opening processes at a higher UIPI mode for write access, which stops a different set of attacks. You can find info about UIPI here here.
So in Vista for an ActiveX control to issue a shatter attack that would exploit the system, you would need to have:
1) A hostile ActiveX running in the browser (so the attacker first has to convince the user to execute their code).
2) a vulnerability in UIPI that allows the ActiveX control to send a window message to a higher privileged application (like every other application running on the desktop).
3) An application running on the users desktop that is running with elevated privileges (to get an application running with elevated privileges requires a special action of the user), normally no application runs with elevated privileges.
4) A vulnerability in that application that would allow an attacker to cause the application to allow the attacker to execute arbitrary code in the application.
The bottom line is that there are at least 4 levels of defense-in-depth that would have to be breached for code running in IE to be execute a shatter attack.
There may be other ways of attacking the system that don't involve shatter attacks, but from what the Microsoft guys have said, I think that shatter attacks are gone.
So what. That's not an attack. You're saying that if you can run a program on the user's desktop, you can get another program, also running on the user's desktop in the same security context as your application to perform an operation.
Why ask the shell do perform an operation instead of simply performing it yourself? Anything explorer can do, your app can do.
So there's no security hole here.
The original shatter attack WAS a vulnerability in Windows - the WM_TIMER message allowed the sender of the message to specify an arbitrary location in the target app to execute (or something like that). That attack was closed a LONG time ago.
Nowadays, shatter attacks are caused when a privileged application (like a service) brings up UI on the application's desktop. Interestingly enough, this doesn't work for many scenarios (Fast User Switching, for example), but it didn't stop applications like from doing it.
On Vista, all system services run in a different session than the logged on user. As a result, all the UI of the service is completely inaccessible to the interactive user. Shatter attacks should be essentially impossible for Vista. However, fixing this security hole may break those apps that depend on the security hole.
How do I redirect Firefox's auto-update mechanism to my corporate update servers (without changing the binary, I'm not in the business of building versions of Firefox)?
I can't deploy the Firefox patches until I've made sure they don't break my corporate network.
Until Firefox adds the ability to be centrally managed in a similar way that IE can be centrally managed, it's not Windows problem, it's Firefox's problem.
IIS runs in kernel space? Since when?
The HTTP server component (http.sys) runs in the kernel, but IIS (everything that isn't involved with the HTTP protocol exchange)is in user mode, and has been for a long while.
Sourceless? It's being licensed under the BSD license. That's an open source license last I heard.
But MS java wasn't open source. If the output of the OpenDoc converter produces crap ODF, then you can just fix the converter to produce correct ODF.
Right? That's supposed to be the whole point of open source - if the software is crap, you can always fix it.
MOD PARENT UP!!!
Once again, the dancing pigs win - parent is 100% right, according to the article, the vulnerability being exploited here is the user.
Go and read Brooks "The Mythical Man Month", then come back and reconsider your comment.
If you don't have to worry about maintainability and documentation and cooperation, then YES, one person can do more than 5.
But heaven help you if that person gets hit by a bus.
My point here is that if everyone who deploys a solution based on FOSS has to pay some vendor to spread their liability, that effectively neuters the "free-as-in-beer" aspect of FOSS, leaving only the "free-as-in-air" part of FOSS.
Consider what happens to Linux as a client OS. If My-Top-three-computer-vendor (let's call it "IQ" for convenience) is going to be held liable to losses to businesses caused by a security hole in IQ Linux, then My-Top-three-computer-vendor is going to look for someone else to share the liability. They go to Jennifers-House-O-Linux and contract for support with an implicit sharing of liability. That's going to cost IQ, and they're going to pass that cost onto their customers. Now, all of a sudden, the "free" Linux OS isn't "free" anymore.
Now the free-as-in-air may be important, but if FOSS is only free-as-in-air, does it matter? Let's continue with the IQ Linux as a rebranded form of Jennifers-House-Of-Linux. I suspect that Jennifers-House-Of-Linux will only take patches from other vendors who are willing to share liability for those patches (to do otherwise would be stupid, because those patches might contain the security hold that costs Jennifers millions of dollars).
So the only people who can contribute to Jennifer's version of Linux (which is the only one that goes on IQ PC's) are those that are willing to share the liability for their security holes with Jennifer's. And I suspect that most contributors would balk at being held individually responsible for security holes in the product.
Actually, under current law, assuming they used a credit card, they're not liable for damages (up to $50.00). But under the new law, presumably they might be (of course this law doesn't exist, so I can make any assumptions about what it says :)...).
If Joe's purchased a support contract from Fred that shares Joe's liability with Fred, then is Fred's software REALLY free (as in beer)?
If, as a consequence of this FOSS stops being free-as-in-beer, doesn't that function as a FOSS killer?
It may still be free-as-in-air, but at the end of the day, does that really matter to anyone other than RMS? Since a vendor's going to be providing support, they're not about to let Sue Random contribute to the project, since they're potentially going to be held liable for any defects in Sue's changes. That will quash contribution from people other than the vendors providing support.
Closed source vendors have the option of passing the additional costs for this liability onto their customers.
OSS vendors don't.
Let's consider a hypothetical.
Joe's Online Bookshop decides to adopt Fred's GPL Shopping Cart package in his online store. Unfortunately, Fred's Free Shopping Cart package has a bug in it that will allow a hacker to extract the credit card info for all the customers of Joe's Online Bookshop.
A hacker realizes this and happily sells the credit card numbers for Joe's customers to the Russian Mafia.
Joe's customers realize that they're seeing fraudulent charges on their credit cards and they turn around and sue Joe for damages (which they can do with this new theoretical law).
Joe's bookshop has incurred REAL liability that they can't pass onto Fred, because they don't have a contractual relationship with Fred.
In the presence of a law that allowed for the collection of damages from vendors, there's no way that Joe's lawyers would allow Joe to use Fred's package, because it would leave Joe holding all the liability for damages with no way of passing them on to the actual culprit.
So Joe will instead switch to a non FOSS package so that they can at least share the liability.
From a hardware vendor's perspective, stable binary interfaces are nirvana.
It means that they can write their drivers to a stable interface and not have to worry about every single recompile of the kernel invalidating their work, which in turn means that they have lower support cost.
More hardware vendors would be willing to write drivers for Linux if they weren't worried about the consequences of open sourcing their drivers (drivers often contain info on how to drive their propriatary hardware that are trade secrets). A stable binary interface enables that.
So here's the question: Does having more hardware available for a platform mean more wider adoptation or less?
The corrolary question: Does wider adoptation mean more innovation or less?
If you believe that the answer to both of these questions is "yes", then can you really say that the lack of a stable driver binary interface drives innovation?
There are processor architectures that make stack overflows orders of magnitude harder. For instance, processors with a grow down stack architecture are way easier to exploit than processors with a grow up stack architecture (grow down means that a forward memory copy can overwrite the return address thus enabling the attacker to control the return address, that's a classic buffer overflow).
There are other processor features that make stack overflows harder, NX being a classic example (also mentioned above). The processors calling convention can also help - if your processor operates with three stacks, one for parameters, one for local data, the third for data flow, it renders the return stack immune from overflow of local data buffers, and mitigates the damage that can be caused by an overflow.
So yes, buffer overflows are a software problem. But the damage that they can cause is strictly a processor architecture issue.
Please note: the migration was from "Costly unix" to Linux. So this isn't a Windows->Linux migration story, but a *nix->Linux migration story.
According to the MSRC blog here, here. and here, they decided not to do an OOB release because the problem was only seen on a limited number of sites and those sites were being taken down as soon as they came up.
Except, of course this isn't an AJAX application. It's an XUL application, which has nothing to do with ajax.
Sort-of like the relationship between "javascript" and "java", only more tenuous (at least both of those were programming languages).
It's capitalized that way because the lDAP specification requires that the first character of each attribute in the directory be lower case. It's a standards thing.
Ok, I think I understand.
You're saying that because the data is encrypted, it's DRM, because the encryption prevents people from accessing the data. Never mind the fact that that YOU posess the ONLY key to decrypt the data (from the article, it looks like that's what's sitting on the USB keyfob), it doesn't matter, because it's encrypted, people are prevented from accessing the data.
Encryption == DRM.
By that logic, SSL is also DRM, because it's designed to stop people from accessing data on the network, and the key is kept away from the owner of the machine.
Now if Microsoft builds a back door into BitLocker which allows someone to decrypt the data WITHOUT the keyfob, it's different. But that's the entire point of the original article.
Also, to be totally clear: the TPM COULD be used for DRM, from what I've been able to figure out, the TPM has a strong key embedded in the hardware. Thus a DRM scheme could encrypt the data being downloaded with the public key in the TPM which would prevent anyone who doesn't physically have the TPM from decrypting the data. And a DRM scheme COULD be built that would use a USB keyfob to hold the public/private key pair.
But there's NOTHING to indicate that BitLocker is anything but exactly what it claims to be: support for encrypting all the data on hard disk, not just the contents of files.
I've posted links to my information sources, I'm going to turn this around and ask you: Where are you getting your information from?
Ok, I looked up how to use BitLocker:
r ary/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx
http://www.microsoft.com/technet/windowsvista/lib
First off, it doesn't need a TPM, it can work off a flash drive.
There's nothing in the documentation that says it has anything to do with DRM.
It's possible that the TPM can be used for DRM, but BitLocker isn't about DRM, and can't be used for DRM.
Why am I replying to an AC? I have no idea, but...
Do you even know what BitLocker is? It's full drive encryption - basically they encrypt all the data on the hard disk using a key in the TPM.
It's not about DRM, and can't be used for DRM.
DRM's about ensuring that you can't INTENTIONALLY give your data to someone else. BitLocker is about ensuring that you can't ACCIDENTALLY give your data to someone else.
On a BitLocker encrypted system, if you can boot the system, you can access your hard disk without any difficulties whatsoever.
BitLocker is all about making sure that if you accidentally leave your laptop in the back seat of a cab, the bad guys can't get at the data on the hard disk.
Which, in turn can save your company millions of dollars in fines if the data on your laptop happens to contain customer data.
Ancient? It dates back to 1997, and yes, it comes from Microsoft :)
It comes from a talk Nathan Myhrvold (CTO at Microsoft) gave at ACM: http://research.microsoft.com/acm97/nmNoVid.ppt
Actually, look up the Dancing Pigs problem for more information.
.Zip file. That means that to spread, the user had to have unzipped the file after typing in the password, then ran the program contained in the file.
Then consider that the Bagle.H email worm spread via a password protected
Marking code as executable's easy, just tell the user that they can't see the dancing pigs if they don't.