banzay13
Emperor
They should made online petition to became Airstrip One, even with maga where more freedom in US 
Internet privacy, security, age restrictions, VPNs and backups
- Thread starter Samson
- Start date
Manfred Belheim
Moaner Lisa
- Joined
- Sep 11, 2009
- Messages
- 8,656
It would be darkly comedic if the government decide to make the petition website require age verification.
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
Another humerus, if not very effective response:
Parliament Protect for Drupal
Parliament Protect will block all UK Parliament IP address range visitors from accessing any content and redirect them to either a silly, satirical form, or a custom message of your choice. The module will also log any attempts at visits from the configured IP ranges and stores the number of times that happens.
This is the form to fill in
Parliament Protect for Drupal
Parliament Protect will block all UK Parliament IP address range visitors from accessing any content and redirect them to either a silly, satirical form, or a custom message of your choice. The module will also log any attempts at visits from the configured IP ranges and stores the number of times that happens.
This is the form to fill in
I came across this and thought it was relevant:
Surveillance Self-Defense
Tips, Tools and How-tos for Safer Online Communications
There are a load, those particularly relevant here:
How to: Manage Your Digital Footprint
How to: Understand and Circumvent Network Censorship
Choosing the VPN That's Right for You
LGBTQ Youth?
Surveillance Self-Defense
Tips, Tools and How-tos for Safer Online Communications
There are a load, those particularly relevant here:
How to: Manage Your Digital Footprint
How to: Understand and Circumvent Network Censorship
Choosing the VPN That's Right for You
LGBTQ Youth?
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
This is interesting, but a couple of comments:
- If Anonymous is saying this, where is the reference? Google can only find different versions of this video. I know Anonymous is decentralised, but would expect to see it somewhere else, perhaps here.
- When one is advocating for VPNs, I think it is better to emphasise the basic privacy and security reasons, rather that avoiding government action. The two big reasons I thing everyone should use a VPN are:
- If you do not use a VPN everyone on your local network, those who control your local network (your parents, your school or your employer) and your ISP can all see what sites you are visiting, and if you are using http (not that many clearnet sites support that these days) they can see everything you do and send.
- If you do not use a VPN every site your visit, as well as every advertiser on that site, can see where you live and cross reference that to any other site you have visited. This could be really dangerous.
Last edited:
If you are interesting it what you can do to stop the EU going further down the authoritarian path you may be interested in fight chat control. They have resources to help contacting your local representatives.
If you use a VPN, then you are replacing the ISP who could see all IPs you are visiting (not necessarily the sites!) with the VPN provider who can see all IPs you are visiting. I am not sure who I would trust more not to do that.
If your parents/school/employer have the desire. competence, and infrastructure to log everything you access, they usually also know how to block access to VPNs (my employer certainly does), so that point is moot.
With the shortage of IPv4 addresses, ISPs tend to use CGNAT, which makes identifying you by your IP close to impossible for 3rd parties and also makes IP geolocation wildly inaccurate. I just tried a few public geolocation services and some displayed the wrong side of the country. Others got the city correct (or almost correct), but there are millions of people living in this metro area.
If you are using IPv6, then this is much more of a concern, yes.
This is very true, and certainly is a concern. However your ISP knows exactly who you are, whereas your VPN only knows your IP address. It seems to me the worst case of your ISP or VPN handing over your browsing history to third parties is a lot better if it is the VPN.
This is a big reason to use crypto for paying for your ISP though (or cash or giftcard), as I mentioned in the OP.
If a VPN is blocked then at least you know.
Whenever I check my externally visible geolocation it gets it pretty close, and I always assume those who could do me most harm would be able to get this more accurately though I do not actually know..
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
Police raid passport photo data in ‘historic breach of privacy’
Campaigners criticise ‘Orwellian’ use of facial recognition technology
www.telegraph.co.uk
They will have these whizzing out and about soon -
Last edited:
Not really. Your VPN provider will know your real IP anyway and then you are only one data breach away from being identified. And since they have your browsing history, that should not be that hard to accomplish. Your ISP is at least bound to local laws, so my ISP is not allowed to store my browsing history. A VPN provider from elsewhere might not be as restrained. That said, if you local laws do not protect you, a VPN provider in a better country might be a good idea.
Eh, that probably does not accomplish much. If you are having a fixed line, they have your address anyway. And if you are connecting via mobile, your ISP knows where you approximately are* any time your phone is switched on and is very likely to store that data for some time (depending on local laws).
Depends a bit on the exact technical details of your internet access. The location of a consumer-grade dynamic IP address tends to be quite obfuscated. How accurate it can be depends on how many customers draw from the same IP address pool. And ISPs have a financial incentive to squeeze as many people into that as possible.
If you have static IP address, then the location of that tends to be known fairly accurately.
But that is IP address data only. If you have a smartphone, it is prone to leak location data through other channels. And as I said above, if we are assuming access to internal ISP data, the location is known anyway. In that case, the IP would be only one entrypoint and not even a good one (phone number would be much better).
*Edit: well, where your phone is, anyway
I am very much not an expert in these things, but it seems to me that using a VPN splits up the data better.
If you do not use a VPN then:
Your ISP knows exactly who you are and what sites you visit.
The sites know your IP address and whatever location data goes along with that.
Anyone on the same network knows what sites you visit.
If you use a VPN then:
Your ISP knows you are using a VPN.
Your VPN knows your IP address and what sites you visit.
The sites know you are using a VPN (probably).
Anyone on the same network knows nothing (or perhaps that you are using a VPN).
I have not yet got round to figuring it out, but it seems another option is oblivious DNS over https via Anonymized DNSCrypt. Looking at for example this and this it seems no one entity knows your IP address and what site you are visiting which has to be the best solution. I am very far from sure though.
Wikipedia has lost its case against Ofcom over the OSA.
If they end up getting classified as the most risky type of site they can try again,. but even less risky sites have to do more that Wikipedia can.
We may lose access to most of the worlds information. If you are worried, you can download it. One way is kiwis, where you can download that and over a thousand other books for free. You also need the app.
If they end up getting classified as the most risky type of site they can try again,. but even less risky sites have to do more that Wikipedia can.
We may lose access to most of the worlds information. If you are worried, you can download it. One way is kiwis, where you can download that and over a thousand other books for free. You also need the app.
Last edited:
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
This is all very muddy. If we wanted to be exact, we would need a distinction between "url", "base url" and "IP", and which of those you mean by "site". But in any case, the last sentences of each list are very much wrong: The network operator can know which IP addresses you send requests to (whether they actually know is a different matter). But not everyone on the same local network can know this: It takes an attack on the network to route traffic on the network through a participant, which should be detectable to you and the network operator. And if the network operator is competent (doubtful, of course), they kick attackers like this off the network. But the important distinction is between something which is readily available, something which is usually not available, but can be made so with some effort, and something which requires an active attack on someone to be available.
What you are missing are the providers between your ISP and the VPN or target server, which also know "your" IP and which IPs you are visiting and when you are using a VPN. If you are using a VPN, there will be more of those who might try to gather data about you.
Also, using a VPN opens another attack vector, because someone can attack the VPN. If someone is able to spoof your VPN provider, they can also get your IP and all IPs you visit.
There are reasons why you would want to use a VPN, but I don't think you can make a blanket statement that it is always more secure than not using a VPN. If you are using a shady VPN provider (or someone posing as your VPN provider), who sells all your data you are worse off than if you had no VPN, your ISP could know more about you, but does not actually know it, or does not do anything with that knowledge.
This only secures your DNS queries. Which is a popular point for data collection, because it allows the DNS provider to collect data about all base urls you visit and almost everything goes through your main DNS server. But all sites you visit and everything in between still get an IP for you. Because ultimately, they need to know where to send the response to. Remember that everything you fetch from the internet has to be traceable back to you, because you need to get the response and the systems need to know where to send it to. The only question is, how many layers of (intentional or unintentional) obfuscation there are between the site you visit and you. This determines how much effort an attacker would need to spend to trace it back to you. But with unlimited resources, this can always be done.
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
UK Govt's gleeful reply to todays 1st victory over Wiki -
Everyone?
''Ofcom is coming!''
Everyone?
''Ofcom is coming!''
Last edited:
Clubber Lang
King
- Joined
- Oct 20, 2016
- Messages
- 858
It all began with a ploughmans...
Some of the OSA founding principles were first written on the back of a sandwich packet (by a University of Essex professor) and then lobbied with help from a trust called Carnegie UK -
There maybe more to it then that.
Some of the OSA founding principles were first written on the back of a sandwich packet (by a University of Essex professor) and then lobbied with help from a trust called Carnegie UK -
There maybe more to it then that.
Last edited:
Unfortunately lgbtqia.space has had to geoblock the UK. This is the page they serve:
Spoiler Big Image :
TL/DR Zero Knowledge Proofs can never work for age verification online.
Privacy-Preserving Age Verification—and Its Limitations
Abstract
To a first technical approximation, it is straightforward to construct a privacy-preserving, credential-based age verification system for the Worldwide Web. However, the legal, economic, and social obstacles are formidable, and possibly insurmountable, especially in certain countries.
Conclusion
It is worth taking an analytic look at what I’ve proposed here. Roughly speaking, there are three components, the technical mechanism for getting a suitable credential—here, the IDP—the mechanism for conveying it from a browser to a web site (client-side certificates), and the human and procedural aspects of obtaining an age verification credential. I examine each in turn.
CL Credentials and the IDP: Except in countries with strong, age-containing digital credentials, I assert that any solution to the age verification problem will require an IDP-like entity. That is, there needs to be some entity that will translate human-readable documents such as birth certificates or passports into a digital credential. That is part of what an IDP does. The other part, of course, is that by using the CL protocol we achieve strong privacy guarantees. That alone justifies this architecture, even if a suitable national credential is used to obtain a CL credential. Quite crucially, this privacy guarantee is a technical mechanism, not a regulatory or bureaucratic one, and hence offers much stronger guarantees of privacy.
Credential Delivery: Realistically, there are only four possible ways for a browser to deliver an age credential to a server: a new protocol to replace HTTP/HTTPS, a new HTTP header line, out-of-band communication between IDP and web sites, or in a client-side certificate. The last is clearly better. The first is absurd; the changes required by 5everyone are far too great. The second and third would work, but make the credential separable from the session. A Web server sees it in plaintext; a hacked web server would be fruitful source of stolen credentials. (Many of today’s age verification services essentially employ this approach. Apart from the direct privacy risk—what will such a service do with the data it collects?—there are security risks as well. For example, a database created by Tea, an app where women can warn about some bad experiences with men, was recently hacked [22]. The database contained selfies and driver’s license data; these were used to verify that the person signing up was, in fact, a woman. A corresponding app for men, TeaOnHer, has also been reported as having serious security holes [32].) By contrast, a field in a client-side certificate is strongly bound to the session and isn’t replayable without knowledge of the private key. Furthermore, such a certificate could also authenticate people after first use if desired, thereby removing friction from the user’s experience. A CA is thus desirable even without using the CL protocol, though it raises the problem of private key and certificate-sharing between devices. Possibly, the IDP-like function and the CA function could be combined into a single entity, albeit with a risk to privacy: users need a separate certificate for each site, to avoid linkage.
Human and Procedural Aspects: By far the biggest problem with the scheme I’ve outlined is the many human-scale obstacles to dealing with IDPs. All of these apply to any other credential-based age verification scheme. You would still need suitable breeder documents, you would still need to travel to an IDP, you would still have the multiple device and multiple forms of authentication issue, you would still have the issues of the poor, the elderly, the rural, etc., having trouble obtaining credentials. I submit that this is no different for my scheme than for any other, even ones that are not privacy-preserving. It is this problem above all that has to be solved, without trying to solve national-scale problems such as poverty and homelessness.
Privacy-Preserving Age Verification—and Its Limitations
Abstract
To a first technical approximation, it is straightforward to construct a privacy-preserving, credential-based age verification system for the Worldwide Web. However, the legal, economic, and social obstacles are formidable, and possibly insurmountable, especially in certain countries.
Conclusion
It is worth taking an analytic look at what I’ve proposed here. Roughly speaking, there are three components, the technical mechanism for getting a suitable credential—here, the IDP—the mechanism for conveying it from a browser to a web site (client-side certificates), and the human and procedural aspects of obtaining an age verification credential. I examine each in turn.
CL Credentials and the IDP: Except in countries with strong, age-containing digital credentials, I assert that any solution to the age verification problem will require an IDP-like entity. That is, there needs to be some entity that will translate human-readable documents such as birth certificates or passports into a digital credential. That is part of what an IDP does. The other part, of course, is that by using the CL protocol we achieve strong privacy guarantees. That alone justifies this architecture, even if a suitable national credential is used to obtain a CL credential. Quite crucially, this privacy guarantee is a technical mechanism, not a regulatory or bureaucratic one, and hence offers much stronger guarantees of privacy.
Credential Delivery: Realistically, there are only four possible ways for a browser to deliver an age credential to a server: a new protocol to replace HTTP/HTTPS, a new HTTP header line, out-of-band communication between IDP and web sites, or in a client-side certificate. The last is clearly better. The first is absurd; the changes required by 5everyone are far too great. The second and third would work, but make the credential separable from the session. A Web server sees it in plaintext; a hacked web server would be fruitful source of stolen credentials. (Many of today’s age verification services essentially employ this approach. Apart from the direct privacy risk—what will such a service do with the data it collects?—there are security risks as well. For example, a database created by Tea, an app where women can warn about some bad experiences with men, was recently hacked [22]. The database contained selfies and driver’s license data; these were used to verify that the person signing up was, in fact, a woman. A corresponding app for men, TeaOnHer, has also been reported as having serious security holes [32].) By contrast, a field in a client-side certificate is strongly bound to the session and isn’t replayable without knowledge of the private key. Furthermore, such a certificate could also authenticate people after first use if desired, thereby removing friction from the user’s experience. A CA is thus desirable even without using the CL protocol, though it raises the problem of private key and certificate-sharing between devices. Possibly, the IDP-like function and the CA function could be combined into a single entity, albeit with a risk to privacy: users need a separate certificate for each site, to avoid linkage.
Human and Procedural Aspects: By far the biggest problem with the scheme I’ve outlined is the many human-scale obstacles to dealing with IDPs. All of these apply to any other credential-based age verification scheme. You would still need suitable breeder documents, you would still need to travel to an IDP, you would still have the multiple device and multiple forms of authentication issue, you would still have the issues of the poor, the elderly, the rural, etc., having trouble obtaining credentials. I submit that this is no different for my scheme than for any other, even ones that are not privacy-preserving. It is this problem above all that has to be solved, without trying to solve national-scale problems such as poverty and homelessness.
