johnsonhammond2 | 27 Apr 2013 18:53
Favicon

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
(Continue reading)

SM | 15 Apr 2013 08:44

Re: Nits about draft-ietf-geopriv-held-measurements-06.txt

Hi Martin,
At 09:55 11-04-2013, Martin Thomson wrote:
>Ah yes, I'm not sure whether this was made explicit in this draft
>(probably not), but we take the view that the Device is a proxy for a
>user (Target in geopriv-parlance).  In terms of protocols and location
>determination that's the only reasonable assumption to make.  That's a
>really important point though, not something we should be taking on
>faith.  I'll make sure to add a note.

I don't disagree with the above.  I guess that the easier path is to 
add a note.  Alissa mentioned referencing Section 3.2 of RFC 6280.

>I don't know where you are going with the "unknowingly informant
>model", but it's true that in some cases, measurements that are
>provided to a LIS might not be useful. If your LIS is operated by a
>cellular operator, then maybe (though it's only a maybe) the cellular
>operator wont be able to use the information to improve a location
>estimate.  Similarly, they might not know how to deal with GLONASS
>pseudoranges.

In easy terms the "unknowingly informant model" is about a device 
providing information related to other people; i.e. data collection 
of information not belonging to the Target.

>Implementations have choices on the spectrum between: provide nothing
>and see if the LIS asks for more information; and provide everything
>and don't worry about the extra stuff.  The latter choice actually has
>some implications with respect to performance and time, so most likely
>it will go somewhere in between the two.

(Continue reading)

SM | 11 Apr 2013 08:02

Nits about draft-ietf-geopriv-held-measurements-06.txt

Hi Martin,

[I added a Cc to Eliot in case he is interested]

At 17:00 10-04-2013, Martin Thomson wrote:
>Hmm, I'd be interested to hear about what you consider to be
>problematic with the privacy considerations.  We put a lot of thought
>into those.  Obviously, this is potentially highly sensitive, but I
>thought we'd hit the important considerations.

As a FYI, the is an article about the privacy bounds of human 
mobility at 
http://www.nature.com/srep/2013/130325/srep01376/full/srep01376.html

Here are some nits (feel free to ignore).  Section 6 mentions that:

   "In order to protect the privacy of the subject of location-related
    measurement data, this implies that measurement data is protected
    with the same degree of protection as location information."

Section 6.2 mentions that:

   "By adding measurement data to a request for location information, the
    Device implicitly grants permission for the LIS to generate the
    requested location information using the measurement data.
    Permission to use this data for any other purpose is not implied."

and

   "A LIS MUST discard location-related measurement data after servicing
(Continue reading)

Stephen Farrell | 19 Mar 2013 11:10
Picon
Picon

Wouldn't it be nice if...


...people wanted to come along to the IETF and
standardise the kind of application protocol described
in the "solution" section of this [1] paper. (Just
seen on /. ) I'm not saying that that solution is
wonderful as-is, but it does appear to be a design
that tries hard to be privacy friendly and to
prevent false reporting.

From the paper, it looks like the Google and Waze
protocols that the authors analyse have serious
shortcomings that would likely have been spotted had
those protocols been developed more openly. There is
mention of open-source licensing, but however
those were developed, the result appears to show
a lack of security/privacy clue somewhere.

I'm not sure what, if anything, we could do to
encourage folks to bring such work here, but it
does really look like they could have deployed
something quite that  if they had
done that.

S.

[1]
https://media.blackhat.com/eu-13/briefings/Jeske/bh-eu-13-floating-car-data-jeske-wp.pdf
Bernard Aboba | 30 Jan 2013 20:06
Picon
Favicon

Ongoing Call for Comments

This is a note about two ongoing Call for Comments that may interest participants on this list. Comments on these documents can be sent to iab <at> iab.org or entered in TRAC.

1.  Privacy Considerations for Internet Protocols.   This Call for Comment ends on February 18, 2013.  The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: 
http://tools.ietf.org/html/draft-iab-privacy-considerations

The Call for Comment announcement is available here:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11573&tid=1359572424

2.  Issues in Identifier Comparison for Security Purposes.  This Call for Comment ends on February 10, 2013. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: 
http://tools.ietf.org/html/draft-iab-identifier-comparison

The Call for Comment announcement is available here:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11533&tid=1359572424
_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
SM | 14 Jan 2013 22:34

Re: Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard

Hi Nancy,
At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote:
>[NCW] I can change it to a lower case "must", ok?

That's ok.

>[NCW] We can move the reference to be normative.

Ok.

>[NCW] I don't think there are specifically for PT-EAP.  The sections you
>reference
>Were to (in section 6) addressing the general EAP identity as PT-EAP is
>really not
>An "authentication" method.

If I understood the above correctly PT-EAP does not transport any 
information which could be used to identify an individual.  That's 
different from PT-EAP not being an "authenticated" method. Therefore, 
there isn't much to say in terms of privacy considerations.

I suggest not including the following then:

   "As a transport protocol, PT-EAP does not directly utilize or
    require direct knowledge of any personally identifiable
    information (PII)."

The draft can leverage the second paragraph of Section 6 as "privacy 
considerations" instead of making a statement about PII.  I'll copy 
this message to ietf-privacy <at>  to get a better opinion.

In Section 6:

   "Therefore, it is important for deployers to leverage these
    protections in order to prevent disclosure of PII potentially
    contained within PA-TNC or PB-TNC within the PT-EAP payload."

I suggest "information about an individual" instead of PII [1].

Regards,
-sm

1. I used the wording from draft-iab-privacy-considerations-06  
Alexander Pretschner | 8 Jan 2013 15:14
Picon
Favicon

CfP: 4th International Workshop on Data Usage Management

4th International Workshop on Data Usage Management
co-located with the IEEE Symposium on Security and Privacy (SP)
Thursday, May 23rd, 2013
San Francisco, CA, USA

http://dig.csail.mit.edu/2012/IEEESP-DUMA13/

Data usage control generalizes access control to what happens to data in the future and after it has been given away (accessed). Spanning the domains of privacy, the protection of intellectual property and compliance, typical current requirements include ”delete after thirty days”, ”don’t delete within five years”, ”notify whenever data is given away”, and ”don’t print”. However, in the near future more general requirements may include ”do not use for employment purposes”, ”do not use for tracking”, as well as ”do not use to harm me in any way”. Major challenges in this field include policies, the relationship between end user actions and technical events, tracking data across layers of abstraction and logical as well as physical systems, policy enforcement, protection of the enforcement mechanisms and guarantees.

Following three successful events - the Dagstuhl Seminar on Distributed Usage Control (http://www.dagstuhl.de/en/program/calendar/semhp/?semnr=10141), the W3C Privacy and Data Usage Control Workshop (http://www.w3.org/2010/policy-ws/), and the WWW 2012 Workshop on Data Usage Management on the Web (http://dig.csail.mit.edu/2012/WWW-DUMW/) - the goal of the 4th International Workshop on Data Usage Management is to discuss current technical developments in usage control and, in particular, foster collaboration in the area of usage representation (policies is one mechanism), provenance tracking, misuse identification, and distributed usage enforcement. Though enabling privacy through careful and controlled dissemination of sensitive information is an obvious fallout of usage control, this workshop is interested in understanding data usage control as a whole. The workshop is also interested in discussing domain-specific solutions (which typically exist in semi-controlled environments) and their generalization to more open environments such as the Web.

Topics and Themes:
Topics of interest include but are not limited to

  • social (i.e. reputation systems) or economical (incentive based) approaches to usage control

  • provenance generation

  • provenance tracking

  • accountability

  • usage enforcement

  • usage policies

  • privacy

  • mis-use detection

  • different perspectives to usage management

  • domain-specific solutions to usage control

Submission:
We solicit short position (up to 5 pages) and long technical (upto 8 pages) papers in IEEE Proceedings format, http://www.ieee.org/conferences_events/conferences/publishing/templates.html on all dimensions of the above problem domain. Papers accepted by the workshop will be published by the IEEE Computer Society Press. Digital version of the proceedings will be made available to attendees.

All papers must be submitted via EasyChair at https://www.easychair.org/conferences/?conf=duma13.

Important Dates:
Papers due: February 11, 2013
Author notification: March 5, 2013
Camera ready and early registration deadline: April 1, 2013
Workshop Date: May 23rd, 2013

Program Committee:
Stefan Katzenbeisser, U Darmstadt
Jaehong Park, University of Texas at San Antonio
Renato Iannella, Semantic Identity
David Chadwick, University of Kent
Fabio Martinelli, IIT-CNR
Anupam Datta, CMU
Guenter Karjoth, IBM
David Basin, ETH Zurich
Sandro Etalle, T.U. Eindhoven & University of Twente
Stephan Micklitz, Google
Tim Finin, UMBC
Helen Nissenbaum, NYU

Organizers:
Lalana Kagal, Massachusetts Institute of Technology
Alexander Pretschner, Technische Universität München

 

Attachment (smime.p7s): application/pkcs7-signature, 5817 bytes
_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
Robin Wilton | 12 Dec 2012 11:52
Favicon

Re: ITU, DPI, and Deliberate Obscurity

Thanks Allison - 

tcpcrypt looks interesting, but the following couple of sentences make me a little uneasy:

By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. For example, if you log in to online banking using a password and the connection is over Tcpcrypt, it is possible to use that shared secret between you and the bank (i.e., the password) to authenticate that you are actually speaking to the bank and not some active (man-in-the-middle) attacker. 

I don't think they can have it both ways. Either they have a secure, non PKI-based (see their earlier dismissal of PKI on the same web page) authentication mechanism, or they are vulnerable to man-in-the-middle attacks of both kinds: simple ones which say the server doesn't support tcpcrypt, and advanced ones which interpose a tcpcrypt-capable server between you and the bank…

Needs a bit more investigation before I'd trust it...

Yrs.,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

Phone: +44 705 005 2931
Twitter: <at> futureidentity




On 11 Dec 2012, at 16:38, Allison Mankin wrote:


Another non-onerous encryption approach I'm finding quite compelling:  tcpcrypt (tcpcrypt.org).

On Tue, Dec 11, 2012 at 6:14 AM, Fred Baker (fred) <fred <at> cisco.com> wrote:
I think there are in fact ways to have encryption that are not onerous to users. Secure HTTP encrypts, although having a standard certificate given everybody is not the most "private" way to do things. Diffie-Helman encrypts without user involvement. If we put our thinking caps on, I suspect we could find a way to encrypt that isn't onerous.

_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
Dean Willis | 11 Dec 2012 18:00
Favicon

Re: ITU, DPI, and Deliberate Obscurity


On Dec 11, 2012, at 10:38 AM, Allison Mankin <allison.mankin <at> gmail.com> wrote:


Another non-onerous encryption approach I'm finding quite compelling:  tcpcrypt (tcpcrypt.org).

On Tue, Dec 11, 2012 at 6:14 AM, Fred Baker (fred) <fred <at> cisco.com> wrote:
I think there are in fact ways to have encryption that are not onerous to users. Secure HTTP encrypts, although having a standard certificate given everybody is not the most "private" way to do things. Diffie-Helman encrypts without user involvement. If we put our thinking caps on, I suspect we could find a way to encrypt that isn't onerous.


Yes, I really like tcpcrypt in concept. The "security" people I've talked to about tcpcrypt dismissed it rather glibly, but it seems to me that widespread use of tcpcrypt is both feasible and rewarding in its impact on casual inspection and consequent change of expectations. 

--
Dean
_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
Dean Willis | 9 Dec 2012 17:55
Favicon

ITU, DPI, and Deliberate Obscurity

If you aren't following tho, see:


A couple of years back we had some discussion about the need to design IETF protocols to be DPI resistant. One principle that I think should guide our efforts is that not only should each protocol be itself DPI resistant, but it should deliberately assist other protocols in being DPI resistant. I call this "intentional mutual obscurity".

Compare it to camouflage. In the city, one person wearing camo will stand out and be noticed. But in the woods during hunting season (or on the battlefield), everybody is camouflaged  and nobody stands out.  It also works for herds of zebras, it works for schools of fish, and it should work for flocks of packets.

You may remember thinking that this position was a little "extreme" when I proposed it.

With the ITU insisting on designing deep packet inspection into the network at the behest of dictators, tyrants, and thugs at various levels of political regimes, perhaps we're ready to reconsider?

--
Dean

_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
Johan Pouwelse | 21 Nov 2012 19:58
Picon

Notes from "Media without censorship" event at IETF Atlanta

Dear All,

Last IETF in Atlanta a side meeting was held about "media without censorship". Brief conclusion:
 - a large group of people is interested in this topic
 - implementation of ideas is judged to be key
 - difficult to fit in IETF, but other organisations are worse.


First, many thanks to all of the attendants for their valuable feedback.
Especially given the overloaded schedules of many people present.
It was a very productive meeting in my personal opinion.

  [informal meeting notes]
Roughly 18 people attended a late-night side meeting at 21:00 on 8 November in Atlanta.
It was taking place right after the bits&bites free drink event, lifting the general spirit so to say.
The improvised proposed agenda included: goal discussion, scenario discussion, prior technology and gap between vision/current tech, system architecture: sunshine model.

Discussed was the similarity between the Tor anonymous browsing experience and the censorship free scenarios. Key difference is the reputation system.
It was noted that the adversary model has unrealistic assumptions. The increase of attackers power and increasing demands on solutions was not sufficiently clear to readers. Should be removed or clarified.

A key question raised was: why does this need an IETF standard? This turned out to be surprisingly difficult to answer.
1) in IETF it is possible to obtain feedback from experienced engineers on architecture and design ideas. IETF people give valuable real-world experience based feedback, differing/complimenting from academia setting, Open Source world and digital human-rights activists.
2) it would produce clear specifications which could unite currently fragmented prototype-driven initiatives.
Given this, is then the IETF really the right venue for this?

The I-D is vague about the physical layer. It can simply be: Bluetooth, direct wifi, NFC and manual USB-stick based transport of information. Needs to be clarified.

The threat model was discussed further and deemed missing the evolution of the adversary.
The "Continuous evolution scenario" could be added. Draft explanation:
Due to the nature of an open standard against censorship, the inner workings of all mechanisms are known to the attacker. At some point it is likely to become compromised due to attacker evolution. To be future proof, the standard needs to be able to co-evolve and be able to include new defensive capabilities.

A draft picture of the possible architecture of the system model was discussed, called "sunshine model". The inner part contains the nodes in the system with high-speed Internet connectivity without censorship. They form the core of the system with possibly millions of participants, coming online and going offline regularly. Nodes at the core experience churn, but can always connect freely to other online nodes in the core (using NAT puncturing possibly) The "rays of sunlight" are nodes without media freedom and constrained Internet. Information transfer between these nodes uses DTN-like techniques and Bluetooth, NFC, direct wifi or USB drives.

Key components in the proposed system architecture are the message forwarding and reputation, voting or spam prevention part. 
For the message forwarding, significant overlap exists with the bundle protocols of DTNs. The term "bundle synchronization" was introduced, meaning exchanging all known new twitter-like messages between two nodes when they are near. The security in DTN work was discussed, as the anti-censorship scenarios place heavy demands on this.

Voting protocols is something the IETF seems to have done little work in.
Crowdsourcing and spam prevention is known to be a difficult problem in a fully distributed setting.

Other concerns raised: "what is the meat", "we have all this".

An important step forward is to create an implementation with re-usage of
existing software + usage of IETF standards where possible.
  [I lost track of the reasoning behind the importance of an implementation]
  Please enlighten me if an attendant remembers this.

Near the end of our 1 hour meeting it was noted that "the IETF is good at efficient data-communication protocols, but this is counter-intuitive". 
Implying that this work lies outside the usual IETF 'comfort zone'.

Greetings from Holland, johan.


On 9 November 2012 16:06, Martin Stiemerling <mls.ietf <at> googlemail.com> wrote:
Johan,

It would be good if you could write a summary about the last night's meeting and post it to the privacy list.

The key message of the room was 'get it implemented' and come back afterwards. I have seen that the DTNRG co-chairs (Jörg and Kevin) where rather positive about it. I.e., it might be good to stay in contact with them and if you have an implementation by the next IETF meeting, it might be good to see if this could be shown & explained in the DTNRG, if it is based on DTN.

  Martin


On 11/07/2012 10:21 PM, Johan Pouwelse wrote:
  [apologies for double posting]
Please attend this side meeting at IETF 85 if you are interested.

Vincent Roca was kind enough to do the first extensive review of the
discussion I-D for that event. Reaction inline below.

On Tuesday, November 6, 2012, Vincent Roca wrote:

    Hello,
    I've read your I-D (extremely interesting) and have a few comments:
    1- The attacker model of the 20sec and kill-switch scenarios
    We assume "the adversary cannot compromise smartphones or other
    participating devices".
    It looks rather strange to me.


This is indeed strange and only meant as a simplistic starting scenario.

      Personally I'd rather state the opposite:
    the threat model must be that of a powerful attacker (as in the 3rd
    scenario).
    Indeed, a device owners can be arrested and obliged to unlock its
    device... He may also be obliged to move around and to collect more
    information on others, using a modified device.

    Is it motivated by the desire to have some progression in the threat
    model
    in the document? If that's the case, then I understand, but state it
    clearly.


Indeed, the idea as to have progression in the threat model.
In the next version I will try to make that clearer.
Or if you think that is not a good idea, it can be changed.

    2- The 20sec scenario and the list of peers
    Is it recommended to have such a list with possibly thousands
    peers in this scenario when a device might be compromised
    (previous comment)? Is it the reason why the threat model makes
    the opposite assumption?


  Again done for simplicity.

    3- The 20sec scenario: clarification

    I understand the wired Internet is here, and usable, even if
    many links/servers/services are compromized. Am I correct?
    Because if it's not the case, then how would it be possible to
    broadcast a message to 20 million devices in 20sec using
    bluetooth and wifi networks only? 20 millions is a lot and having
    a meshed network large enough to reach them all using small
    range wireless techniques seems rather challenging ;-)


Yes, thank you for spotting this. It implicitly assumes wired Internet
and usable connections.
Will clarify this.

    4- AThe friend-to-friend scenario
    What does the following bullet mean?
      o  The adversary can choose the data written to the microblogging
           layer by higher protocol layers.
    (I confess I didn't read [BRIAR] where it's certainly explained)


Another clarification needed.. The idea is that the attacker can do a
chosen plain text attack.

    5- Concerning Tor...
    I agree, it's not the panacea for this use-case. In addition to
    what you're saying, we can add that it can make the situation
    worse. My colleagues have a paper on this topic:
    S. Leblond, A. Chaabane, P. Manils, M.A. Kaafar, C. Castelluccia, A.
    Legout, W. Dabbous,
    "One Bad Apple Spoils the Bunch: Exploiting P2P Applications to
    Trace and Profile Tor Users",
    USENIX Workshop on Large Scale Exploits and Emergent Threats
    (LEET'11), April 2011.
    http://arxiv.org/abs/1103.1518


Interesting work! Will use this in next version.
Never knew that your listen port number is actually privacy leakage in a
DHT.

    I'll be at the side-meeting.


Looking forward to it.  -j

    Cheers,
          Vincent



_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy


_______________________________________________
ietf-privacy mailing list
ietf-privacy <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

Gmane